ESXI 5.1 “The disk is not thin-provisioned” after copying vmdk to new datastore

vmware-esxi

I wanted to create both an external backup as well as a 2nd ready-to-run VM on the 2nd datastore.

I removed all the snapshots, shutdown the VM and exported the OVF file to a computer, adjusted the size of the original VM, booted into Gparted to update the partition and reboot. All okay.

I then tried to deploy the OVF to the alternate datastore (235GB thin, 250 thick according to the deployment wizard). I've tried both thick and thin but receive the error "Failed to deploy the OVF. The operation was cancelled by the user".

I then manually uploaded the VMDK & OVF file to the 2nd datastore and tried to inflate but then received the message "A specified parameter was not correct. The disk is not thin provisioned.".

Based on (http://pubs.vmware.com/Release_Notes/en/vsphere/55/vsphere-vcenter-server-55u3-release-notes.html) I suspect there is something similar in 5.1. However I have no idea what to do now…and I'm concerned because it appears that my backup plan may not work if there was a critical problem.

Rob

Best Answer

A quick Google of the error you're getting (Failed to deploy the OVF. The operation was cancelled by the user) leads me to this post on the VMware Communities site.

It says

Deleted *.mf file and change settings en OVF file

Failed to deploy OVF package: The task was canceled by a user.

How misleading. I, or any other user, certainly didn’t cancel the task. So what happened? I took a look through the (horrendous) hostd.log on the ESXi box and found absolutely nothing of any value.

Frustrated by the inability to redeploy a template I spent so long preparing, I broke open the OVA template and took a look inside. There were three files with different extensions:

  1. .ova - OVF descriptor, written in XML, which describes the hardware requirements
  2. .mf – contains SHA1 checksums of the .OVA and .VMDK
  3. .vmdk – the virtual hard disk for the virtual machine.

I immediately discarded the .mf. If you modify the .ova and don’t update the .mf, it’ll complain that the checksum is invalid. Removing this file seems to prevent vSphere from checking the checksums, which is useful, seeing as we want to poke around the .ova. After fiddling around inside the .ova, I stumbled across the following line: 

<rasd:ResourceSubType>vmware.cdrom.iso</rasd:ResourceSubType>

Changing the above line, to read: 

<rasd:ResourceSubType>vmware.cdrom.atapi</rasd:ResourceSubType>

Appears to have fixed my deployment issues. Perhaps changing the ‘CD Drive Device type’ in the virtual machine’s settings would’ve fixed it. But by that point, I had already exported the OVA and deleted the source virtual machine.

Hopefully someone will stumble across this one day, and it’ll save them a few hours!

There's also an answer right below that which might work as well, given that it does basically the same thing before you export the VM/vApp:

Before creating an OVA file, in vSphere right click on the VM, open Settings, click on CD/DVD drive, check if Device Type is selected as Datastore ISO. If so, select Client Device. Save settings by clicking OK. Export OVA file, and then deploy.

Related Topic