Howto: Removing a disk from a VM - howto identy the right disk?

From time to time, we need to remove disks from a VM. If there's only two or three disks attached to the VM, it's typically not a problem figuring out which one to remove e.g. if the disks have different sizes. But if you have seven or eight disks and they are the same size, then it's a bit more tricky - let's say if you're asked to remove the 'E-drive'. Under 'Edit Settings' for the VM, the disks only have a number which does not necessarily correspond with anything within the VM.

So how to identify exactly which disk that corresponds with a given volume within Windows?

The match can be made by looking at the SCSI target ID for the disk - this can be identified both in WIndows and under 'Edit settings' for the VM (A VM can have four SCSI controllers with up to 15 disks on each controller, so a maximum of 60 disks per VM).

To identify SCSI target ID within the VM:

Go to Computer Management -> Disk Management

Right click a disk and choose Properties

On the General tab you will see the Bus number (SCSI controller) and the Target ID (SCSI target ID), note the number - in this case below the ID is 4.

To identify SCSI target ID from the VI client:

Now go to 'Edit Settings' for the VM under and locate the disk with the corresponding target ID (see Virtual Device Node for the disk). Make sure the that the controller number and SCSI ID is the same. In this case it is Hard Disk 5 that have SCSI ID 4.

Shut down the VM to remove the disk.

Resetting the root password on ESXi 5 (and ESXi 4)

Yesterday, we had a fairly nasty situation at work where a standalone ESXi 4.1 host had to be rebooted. After reboot it did not automatically reconnect to vCenter and so a manual reconnect was done which prompted for root password. Unfortunately, we did not have the root password (don't ask). The host was joined to a domain but it could not be added to vCenter by using domain credentials and ssh to host with domain credentials did not work either. So, having 19 VMs down and no way to power them back on, I was basically screwed (all VMs were residing on DAS).

According to this VMware KB article there is no supported way to reset the root password on an ESXi v4 or v5 other than to reinstall it (or do a repair). I contacted VMware support and they sent me a guide for doing it in an unsupported way.

Finally, I mounted the ESXi 4.1 install ISO and did a repair. This resets most host configurations such a root password, network configuration, ntp settings, domain etc. After this I could set the pas

sword, reconnect to vCenter and then I had to reconfigure the host. Fortunately, the VMs were not completely gone from vCenter but were presented as greyed out orphaned VMs. So I could still see which LUNs the VMs were residing on. That way, the .vmx files could be located (except for one VM that had been renamed in vCenter without svMotioning or migrating it to another LUN afterwards...), the orphaned VM could be removed and the VM could be readded. It was quite a boring process but a least it worked.

Today, I wanted to recreate the password reset method in my home lab to see if I had actually done it in the correct way. I can confirm that, at least, on a virtual ESXi 5 it works and it is possible to reset the password to blank.

These are the steps
Download a Linux live bootable ISO. I used KNOPPIX. Mount the ISO and boot the host.

Once booted into KNOPPIX, open a shell.


Run the following set of commands:

# fdisk -l
# mkdir /mnt/disk
# mount /dev/sda5 /mnt/disk

(Mounting the correct device is the tricky part. To me, it was rather confusing which one to choose. For both the Fujitsu server that I dealt with and for the virtual ESXi, though, it was in sda5 that the state.tgz file was located.
VMware suggested using the following command for HP servers:
# mount /dev/cciss/c0d0p5 /mnt/disk - c0d0p5 is controller 0, disk 0, partition 5)

# cd /mnt/disk
# ls -al
# cp state.tgz state.tgz.bak
# cd /ramdisk
# mkdir temp
# cd temp
# tar zxf /mnt/disk/state.tgz
# ls -al
# tar zxf local.tgz
# cd etc
# nano shadow


Blank out the encrypted password. For example change root:$1$ywxtUqvn$9e1iXjGVd45T5IAgRxAuV.:13358:0:99999:7:::
to root::13358:0:99999:7:::

See below screendumps for before and after:

Save the shadow file.

Run the following commands to repackage everything:

# cd ..
# rm -rf local.tgz
# tar zcf local.tgz *
# chmod 755 local.tgz
# rm -rf /mnt/disk/state.tgz
# tar zcf /mnt/disk/state.tgz local.tgz
# ls -al /mnt/disk/
# umount /mnt/disk
# shutdown -r now

Disabling cores in BIOS for BL460c Gen8

Due mainly to licensing rules imposed by Oracle and Microsoft, there is an increasing demand for either locking VMs to specific hosts (like with VM-host-affinity rules) or for decreasing the number of physical CPUs or logical cores in the ESX hosts.

For HP hardware it is possible to order Blade servers with 2, 4, 6, or 8 cores - at least for BL460c Gen8. But in my company, we like to keep things as standard as possible, not having too many different hardware models.

As per Gen8, it is possible to disable a given number of cores in the BIOS. It has to be increased/decreased in pairs from 1 to 8. So as a minimum you can have 1 core enabled on each CPU. It is not possible to deactivate one of the physical CPUs.

Downloading VMware tools seperately from VMware site

The other day I had to extract the VMware tools ISO for a customer. One way to do it is to log on to a VM that has not updated VMware tools to latest version, choose to upgrade VMware tools manually and then copy all of the files on the mounted ISO and make a new ISO.

However, the different versions of VMware tools can also be downloaded directly from VMware's website on http://packages.vmware.com/tools. There are also tools version for Windows servers.

I found some more info on it on this site

Why Are There Two VMX Files?

Have you noticed that for a powered on virtual machine in vSphere 5.1, there is now an additional VMX file that ends with an ~ (tilde) found within the virtual machine's configuration directory?

This was an observation that was made by a few folks and some thought it might be related to a virtual machine's lock file which is created when a virtual machine is powered on. After a bit of research, it turns out this extra VMX file is not a lock file but actually an "edit file". This edit file is a copy of the original VMX file and when changes are required, they are applied to the edit file first. Once the changes are complete, the edit file is then atomically swapped with the original VMX file which helps prevent potential VMX file corruption. In the worst case event where the original VMX file is somehow corrupted, the virtual machine can be restored using the edit file.

This is another reason why you should not be manually editing a virtual machine's VMX file, especially when it is still powered on. For any VMX configuration changes, you should be automating using the vSphere API through the use of either PowerCLI or the vSphere SDK for Perl.

How to change SID in Windows Server 2008 R2

Most of the tech guys usually work on VMware and some other Virtual platforms and usually install the same OS to create multiple copies. You can do this copy by two methods.

1.      By cloning the virtual machine

2.      By Changing the SID of the OS so that it will not conflict.

In previous version of Windows like 2003 we usually use NewSID.exe that is recommended by Microsoft to changing the SID. But if you will use this NewSID.exe with windows server 2008 it will work but if you will use this for Windows Server 2008 R2 then your OS will be crashed and will be rebooted in recovery mode every time you restart.

In this blog i will describe you how to change SID on Windows Server 2008 R2.
The method is to use sysprep. 

First, click on  Start->Run, type sysprep and press OK.

This will open sysprep folder which is located in c:\Windows\System32. Open sysprep application.

This will open System Preparation Tool 3.14 window. As a System Cleanup Action select Enter System Out-of-Box Experience (OOBE).

Important: select Generalize if you want to change SID, it’s not selected by default.

As Shutdown Options select Reboot.

It will take some time for sysprep to finish.

After rebooting you will have to enter some data, like Country or region, Time and currency and Keyboard input.

Also, you will have to accept EULA. After booting, in Server Manager you’ll see that everything is changed, if you had some settings that you had configured earlier that will be changed as you have some new OS.

You can check the SID if you want to check
Also you can use the PsGetSid that is very small utility to check the SID

How To Backup & Restore Free ESXi Host Configuration

ESXi host configurations can easily be backed up and restored using either the vCLI's vicfg-cfgbackup or PowerCLI's Get-VMHostFirmware cmdlet. These commands along with others that perform "write" operations are only supported when you have a (paid) licensed version of ESXi. If you are using free ESXi, the remote commands are only available for "read-only" operations.
Note: In my personal opinion, it is much quicker and more efficient to re-install ESXi and apply your configurations using either a scripted deployment such as kickstart or a combination along with post configuration scripts. Re-installs become extremely trivial when you centralize your ESXi host configurations, even for small setups. 

Having said that, if you are running free ESXi in a small shop or in a home lab and wish to backup your ESXi host configurations, you can still do so by leveraging a neat little tool called vim-cmd found within the ESXi Shell. There is a section under hostsvc/firmware which manages the ESXi host configuration which also uses the same vSphere APIs that both vicfg-cfgbackup & Get-VMHostFirmeware command uses.

Under this section of vim-cmd, there are four commands:

• backup_config   
• reset_config    
• restore_config  
• sync_config

Prior to actually backing up your ESXi host configuration, run the following command which will flush the ESXi configuration changes:

vim-cmd hostsvc/firmware/sync_config

To backup the ESXi host configurations, run the following command which will generate a file that will be automatically stored in /scratch/downloads and can also be downloaded from a web browser using the URL shown from the output:

vim-cmd hostsvc/firmware/backup_config

Before restoring your ESXi host configurations, you will need to ensure the file is renamed to configBundle.tgz and stored under /tmp directory. You will also need to ensure the ESXi host is placed in maintenance mode by running the following command:

vim-cmd hostsvc/maintenance_mode_enter

To restore the ESXi host configurations, run the following command and specify the backup configuration file which should reside in /tmp/configBundle.tgz:

vim-cmd hostsvc/firmware/restore_config /tmp/configBundle.tgz

Note: Upon completing the restore, it will automatically reboot your ESXi host.

Here is a screenshot using the above commands to backup and then restore ESXi host:

Note: You can not restore an ESXi host using a configuration file backed up from a different host.

Enable Auto Startup After Power Failure For Apple Mac Mini

I recently came across a very useful tidbit after receiving several inquires asking how to configure an Apple Mac Mini to automatically startup after a power failure. This is extremely useful for situations where power is eventually restored and you are not physically around to press the power button. Automatically starting up after a power failure is not a new feature of the Mac Mini and it actually exists on most modern day systems and can be configured using a variety of tools.

The challenge arises when you are running ESXi, how do you go about enabling this functionality in ESXi itself? Well the answer is actually quite simple, you can enable this outside of ESXi. Normally to enable this feature you can either run a setpci command on UNIX/Linux system or configure the energy saver settings in OS X. Several folks from the VMTN community such as zippytiff and twuhabro have already confirmed having success using the latter option when booting OS X off a USB or SD card to modify the energy saving settings.

I finally got a chance to look into this a bit more for myself and with a bit of research, I found several other methods which also works and may potentially be easier.

Note: I have heard that historically the auto startup flag has not persisted in older Apple hardware, but for the new Mac Mini 5,3 and 6,2, they seem to be persisting without any issue from my testing. YMMV depending on your hardware and/or firmware.

Method 1 (Configure in OS X)

If you already have OS X install on your Mac Mini, then you just need open up the System Preferences and enable auto startup under the Energy Saver section. Once that has been enabled, you can then perform your ESXi installation.

If you already have ESXi installed, then you can use either Method 2 or 3.

Method 2 (Configure using bootable Ubuntu on USB)

We can create a bootable Ubuntu image running off of a USB device (minimal footprint) and run the following setpci command to enable auto startup:

setpci -s 0:1f.0 0xa4.b=0

If you are interested in the gory details on the above command, please refer to this great article which breaks it all down for you. After you have created your Ubuntu image using the instructions in the above link, you can boot off of the USB device (Make sure to hold down ALT/OPT key so you can select to boot off of the USB device). Once Ubuntu has booted up, you will right click on the purple icon on the upper left hand corner and type in terminal.

You will then launch the terminal application and type the following to change over to root user.

sudo su -

Finally, you will enter the above setpci command which will enable the auto startup. At this point, you can type reboot and remove the USB device.

Method 3 (Configure using bootable OS X on USB)

Another method is to create a bootable OS X image running off of a USB device and change the power management settings by using the pmset utility. To enable auto startup, run the following command in the terminal:

pmset autorestart 1

You will need the original OS X installer and if you are using either Lion or Mountain Lion, you can use Lion DiskMaker to help you create the bootable USB image (Make sure to hold down ALT/OPT key so you can select to boot off of the USB device). Once the OS X installer boots up, at the top select Utilities and click on the Terminal application.

Go ahead and run the above command to enable auto start and then type reboot and remove the USB device.

The last thing to do of course is to actually test this out on your Mac Mini. Go ahead and let the system boot up and then yank the power cord and then give it a few seconds before plugging it back in. You should see the Mac Mini automatically power back on after you plug the power back in.

VMware vSphere can virtualize itself + 64-bit nested guests

Running VMware ESXi inside a virtual machine is a great way to experiment with different configurations and features without building out a whole lab full of hardware and storage. Virtualization enthusiasts everywhere have benefited from the ability to run ESXi on ESXi, first introduced with the vSphere 4 release.

VMware vSphere 5 makes it easier than ever to virtualize hypervisor hosts. With new capabilities to run nested 64-bit guests and take snapshots of virtual ESXi VMs, the sky is the limit for your cloud infrastructure development lab. Heck, you can even run Hyper-V on top of vSphere 5 — not that you’d want to.

Physical Host Setup

The physical host running VMware ESXi 5 requires just a few configuration changes; here is a guide:

• Install VMware ESXi 5 on a physical host and configure networking, storage, and other aspects as needed
• Configure a vSwitch and/or Port Group to have Promiscuous Mode enabled
• Create a second Port Group named “Trunk” with VLAN ID All (4095) if you want to use VLANs on virtual hypervisors
• Log in to Tech Support Mode (iLO or ssh) and make the following tweak to enable nested 64-bit guests

  echo 'vhv.allow = "TRUE"' >> /etc/vmware/config

Virtual VMware ESXi Machine (vESXi) Creation

For various reasons, it’s not feasible to clone virtual ESXi VMs. As an alternative, create a fully-configured shell VM to use as a template — it can be cloned before ESXi is installed.

Create a new VM with the following guidance:

• Guest OS: Linux / Red Hat Enterprise Linux 5 (64-bit)
• 2 virtual sockets, 2+ GB RAM
• 4 NICs — connect NIC 1 to the management network and the rest to the “Trunk” network:
• Thin provisioned virtual disks work fine
• Finish creating the VM, then edit the following settings
  • Options/General Options: change Guest Operating System to Other – VMware ESXi 5.x
  • CPU/MMU Virtualization: Use Intel VT … EPT… ( bottom radio button)
• Don’t power this VM on — keep it to act as a template
• Clone and install VMware ESXi via ISO image or PXE boot
• Add to vCenter and configure virtual ESXi hosts for action

Nested 64-bit Guests

With the release of VMware vSphere 5, nested guests can be 64-bit operating systems. Just be sure to make the change to /etc/vmware/config on the physical host as indicated above.

Nested guests can be migrated with vMotion between virtual or physical VMware ESXi hosts; this requires a vMotion network and shared storage.

Nested Hyper-V Virtual Machines

It is possible to run other hypervisors as vSphere virtual machines, and even power on nested VMs. Here you can see Hyper-V running a CentOS virtual machine — all on VMware ESXi. Talk about disrupting the space-time continuum!

A couple of extra tweaks are needed to enable this, and performance is not great. Nevertheless, an amazing feat of engineering from VMware!
Do the following to enable Hyper-V on VMware ESXi:

• Add hypervisor.cpuid.v0 = FALSE to the VM configuration

• Add —-:—-:—-:—-:—-:—-:–h-:—- to the CPU mask for Level 1 ECX (Intel)

How to Access vSphere Remote Console Using vSphere & VMRC API

We can provide access to the remote console of a virtual machine in a vSphere environment to your end users. This can be accomplished by leveraging both the vSphere and VMRC (Virtual Machine Remote Console) APIs and can be useful if you are building a custom portal for users to access their virtual machines. To use the VMRC API, you can download the latest VMRC 5.1 SDK which provides the following:

The VMRC SDK allows you to use a Web-based application to connect to a vCenter- or vCloud Director-managed virtual machine and access that virtual machine’s console in a browser window. You can interact with the virtual machine console input and screen. You can also use the VMRC SDK to manage virtual and physical device connections on a vCenter-managed virtual machine.

The VMRC SDK includes documentation to the API as well as a sample webpage implementing some basic functionality of the VMRC API. I recently received a question on how to get started with the sample as it was not completely intuitive and thought I take you through the required steps to get the sample working.

Step 1 - Download the VMRC 5.1 SDK and extract the contents to your local desktop.

Step 2 - Open the vmrc-embed-example.html using a web browser located in the docs folder.

Note: In my example, I uploaded both the javascript and html file to a web server and accessed the sample by connecting to the server instead of running it locally on my desktop. This was to show how users could access the custom portal using the VMRC SDK.

Step 3 - At the top of the page where it says "VMRC Modes", make "MKS" is selected in the drop down box and click on the "+" icon to add. Then go ahead and click on the "Start" button to start a VMRC instance and ensure you see a success message on the right hand side of the console box.

Step 4 - To authenticate to VMRC, you will need a session ticket which will be obtained through the use of the vSphere API using the acquireCloneTicket() method provided by the SessionManager managed object. In this example, we will be using the vSphere MOB to quickly retrieve our session ticket, but in a real implementation, you would programamtically retrieve the session ticket along with few othe pieces of information to connect to the VMRC. Open up a new tab in your web browser and connect to the following URL:

https://reflex.primp-industries.com/mob/?moid=SessionManager&method=acquireCloneTicket

Note: Make sure you substitute in your vCenter Server IP Address/Hostname

Once you have authenticated, go ahead and click on the "Invoke Method" which should generate a session ticket:

Step 5 - Copy the session ticket string and go back to our VMRC sample page. We will now need to fill out the following sections before we can access the remote console of a virtual machine:

• Hostname (IP Address/Hostname of your vCenter Server)
• Allow SSL Validation Errors (Check this if you are using self signed SSL certificates)
• Ticket (Paste the session ticket from the previous step here)
• VM ID (This is the MoRef ID of the VM you wish to connect to the remote console)

Once you have filled out the minimum required fields, go ahead and click on the "Connect" button and if everything was successful, you should now see the remote console of the virtual machine you selected.