Explaining the Hyper-V authorization model, part five

Hyper-V uses a role based authorisation model for access checks. This series of articles takes a look at the model; defines the available primitives; and walks through a couple of examples. (I actually wrote most of this many months ago – only finally found the time to post it up!).

Quick links: Part1; Part 2; Part 3; Part 4  

This post describes a change to the authorisation model in Hyper-V for Windows Server 2008 R2. If you recall from part one, I mentioned that there are 33 operations defined in AZMan for Windows Server 2008, and 34 operations for Windows Server 2008 R2.

The new operation has ID 355, ‘Allow Virtual Machine Snapshot’.

Why (to me) is this useful? Have you ever been confronted with a screen such as the following where you want to make Hyper-V Manager the foreground application, but accidentally hit the ‘Snapshot’ action in the MMC? I assure you, I have, several times.

The problem with accidentally hitting that action is that you could now find your production virtual machine using a differencing disk, with reduced performance (at least in v1 – not the case in R2), or the possibility of physical disk space running out. Further, to merge the changes back to the parent VHD so that a differencing disk is no longer being used, you need to delete the snapshot, shut down the virtual machine, wait for the merge to complete and then restart the VM. This is particularly painful when the VM in question is your ISA server for outbound Internet connectivity, or your Exchange server your clients (wife and children in my case) are using for email?

In part six, I’ll look at a solution that I personally use at home on my Windows Server 2008 R2 production environment that builds on what’s been learnt so far to ensure that I can’t accidentally snapshot critical production VMs, but am able to snapshot test VMs to my hearts delight.

Cheers,
John.

Comments

• Anonymous
  October 30, 2009
  Nice one John! You have been very helpful!