Cluster validation error – the wrong diskette is in the drive

While configuring a new MSCS Cluster in VMware ESXi 5.1 I encountered the following error when running the Cluster Validation Tool:

The wrong diskette is in the drive
Insert %2 (Volume Serial Number: %3) into drive %1.

I was very surprised to see an error indicating that the problem was with a diskette. Obviously this wasn’t right, my suspicion was that it was storage related so I requested a SAN Engineer to take a closer look. The cursory checks were made such as ensuring PR (Persistent Reservations) was set on the LUN but no glaringly obvious causes were identified.

After trying a few things (and failing) I ‘cleaned’ the clustered disks, which fixed the problem. This involved converting the disks from GPT to MBR and then back again. The following steps  were performed:

  1. Open Disk Management by running diskmgmt.msc from a command prompt
  2. The disk contained a volume, so right-clicked on the volume (within the disk) and then clicked Delete Volume.
  3. Right-clicked the GPT disk and then clicked Convert to MBR disk.
  4. Once the disk had converted to MBR I right-clicked on it and then clicked Convert to GPT disk.

I then re-ran the Cluster Validation Test and it passed successfully!

Reference:
Change a GUID Partition Table Disk into a Master Boot Record Disk
Change a Master Boot Record Disk into a GUID Partition Table Disk

High I/O on VM causes clone to fail

When creating a hot clones of VMs that have high I/O you may encounter the following error:

Cannot create a quiesced snapshot because the snapshot 
operation exceeded the time limit for holding off I/O in the 
frozen virtual machine

This is s common issue when trying to perform clones of very busy production servers such as SQL Server or Exchange Server. As these applications perform constant reads/writes the usual quiescing function (when initiating a clone or snapshot  fails to flush all of the operations to disk. Below is an example of this error when trying to hot clone a very busy Exchange server:

A quick and dirty fix if you simply want to clone the VM is to stop the VMware Tools Service on the guest and then re-run the clone. It should complete OK. This basically bypasses the quiescing of the file system and produces a crash-consistent clone:

VMware KB article 1018194 highlights this issue and prescribes various fixes depending on your circumstance.