Hyper-V VMs in a Lab Environment

Before I start, a note on “differencing disks”… these are .AVHD files which contain a list of the changed sectors when compared with a parent VHD, and their data, and they are always dynamic.

Without its parent, a differencing disk is useless – they can be considered similar to a “differential backup” (relying on the complete backup as a base to which the changes are applied to see the result).

When a snapshot is taken of a Hyper-V VM, a new differencing disk is started and added to the chain of disks leading up to the base VHD file – whilst the “Now” is pointing to this snapshot, all the changes to the disk are written to this differencing disk alone, this is what allows a quick rollback by deleting the snapshot and reverting back to the parent version of the world.

Rolling back VM states might sound great, but never, ever do this for a Domain Controller – and bear in mind that the system will see a sudden leap into the future when its clock syncs, so think of validity periods on certificates or trial periods for software, it is also one of the reasons you should never consider a snapshot as a “backup" or run on a snapshot in a production environment for long periods of time.

 

In production environments the preferred solution when using VHDs is a fixed size disk that only has snapshots taken before making a significant change to the VM’s OS or apps, as a safety net.

The fixed size disk means the VHD file does not get fragmented or the VM have the risk of being unable to start due to there being no (physical) disk space to expand into, and as differencing disks are dynamic you want to avoid using those for the same reason (and the larger the differencing disk gets, the longer it will take to merge).

 

In lab (or PoC, or test) environments we often use cheaper, scaled-down systems to play with – which means we have to cut corners with certain luxuries, like using dynamic disks instead of fixed size disks, and being frugal with the number of VMs running simultaneously at any given time.

For some setups, though, we can cheat a little bit, so long as we are aware of the consequences…

Imagine we want to set up a lab with X Windows Server 2008 R2 servers, to emulate a AD forest and set up a Remote Desktop Services environment with RD Gateway and RD Web Access – the servers all use the same base OS but with different roles installed (and different SIDs, names, IP addresses, naturally).

So here’s what we do – create a VM with a fixed size hard disk that is “big enough” for the most heavyweight server you will have in the environment (I tend to use a 60GB VHD) and install the OS onto it.

Optional: you can now take the opportunity to install any tools in this system that might be useful for troubleshooting in your lab later – I create a Tools folder and put the latest version of the SysInternals tools in there, sometimes NetMon and the Debugging Tools for Windows get installed too.

 

Once the base image is to our satisfaction, we sysprep it, shut it down and do not restart it.

The VM we used was just to get the VHD created – it can be deleted or it can be one of the X servers for our lab, your choice.

The key thing is this – for every VM you create that points to this disk initially must have a snapshot created before it ever starts.

After the snapshot is created (practically instantaneous), the VM can be safely started and the system will resume from the sysprep state, allowing you to name and configure it to suit (I would, however, recommend doing only 1 VM at a time to avoid the VHD being a bottleneck and badly fragmenting the AVHD files).

 

PRO: Now you can set up the X servers for your environment, with the option to easily and rapidly deploy more VMs based on this OS and service pack at any time (disk space permitting).

 

CON: Here is the major caveat, and the reason this is only useful for “throwaway” lab environments (other than the obvious performance issue) – you cannot touch the original VHD which means you cannot service pack the base image.

(Remember the differencing disks are based on allocation blocks, not at the file level.)

You can use the differencing disks to apply a service pack per VM, but this will make them very large due to the amount of disk I/O and cause further fragmentation (both within the virtual disk and for the files on the physical disk).

 

So long as there is a VM in the Running or Saved state that has the VHD as its base, it should be impossible to accidentally delete the disk or start a VM which does not have a snapshot, due to a sharing violation, so there is some mitigation there, but you cannot just mark the VHD as “read only” as this will make the Hypervisor unhappy.

 

NOTE (and this is an important one):
If you delete a VM through the Hyper-V Manager when it has snapshots applied, they will get merged into the parent but the AVHD is not deleted – this makes the process take a long time whilst in the “Destroying” state, and is rather pointless as the AVHD is no longer needed.

If you intend to remove the VM, to avoid trashing your sysprep’d master VHD, first turn off or save it (no point in saving it if you intend to delete the AVHD), then edit the settings to remove the hard disk – now you can safely delete the VM (which will be very quick as there is no merging to do) and optionally the AVHD you no longer need (the parent does not keep any pointer to snapshots that refer to it, so this is safe so long as you identify the correct differencing disk.