News

Storage VMotion Bug

I've been tinkering with Storage VMotion quite a bit lately as the org where I work recently purchased a new storage array and we've been trying to vacate the old one. Lucky for me VMware also introduced Storage VMotion just last month ( Dec 21st ) with the release of VMware ESX 3.5.


But when I went to migrate the data from one storage array to another ( one of which is unsupported in ESX 3.5.0 at this time ), I had about a 15% failure rate. The VMs would get to 99% complete, and then fail ungracefully. The failure would halt the operation of the VM, not commit the snapshot that was used during the process and not update the .vmx to point to the new .vmdks ( on the target lun ) so the VM would have to be manually manipulated before it would power on again. The error in VirtualCenter reported:

Received an error from the server: A general system error occurred: DMotion: 
Failed to unstun VM after disk reparent. You will have to manually 
perform the relocation.

Several threads about users with similar problems were spawned on the VMTN message boards, and one of the VMware employees appears to have identified the source of the problem to be VMs that have the 'thinProvisioned' flag set in their .vmdk header file. It seems that even if your VMs were only spun up from a template that was thin provisioned, that the flag carries ( erroneously ) to the .vmdk of the VM which is not thin provisioned.


You can check to see if your .vmdks have the thinProvisioned flag by looking at the header of the your .vmdks. As you can see below I have put the problem flag in bold.

# Disk DescriptorFile
version=1
CID=dee36311
parentCID=ffffffff
createType="vmfs"

# Extent description
RW 41943040 VMFS "VM01-flat.vmdk"

# The Disk Data Base 
#DDB

ddb.adapterType = "lsilogic"
ddb.geometry.sectors = "63"
ddb.geometry.heads = "255"
ddb.geometry.cylinders = "2610"
ddb.uuid = "60 11 C4 90 87 a8 e8 12-89 ff 22 11 96 40 eb cd"
ddb.thinProvisioned = "1"
ddb.toolsVersion = "7299"
ddb.virtualHWVersion = "4"

VMware was very responsive to the problem even though one of the storage arrays that I was utilizing was not on the HCL. I have also been informed that VMware plans to make a announcement either today or Monday on how they plan to address the issue.

Labels: storage vmotion bug

Posted by Dominic Rivera at Friday, January 25, 2008.