Virtual Machines are great. I rely on them for my work every day and most of my home office network depends on several Virtual Machines (VM’s) for the core infrastructure (SMTP, DNS, AD, backup management, centralized automation, build farms, continuous integration, etc.) but sometimes you just want the abstraction and ease of use of a Virtual Machine while having full support of the host’s hardware (graphics cards, drivers, etc.) and often you don’t want to mess around with the, often complex or entangled, multi-boot scenarios. If you’re in need of that, Windows 7 (and 2008 Server R2) and their native support for Virtual Harddisks (VHD’s) will come in extremely handy. Especially now that you can install and boot your system from a VHD, directly. The following is a bit of a quick start to using VHD’s, some additional details on how I’ve been using them, and a quick look at Starwind’s free V2V conversion application.
You will need:
Preparation:
Extract or copy the installation DVD somewhere (e.g. S:\W7INS).
Put imagex.exe and bcdboot.exe (from the WAIK) and the WIM2VHD.WSF in the same location (e.g. S:\AIK). Also put bcdedit.exe in the same location (it can be found in C:\Windows\System32).
The reason for putting bcdboot.exe in the same directory is because I have had one system where the WIM2VHD script failed when it had to call bcdboot.exe which certainly was present in C:\Windows\System32 but not found by the script.
Create the VHD and install the Windows 7 image:
cscript WIM2VHD.WSF /wim:S:\W7INS\sources\install.wim /sku:ultimate
/vhd:S:\MyDisk.vhd /size:50000 /disktype:Fixed
Note that the above should be one single line. I broke it up for page layout reasons. Make sure you keep a space between “ultimate” and “/vhd:” up there.
The VHD will be created as a 50GB fixed size file as S:\MyDisk.vhd. If you wish to use a dynamic VHD you can specify Dynamic instead of Fixed for the disktype, or simply not specify the disktype (and have it default to dynamic). Also, if you do not have to specify the size a 40GB dynamic VHD will be created by default. Check the documentation on WIM2VHD for more information. After a few minutes your VHD will be ready and should contain a nearly completed pre-installation of Windows 7. But now you still need to make it bootable.
Making the VHD bootable:
First we need to get a new GUID for the boot option:
bcdedit /copy {current} /d "My New VHD Installation"
Copy the GUID that is shown and use it as a replacement for {guid} below to create the boot entry. Note that the [brackets] around the drive letter SHOULD BE there!
bcdedit /set {guid} device vhd=[S:]\MyDisk.vhd
bcdedit /set {guid} osdevice vhd=[S:]\MyDisk.vhd
bcdedit /set {guid} detecthal on
After doing all the above you should now have a bootable VHD that you can boot into for final configuration and setup. If you want to check what the boot list looks like, just use bcdedit /v on the command line. If at any time you need to remove the bootable VHD you can simply do the following. First check the boot entries using:
bcdedit /v
Look for the VHD file in the output and copy the GUID that is shown for it. Use it as a replacement for {guid} below:
bcdedit /delete {guid} /cleanup
The quick start outlined above should get your started with VHD’s. But it doesn’t end there. For advanced use you can use VHD differencing disks, mount VHD’s locally on the system, and basically have yourself an abstraction of your storage, the use of which will vary depending on your requirements.
For quick testing and discardable VHD’s I tend to go with the default 40GB dynamic disks but for performance and sustained VHD’s that I use as a more manageable alternative to multi-boot scenarios I tend to use a fixed size VHD, usually something in the range of 35GB to 120GB, depending on my purpose.
Instead of creating disk images for backup and emergency restore purposes I tend to just keep a copy of the VHD’s around and save myself the hassle of having to restore an actual image when all I need to do is copy a VHD back to its original location, if needed by overwriting the existing copy if it has been banged up badly duing some extreme development activities.
One of the benefits of native VHD support is that you can mount a VHD to a drive letter on your system and conduct maintenance and repair without having to boot into the OS on the VHD. I have found this to also be very helpful in testing various critical doomsday scenarios where an OS gets corrupted from the outside. I also use VHD’s as bootable systems on my workstations to deal with beta software that I would not allow to run free on the native system itself and would otherwise not perform too well inside a VM. Since many of these beta things in my case revolve around graphically and computationally intensive software you can understand why I would like to use the full resources of the host system, in particular graphics drivers and all the CPU’s and cores available in the system.
I can hear you thinking, why would I copy entire 100GB VHD files around while at the same time assuming that is why I have so much storage in the home office. Sometimes I do, if I want to be really quick about it. But the way I keep and store copies of VHD’s that were created with a fixed size is by converting the VHD file to a dynamically growing VHD file using Starwind’s free V2V utility. I select the VHD I wish to convert, I select what I want to convert it to, wait around for not too long, and that generates the VHD that I will “shelve” on the server or backup to long term backup storage, ready to be used and taken off the virtual shelf whenever I need it. Likewise, when I take a dynamic VHD off the virtual shelf I will use V2V to expand the VHD to a pre-allocated fixed size, again, to gain the maximum performance.
Starwind V2V is an extremely useful tool for anyone who frequently shares disk images between VMware and Windows 7 or Windows 2008 Server, Virtual PC, or the 2008 Hyper-V. It can convert VMDK (VMware) images to VHD and vice-versa, either as pre-allocated fixed size files or dynamically growing files, including support for VMware ESX Server and Starwind’s own IMG format that is used by their Starwind Server and Enterprise Server SAN solutions (but more about those next week, in another place).
Another thing that V2V will not help you with, but that should go without saying (even though I’ll make a note of it here anyway) is to share installed operating systems between VMware and Virtual-PC and/or Hyper-V. If you wish to share operating system virtual disks you should go the full route and use sysprep and properly administer the deployment process. This, however, goes a little beyond the scope of what I was writing about here.
