Hyper-V FAQs, Tips, and Tricks - Checkpoints and Snapshots

One of the topics at our Hyper-V FAQs, Tips, and Tricks discussion at TechEd was that of checkpoints and snapshots, and whether they should be used in production or not, as well as the gotchas that one may come across when using them.

Snapshots versus Checkpoints

First, I have to mention that snapshots and checkpoints are the same thing. Hyper-V calls them snapshots, and System Center Virtual Machine Manager calls them checkpoints. When you make a checkpoint in VMM, it actually creates a snapshot in Hyper-V. When you create a snapshot from Hyper-V, you'll see it in the VMM console as a checkpoint. With that out of the way, let's discuss what they are for, and when you night use one.

What are snapshots and when/why should I use them?

Snapshots are representations of a virtual machine at the point of time from which the snapshot was taken. They are most useful when you're about to make a change which you might want to quickly roll back. You can take a snapshot, make your change, and then revert back to your previous state. One of the most common scenarios is in doing software sequencing with something like App-V. You can take a snapshot of your VM, sequence the installation of your software, copy the results off of the machine, and then roll back. However, snapshots are not to be used for backup purposes. Snapshots don't behave the same way a backup would behave, and traditional backups may likely need to be used, depending on your scenario (either SAN level or from something like System Center Data Protection Manager).

When/why should I not use them? What are the "gotchas"?

Though snapshots are a valuable tool, there a few things to be aware before you ever start using snapshots. Knowing these few things will save you a lot of grief and wasted time in the future:

• Machine rollbacks can cause Active Directory connection problems
• Leaving machines running for an extended period of time after a snapshot can use up significant disk space
• Merging snapshots into existing VM can take many hours, during which the VM has to remain offline to complete the merge

Rollback to previous snapshot can cause Active Directory Password problems

The first thing to be aware of is that computers have a unique machine account password within Active Directory that by default changes every 30 days for security reasons. If the password changes between the time you take the snapshot and the time you want to rollback, you'll break the computer's access to Active Directory when you revert to the snapshot. This will in turn cause you to lose the ability to login to your VM with any domain credentials unless they were previously cached. Once you find yourself in this state, you need to login via a local account or account with cached credentials and unjoin/rejoin the computer from the domain.

To prevent this automatic password change from occurring, you can disable the automatic password reset by following the steps within Microsoft KB 154501 (thanks to Aaron Sudduth for the live link during the session). Once you flip the registry key, you can safely revert without having to worry about whether the machine is in sync with AD, since it will permanently keep the same machine account password. (This would apply to a traditional backup as well - anything which brings the VM back to a previous point in time.)

Snapshots, AVHD, and disk space

Once you take a snapshot of your VM, all of the VMs future writes will be written to a differencing disk (AVHD) rather than your original VHD. This means that over time, the AVHD will continue to grow indefinitely, even if space inside the VM isn't growing, but is merely changing alot. If you're leaving this machine up for years, it's only a matter of time before you eventually run out disk space. At that point, you have to make the decision to power down the VM and merge the snapshot into the current VM, which brings me to my final point.

Merging snapshots can mean hours of downtime

In the current version of Hyper-V, the only way you can merge the AVHD back into a VHD is by deleting your original snapshot and powering off the VM, and then waiting for Hyper-V to merge the files. Depending on the speed of your storage, and size of the AVHD, this can take minutes, hours, or days. In general, you don't have days of time that you can wait for AVHDs to merge, which means you don't want to get yourself into the situation to begin with.

Conculsion

So the moral of the story is: feel free to use snapshots and checkpoints, but only for VMs that need to be rolled back regularly, and which won't be left on for really long periods of time after the snapshot is taken. If you actually want to keep a pristine copy of your VM for months or years, use a traditional backup instead. You can do a SAN-level snapshot, a DPM backup, or a simple file copy of your VHD to external storage.

Good luck, and happy virtualizing!

Rapid Provisioning with System Center Virtual Machine Manager

During my presentations at TechEd this year, I spoke about a somewhat rarely used and somewhat unknown feature of System Center Virtual Machine Manager known as Rapid Provisioning. The feature isn't well known for a couple of reasons:

• It’s not available in the GUI – you can only access it from PowerShell.
• It’s not referred to as Rapid Provisioning from within PowerShell.

As such, generally the only people using Rapid Provisioning are those who had the feature demo’d to them by someone else, or who stumbled upon the feature while reading a blog post or doing some thorough documentation reading.

So what is it?

In short, Rapid Provisioning allows you to deploy a virtual machine using Virtual Machine Manager with all of the goodness that VMM provides (Hardware Profile, Guest OS Profile, templates), without the need of waiting for Virtual Machine Manager to do a BITS copy of the Virtual Machine from the VMM Library to the Hyper-V host, which can take awhile, and put unnecessary IO loads on your storage and network.

So how does it work?

Basically, you'd do everything identically to the way you normally do when you create a new VM, except you add one cmdlet: Move-VirtualHardDisk. This cmdlet tells VMM to not actually do the file copy, but to instead use the existing destination VHD already on the Hyper-V host. You might be asking, "Why is the cmdlet called Move-VirtualHardDisk, when it's not moving anything?" That's a good question, and one that I can't actually answer. Not everyone names their cmdlets intuitively. A better answer would probably be that it's meant to signify that you're moving a new Virtual Hard Disk into your deployment job in place of the blank VHD which was specified in the template. So you aren't actually moving a VHD across storage, but within the VMM job space.

So how does the VHD actually get to the destination?

That's up to you. There are a few ways you can accomplish the task. You can:

• Use a SAN snapshot or similar hardware solutoin to present the VHD to Hyper-V
• Use something like Virsto to present the VHD to Hyper-V.
• Manually copy the VHD from local storage to your destination location on Hyper-V (this still has the added benefit of keeping traffic off of the network).

Here's an example of a deployment script end to end.

function create-newdemoVM
{
param($vmname, $csv, $vmnumber, $CPU, $RAM)
$VMMServer = Get-VMMServer "MYVMMSERVER"
$JobGroupID = [Guid]::NewGuid().ToString()
$Template = Get-Template | where {$_.Name -eq "2K8R2_SP1_GOLD"}
$VMHost = Get-VMHost | where {$_.ComputerName -eq "MY_HYPER-V_SERVER"}
Move-VirtualHardDisk -IDE -BUS 0 -LUN 0 -Path "c:\clusterstorage\$CSV\$vmnumber\AIT_R2_SP1_ENT.vhd" -JobGroup $JobGroupID
New-VirtualNetworkAdapter  -VirtualNetwork "Guest" -VLanEnabled $false -Synthetic -JobGroup $JobGroupID
$VM = New-VM -Name $VMName -Path "c:\clusterstorage\$CSV\$vmnumber" -CPUCount $CPU -MemoryMB $RAM  -Template $Template -VMHost $VMHost -ComputerName $VMName -JobGroup $JobGroupID -UseLocalVirtualHardDisks -RunAsynchronously -JobVariable "NewVMJob" -SkipInstallVirtualizationGuestServices -FullName "Joe User" -OrgName "Acme" 
}

Let's walk this little function one line at a time. First:

param($vmname, $csv, $vmnumber, $CPU, $RAM)

Here, we're simply telling the function that we'll be calling five parameters: * VMname - the name of the VM, both at the Hyper-V/VMM level, and inside the guest OS * CSV - in this case, we're using a Cluster Shared Volume, and parameters specifies the name of the CSV from the C:\ClusterStorage path * VMNumber - in this example, we have a numbered folder within the CSV - for example C:\ClusterStorage\MYCSV1\3\ * CPU - Simply passing the number of CPUs we'd like the VM to have (overriding the template setting) * RAM - Passing the number of RAM we'd like the VM to have (overriding the temlpate setting)

Next, we set the Virtual Machine Manager server:

$VMMServer = Get-VMMServer "MYVMMSERVER"

Here, we create a new randomly generated GUID with which we can group all of the tasks together.

$JobGroupID = [Guid]::NewGuid().ToString()

The job grabs our existing template from the library where we store our W2K8R2SP1 gold image settings, inluding the Unattend file for the Sysprepped image.

$Template = Get-Template | where {$_.Name -eq "2K8R2_SP1_GOLD"}

In this step, I'm calling a specific server where I want to place the VM. Theoretically, I could use VMM Intelligent Placement here, but for simplicity's sake, I'm hard coding the destination server.

$VMHost = Get-VMHost | where {$_.ComputerName -eq "MY_HYPER-V_SERVER"}

This line is where the magic happens:

Move-VirtualHardDisk -IDE -BUS 0 -LUN 0 -Path "c:\clusterstorage\$CSV\$vmnumber\AIT_R2_SP1_ENT.vhd" -JobGroup $JobGroupID

I'm specifying that the VHD located on BUS 0 LUN 0 should be mapped the path on the destination server instead of the VHD from the VMM Library.

One last housekeeping item - I need to attach a NIC from my Guest network:

New-VirtualNetworkAdapter  -VirtualNetwork "Guest" -VLanEnabled $false -Synthetic -JobGroup $JobGroupID

And finally, the one line to create the VM itself:

$VM = New-VM -Name $VMName -Path "c:\clusterstorage\$CSV\$vmnumber" -CPUCount $CPU -MemoryMB $RAM  -Template $Template -VMHost $VMHost -ComputerName $VMName -JobGroup $JobGroupID -UseLocalVirtualHardDisks -RunAsynchronously -JobVariable "NewVMJob" -SkipInstallVirtualizationGuestServices -FullName "Joe User" -OrgName "Acme" 

So that's rapid provisioning in a nutshell. If you're interested in learning more, here's some more information from TechNet.

Feel free to leave a comment below or hit me via Twitter if you have any questions.

Good luck, and happy virtualizing!

TechEd North America 2011

I recently returned from TechEd North America 2011, where I had the pleasure of presenting three sessions this year - two on Virtualization FAQs, Tips, and Tricks, and one on Fluid Data Management at Indiana University. Unfortunately, the two Virtualizaiton FAQs sessions weren't recorded, but luckily, we took notes during the sessions, and will be posting up many of the questions and answers over the coming week or so.  I was fortunate to have three other Microsoft MVPs join me on stage for the Q&A:

Nathan Lasnoski (Virtual Machine MVP)
William Bressette (Clustering MVP)
Annur Sumar  (Clustering MVP)

Nathan posted up a round of the Q&A from the first session here (Thanks Nathan!):
http://blog.concurrency.com/infrastructure/virtualization-faq-1-presenting-at-vir471-int/

I'll follow up with another round from the Q&A, as well as post some more deep dives, in the near future.