So you’ve decided (or been told by management) that your VHD’s need to be able to work with both bare-metal and ESX (and Hyper-V). There are many different reasons why this is a valid thing to do. The major ones being portability between different hardware and the ability to use some kind of replication software (DFS-R for example) to copy your VHD to another site and automatically bring servers up there.
If you read Part 1 of this post you now know how to get your image to work between bare-metal and Hyper-V. If Hyper-V is necessary in your environment you can really do that piece before or after the process I’m about to explain. It’s kind of adjunct process.
The process for making your VHD/vDisk work with both bare-metal and ESX is mostly straightforward. It’s not the simplest procedure, but it’s the one I’ve found that consistently works.
The first thing you want to do is go to http://www.starwindsoftware.com/converter and download the V2V Converter. You can use XenCovnert to go P2V or V2P or use the VMWare Converter to do the same, but those utilities all insert their own little functionality which manages to break your VHD. the V2V converter does a block level conversion from an ESX .vmdk to a standard .vhd and vice-versa.
You’ll want to install this utility on the Citrix Provisioning Server, or wherever you’re hosting your vDisks.
- Boot your vDisk into Private Mode on one of your bare metal servers
- Copy the PVS Target Device software to a local temp directory. Also copy any other software/drivers you might need. When you convert the .vhd to a .vmdk you will NOT have any network access. (You could also mount your .vhd on the PVS server directly and copy the files into the temp location.)
- Shut down the bare-metal server and physically copy the .vhd file to a temp location on the PVS server.
- Run Starwinds V2V Image Converter.
- Browse to the source VHD and click Next
- Select VMWare Growable Image and click Next (assuming you thin-provision)
- IMPORTANT: Select IDE disk, even if it’s not.
- Select the name/location of the output .vmdk
- Let the conversion go…
- Install the vShphere client on your PVS server. Open it and log into vCenter.
- Browse to your datastores and create a Folder for your temp VM.
- Upload the .vmdk to this folder
- Create a new virtual machine. Give it 2 processors, however much memory you want, specify the E1000 NIC (super important for PVS), then UNCHECK the “Connect at Power on” box. You don’t want this bad boy on the network.
- When you get to the Virtual Disk screen select “use an existing” and browse to your uploaded .vmdk in the store.
- Power on the VM
- Log into the console with cached creds.
- Install the VMWare tools to get the appropriate drivers installed.
- Go to Control Panel and uninstall the Citrix Provisioning Services Target Device x64 software.
- Log back in and reinstall the Target Device Software from your temp location. You remembered to copy it in, right?
- When it’s done, make sure all your NICs are checked and click OK. You should see at least one that is inactive.
- Power off the VM
- Repeat the above steps to download the .vmdk from the datastore back to your local temp location.
- Open the StarWind V2V Image Converter.
- Select the new .vmdk file (you’ll probably see temp.vmkd and temp-s001.vmkd, select the temp.vmdk)
- Select the destination as “MS Virtual PC growable image” and click Next. Again, this assumes you’re thin-provisioning.
- Select the output filename/location.
- When done, just copy the .vhd back into the PVS datastore and import it as usual.
As convoluted as that sounds, that’s really all you need to do. Your image will now be able to boot between both ESX and bare-metal. You’ll of course want to clean up the image a bit. Uninstall any hardware agents (HP SIM, etc.). And you’ll get some errors in the logs when you boot that it can’t find so-and-so hardware, but for the most part you should be set.
I’ve got my images booting between bare-metal (HP GL460c G6), Hyper-V, and ESXi 4. It’s pretty slick and took months to figure out the right order for everything but it now runs like a dream.
Of course if you followed the Citrix best-practices you were already using ESX or XenServer (same process, btw), so you probably don’t have this problem. But if you’re like most people don’t RTFM you’ll hit this pickle at some point.