Skip to main content

vSphere 4.1 ESXi Installable on USB?

Looking at the ESXi Installable Setup guides for 4.1 and 4.0 reveals a change. In 4.0 under System Requirements, a USB drive was listed as a possible boot device, as well as being usable for installation. So you could stick in your installation media and select USB as the destination.

Under 4.1, USB is no longer listed in the documentation as a bootable device, though boot from SAN devices via HBAs is now supported.

I’ve not checked whether you can actually install ESXi Installable 4.1 to a USB drive. It may well be possible, but I suspect it’s dropped off the “Supported” list of options.

The only reason I can see to drop support for putting Installable onto USB is to encourage people to purchase and use ESXi Embedded from their hardware supplier instead.

**UPDATE 2nd March 2011**

VMware have posted a clarification Knowledgebase article about the support for USB and SD for booting ESXi.

You can install ESXi 4.x to a USB or SD flash storage device directly attached to the server. This option is intended to allow you to gain experience with deploying a virtualized server without relying on traditional hard disks. However, VMware supports this option only under these conditions:
  • The server on which you want to install ESXi 4.x is on the ESXi 4.x Hardware Compatibility Guide.

    AND

  • You have purchased a server with ESXi 4.x Embedded on the server from a certified vendor.

    OR

  • You have used a USB or SD flash device that is approved by the server vendor for the particular server model on which you want to install ESXi 4.x on a USB or SD flash storage device.

If you intend to install ESXi 4.x on a USB or SD flash storage device while ensuring VMware support for it and you have not purchased a server with embedded ESXi 4.x, consult your server vendor for the appropriate choice of a USB or SD flash storage device.

So as I suspected, it’s only supported if you install either using “Embedded” or on a device approved by the server vendor.

It does work absolutely fine on a normal USB stick, the host that this web server runs from boots from such an item in fact. It’s just not supported by VMware.

Worth noting that an approved 2GB USB stick from HP will cost you approx £75, about 15 times the going rate…

After vSphere 4.1 – what will be going

vSphere 4.1 has been out for a couple of days now.

As well as the new features which have been covered extensively (see What’s New), the release notes list some future changes for the product range. They’re not really hidden but haven’t been given much publicity.

  • ESX will be dropped in future releases, with ESXi being the hypervisor product for vSphere.
  • Future versions of vCenter Update Manager will not scan or remediate guest OSes. I presume the cross-licensing costs of using Shavlik were outweighing any benefit. UM will continue to scan and update ESXi hosts. and presumably aid in conversion of ESX hosts to ESXi.
  • VMware vCenter Converter plugin and VMware vCenter Guided Consolidation are also going away in future versions. Converter will continue in a standalone format rather than a vCenter plugin.
  • Web Access isn’t available on ESXi so that’ll be going away when ESX is dropped too

There are a few other items being dropped such as support for some versions of Linux in guests, VMI paravirtualization support, and MSCS in Windows 2000 but they aren’t as widely used.

Passing info from PowerCLI into your VM using guestinfo variables

For a project at work we’ve been trying to pass information into a VM without connecting the VM to the network.
This is in order to set up some config within both Windows and Linux VMs. We decided to explore the use of GuestInfo variables which are held in memory in VMware Tools within the Guest VM, but which can be set from the host.

From the ESX Service Console of the host you can use
vmware-cmd <cfgfile> setguestinfo <variable> <value>
to set a value and vmware-cmd <cfgfile> getguestinfo <variable> to read the value. Note that you don’t need to use the “guestinfo.” prefix when using these commands.

Within the VM guest OS the values can be set/read using:
(Windows)
vmtoolsd.exe --cmd "info-set guestinfo.<variable> <value>"
vmtoolsd.exe --cmd "info-get guestinfo.<variable>"
(vmtoolsd.exe is usually in C:\Program Files\VMware\VMware Tools)

(Linux)
vmware-guestd --cmd "info-set guestinfo.<variable> <value>"
vmware-guestd --cmd "info-get guestinfo.<variable>"
(vmware-guestd is usually in /usr/sbin)

It wasn’t immediately obvious where the guestinfo variables live with regard to the PowerCLI vmConfig properties. Googling didn’t reveal much useful info, so I though I’d try the wonders of new technology and use Twitter. I’ve been following Carter Shanklin of VMware on Twitter since I attended a London UK VMware User Group meeting a couple of months ago, and as he’s the Product Manager for PowerCLI and the SDK, I thought I’d ask.

He quickly pointed me at the VMware SDK documentation for the ConfigInfo object and the extraConfig object in particular.

A bit of further reading led me to some experiments let me to try the following code:
$vmConfigSpec = New-Object VMware.Vim.VirtualMachineConfigSpec
$extra = New-Object VMware.Vim.optionvalue
$extra.Key="guestinfo.test"
$extra.Value="TestFromPCLI"
$vmConfigSpec.extraconfig += $extra
$vm = Get-View -ViewType VirtualMachine | where { $_.name -eq "MyVMName" }
$vm.ReconfigVM($vmConfigSpec)

That will set the guestinfo.test property to “TestFromPCLI”. Once that’s been set it can be read by the VM.

The guestinfo property can have multiple Key/Value pairs so you can pass quite a few variables through to a VM. These can only be set when a VM is powered up and running VMware Tools as the value is stored in the VMs memory, and as far as I can tell, the contents are lost when the VM reboots.

However, there is another extraConfig object which can also be set which is the machine.id. Again this can be read from within the VM (replace guestinfo. with machine.id in the above code snippets), but this one gets written to the VMs VMX config file and will thus survive reboots.

You could squish several bits of info into that one object/variable, for example a unique identifier and the VM name so that the VM can self-configure.

Unable to upgrade from Virtual Center evaluation license

I encountered a problem with Virtual Center (VC, vCenter) 2.5 Update 4 where trying to change from the evaluation license to a proper license server resulted in a message that there were “Not enough licenses for this operation”.

There were various suggestions on the web, mostly involving stopping and starting the Virtual Center and License Server services. None of them worked. The only other suggestion was to remove all the hosts from the Virtual Center, add the license, then re-add the hosts back in. This would lose any nice filing of VMs in the “Virtual Machines & Templates” view, and would generally be a bit of a pain.

As a last resort, I thought I’d have a Google round for possible registry settings which may affect licensing.

I found a blog posting about changing the license type that VC looks for within the registry, which also mentioned a “LicensePath” key.

Looking in the registry of my VC server there was no “LicensePath” key, so I created one, stopped and restart the Virtual Center service and found that VC now found the license server correctly and didn’t complain about “Not enough licenses”.

So to recap, open regedit, navigate to
HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware VirtualCenter

Create a new String key calledLicensePath and enter the info for your license server, e.g. 27000@vc01.example.com

Hostname/IP bug in ESXi 3.5 Update 3

Last week I was working on an HA cluster of VMware ESXi hosts.

Whatever I tried I couldn’t get the hosts to play nicely when HA was turned on. Further investigation showed that the hosts were resolving their own names to a previous IP address.

Checking the console on each host showed the correct information, but the error messages when turning HA on indicated that they were still resolving to their old incorrect addresses.

The usual problem with HA is that DNS records don’t match what is actually set up, but in this case DNS checked out fine.

It would appear that:

  1. ESXi uses a local ‘/etc/hosts’ file for resolving names in preference to DNS. You can view this file by pointing a browser at http://youresxservername/host/hosts
  2. The local hosts file doesn’t get updated when you change the settings using the console interface. It keeps whatever was in there the first time you set up the hostname and IP address for the host

Most of the time this doesn’t matter much as the host doesn’t often need to look itself up, but when VMware HA is turned on, name resolution becomes much more important.

There are two ways to edit the /etc/hosts file. Because ESXi doesn’t have a normal Console Operating System (COS) that full ESX enjoys, both methods are relatively awkwards.

  1. Use ‘unsupported’ mode to get a local root shell and edit using ‘vi /etc/hosts’
  2. Use the Remote CLI to change the file remotely.
    1. vifs.pl –sessionfile <yoursessionfile> –get /host/hosts C:\temp
    2. Edit the file with notepad
    3. vifs.pl –sessionfile <yoursessionfile> –put C:\temp\hosts /host/hosts

With that done HA started working again. Probably worth doing a reboot just to make sure it’s ‘taken’.