The first task was copying the actual files, which can be done via any machine that has both datastores mounted (with read-write access to the destination store).

The more significant job is reconfiguring the VMs to use the copies of the ISOs in the new datastore.

Here’s the PowerCLI script I used:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

#
# Disconnect all CD/DVD ISOs on a particular datastore and reconnect them to the new datastore
#
$myvcenter = "myvcenter.host.net"
$mydatacenter = "BigDC1"
$originalISOstore = "MyFirstISOstore"
$finalISOstore = "MuchBetterISOstore"
 
Connect-VIServer $myvcenter
 
(Get-VM -Location: (Get-Datacenter $mydatacenter)) | ForEach ( $_ ) 
	{ 
	$myDrive = Get-CDDrive $_
	if ($myDrive.IsoPath -match "\["+$originalISOstore+"\]") 
		{
		Set-CDDrive -CD $myDrive -IsoPath ($myDrive.IsoPath -replace $originalISOstore, $finalISOstore) -Confirm:$false  
		} 
	}
Disconnect-VIServer $myvcenter -confirm:$false

It’s fairly self-explanatory.

The biggest caveat with this is that it assumes that the source and destination stores have the same structure, but it wouldn’t be difficult to amend it to change the destination path slightly.

The slot size for a cluster can be seen by going to the Summary Page for the cluster and clicking the “Advanced Runtime Info” link in the HA box.

If none of the VMs have CPU or RAM reservations, a default of 256MHz and 0GB is used.

The slots per host is derived by taking the total available CPU/RAM for the host and dividing by the slot size. Some CPU is reserved for the system so it will usually be a little lower than the full amount. So a host with 2xquad-core 2.4GHz CPUs (total 19.2GHz) and no VM CPU or RAM reservations has 73 slots and will only allow 73 VMs to be powered on if the cluster has two hosts and is set to protect against a single host failure.

Obviously this allows a very minimal amount of resource for each VM, so either reservations should be set for each VM, or slots size can be manually adjusted (see the VMware vSphere Availability Guide (pdf) for full details).

Note that the slot size is used for admission control calculations only. It has no direct effect on the resources available to VMs should an HA event occur.

There is a VMware Knowledgebase article (1010594) which  has some details of the difference in VI3 and vSphere 4.x.

Logging on to the Service Console on an affected host, “esxcfg-nas -l” also results in the same error.

The cause is invalid entries in the /etc/vmware/esx.conf file. Fortunately, it seems to be possible to remove the bad entries and the host then starts working properly without a reboot.

In our case, the bad entries looked like:
/nas/./enabled = "false"
/nas/./host = "1"
/nas/./share = "0"
whereas valid entries are recognisable:
/nas/vmdesktop/enabled = "true"
/nas/vmdesktop/host = "10.0.0.100"
/nas/vmdesktop/readOnly = "false"
/nas/vmdesktop/share = "/vol/vmdesktop"

As I mention above, fixing it on ESX isn’t too hard, just edit /etc/vmware/esx.conf using nano or vi as root, being careful not to affect any other lines.

On ESXi, it’s a little more tricky as you can’t readily log on and edit files without enabling Technical Support mode.

It is, however, possible to edit esx.conf via the Remote CLI (Linux or Windows) or using the vMA.

Below are some example commands which grabs the esx.conf file, edit it using ‘sed’, and then put the altered file back on the host.

vifs -get /host/esx.conf work.conf
cat work.conf | sed -e '/\/nas\/\./d' > fixed.conf
vifs.pl -put fixed.conf /host/esx.conf


The ‘sed’ command will probably need to change for you, depending on what the invalid lines look like. You can just use nano or vi on Linux or the vMA to do the edit, but if you’re using Windows you may find that Notepad and Wordpad either don’t display the file clearly or convert the line endings from Unix format to DOS. Using the free VIM for Windows (http://www.vim.org/download.php) will let you keep the file in the same format.

After making those changes, it was possible to add NFS datastores as normal.

I needed to add some datastores to all the clustered hosts in a single datacenter, but to skip our non-clustered standalone hosts which are used for backups.

A bit of PowerCLI which should be fairly self-explanatory:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

#
#  Add Datastores to all hosts in all clusters in a specified datacenter
#  If a host isn't in a cluster it won't get the datastore
#  Easy enough to change to do all hosts in a datacenter, all in vCenter etc
#
#  Change the value below to point it to your own vCenter
$myvCenter = "vcenter.example.com"
 
# Array of arrays below holds NFS-hostname, NFS-path and Datastore name, should be easy to add to
$nfsArray = @(
			  @("nfsserver1","/vol/nfspath1","VMstore1"),
			  @("nfsserver2","/vol/nfspath2","VMstore2"),
			  @("nfsserver3","/vol/nfspath3","VMstore3")
			 )
 
$datacenter = Read-Host -Prompt "Datacenter name"
 
Write-Host "Datacenter is $datacenter"
 
connect-viserver -server $myvCenter
 
#
# Get all hosts in all clusters in the named datacenter
$ObjAllHosts = get-datacenter -name $datacenter | Get-Cluster  |  Get-VMHost 
 
ForEach($objHost in $ObjAllHosts){
	ForEach($nfsItem in $nfsArray) {
 
      Write-Host "Adding datastore" $nfsItem[2] "with path" $nfsItem[0]":"$nfsItem[1] "to" $objHost
      New-Datastore -Nfs -NfsHost $nfsItem[0] -Path $nfsItem[1] -Name $nfsItem[2] -VMHost (Get-VMHost $objHost)
    }
}
disconnect-viserver -server $myvCenter -Confirm:$false

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…

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.