RoudyBob.NET

I’m not going to partake in the lively discussion of late about which company’s virtualization hypervisor product is the best. It may prove to be the technology world’s version of “The Pepsi Challenge” for all that I know…in the end, it may just be a matter of what each person prefers. Generally speaking, the more I work with Hyper-V the more I come to appreciate the fact that it does perform well and is (at least from my perspective) reliable. Having worked with virtualization technologies for several years and being very familiar with how VMware and other virtualization solutions work, however, there are some things which do leave me scratching my head. You might say it’s just because I’ve been conditioned in a certain way. I’d argue that if it were possible for me to be conditioned, I’d probably still be married.

The issue is this: file paths. It might seem minor, but Hyper-V makes managing the location of VM files about as difficult as possible from what I can tell. It might help to start with a summary of the different types of files you might find associated with a particular virtual machine running on a Hyper-V host:

*.VHD - Primarily these are the files that hold all the data for a particular volume associated with a virtual machine. VHDs have been around for quite some time and Microsoft has been pretty open about making the specification available and integrating it throughout the product line – i.e., the backup application Windows Server 2008 has can save backups as VHD files. Technically speaking, they’re just a file format which provides the ability for a virtual machine’s hard disk to reside on a native host file system encapsulated within a single file. Literary geeks take note. There might be a bit of foreshadowing with my use of the word ‘encapsulated’ here.

*.AVHD - Hyper-V provides the ability to take snapshots of a virtual machine so that you can revert back to a previous version of the OS, applications and data very easily. These snapshots can be taken at any time (whether the VM is powered on or not) and work with any OS running within the virtual machine. Generally, most consider this to be a handy feature. Just like Cher, you can turn back time easily to revert to a previous version of your VM. When you take a snapshot of a virtual machine, its .VHD files are “frozen” and subsequent disk writes within the VM are instead stored in a .AVHD file. You can end up with a whole slew of .AVHD files depending on how often you take snapshots and whether or not you decide to create branches within your snapshot lineage. There’s a ton of information on the InterTubes about how Hyper-V snapshots work if you want more detail.

*.XML - Hyper-V stores a virtual machine’s configuration information (number of processors, devices associated with the VM, amount of memory, etc.) in an industry-standard XML file which is named using the Globally Unique Identifier (GUID) for the associated virtual machine. (More foreshadowing…) This is good for interoperability or for solutions that want to perhaps leverage the information in some way.

*.BIN and *.VSV - When you pause or take a snapshot of a running virtual machine, Hyper-V stores the contents of the virtual machine’s RAM in a .BIN file and information about the current state of the running virtual machine in a .VSV file. These two files are used together to resume the virtual machine from the point at which it was paused.

One of the great things about virtualizing workloads is the fact that once you do so, that workload is encapsulated. This means that everything about that workload – the OS, applications and data are all packed up nicely in a few files and easy to move around between physical hosts. They’re also abstracted from the underlying host hardware so it’s easy to move VMs between different makes and models of server hardware. With Hyper-V, then, by keeping all of my .VHD, .AVHD, .XML, .BIN and .VSV files together I can easily move an entire VM from one Hyper-V host to another.

Well, not really.

The default path for Hyper-V VHDs is C:\ProgramData\Microsoft\Windows\Hyper-V\Virtual Hard Disks. The default path for Hyper-V Snapshots is C:\ProgramData\Microsoft\Windows\Hyper-V\Snaphots and the default path for Hyper-V configuration files is C:\ProgramData\Microsoft\Windows\Hyper-V. So, instead of storing everything together, each of the three pieces of a VM are spread across multiple directories. If your first inclination is to change the default path for your VHDs, then that means they’re spread across three different directories on at least two different disks.

What’s really crazy is that all pieces of a VM must be accessible for a VM to work properly. So, if you’re thinking about using Quick Migration to move VMs between cluster nodes you had better make sure you change the default locations for configuration files and snapshots in addition to VHDs so that everything lives on the cluster’s shared storage. Making sense of which files are part of a VM is nearly impossible, too, since Hyper-V uses a 32 character GUID-style naming scheme…and the name of the VM’s configuration file doesn’t correspond with the names used for its snapshot files.

I know what you’re thinking now. You’re wondering why you can’t just go locate all the bits and pieces and copy them to a single location after the fact? Well, once a VM has been created and a snapshot has been taken, there’s no way to change the location of that VMs snapshots. It doesn’t really matter anyway, because Microsoft doesn’t support just copying all of the files that make up a VM and moving it to a different host. You have to use a sanctioned Import/Export utility to do that and some people aren’t too happy about it.

The lesson to be learned here is to pay very close attention to planning where VM-related files are going to be stored on your Hyper-V host. If you’re planning on using Quick Migration with Failover Clustering, you want to be sure that everything is stored on a shared disk. If you want to be able to move individual VMs between cluster nodes, also be sure to put each VM on its own shared disk (or LUN) because Failover Clustering moves entire disks between nodes rather than particular directories. Even if you’re not using Quick Migration, it’s important to think about paths because performance and available disk space could become concerns. VHDs should be moved to a separate disk from the OS for better performance and snapshots should be stored separately as well to prevent yourself from unknowingly running your system volume out of space. VM configuration files should probably be moved as well – by default the current version of the VM saves its saved state information to a subdirectory under the configuration files location and pausing VMs that have 2GB or even 4GB of RAM assigned could take up space rather quickly.