Where I work, we love using OVA templates to speed up our deployment of virtual machines. I recently upgraded one of my servers to ESXi 5.1 (which also required an update to vSphere). ESXi 5.1 provides support for Windows 8 and Server 2012, which is incredibly useful. However, whilst building OVA templates for these operating systems, I stumbled across an issue.
I ran through the ‘New Virtual Machine’ wizard, selecting Windows 8 (or Server 2012), leaving all settings default. Installed my operating system, and made the required customisations, shutdown the machine and exported an OVA template through vSphere – excellent, how easy!
However, whilst trying to re-deploy the OVA to the ESXi 5.1 host, through the ‘Deploy OVA template’ wizard, it failed immediately after completing the wizard (right before it shows the deployment progress bar). Now, I have a particular hate for misleading error messages, and this one seems to fall right in-to that category –
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,
- .ova – OVF descriptor, written in XML, which describes the hardware requirements
- .mf – contains SHA1 checksums of the .OVA and .VMDK
- .vmdk – the virtual hard disk for the virtual machine.
I immediately discarded (renaming to .mfx will do the trick) 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!