Merging snapshots in Microsoft Hyper-V R1 and R2

When you create a snapshot in Hyper-V, it freezes the original VHD files and creates a new file with a .avhd extension that is a ‘differencing disk’.  All changes are written to the AVHD file and the old VHD is only used as read-only.

When you delete the snapshot in Hyper-V, the AVHD file is not removed.  For that, you have to shut the VM down, at which point Hyper-V will automatically begin merging the AVHD file with the VHD.  Depending on the configuration of your disks, where the snapshot files are stored, and the size of the snapshot files, the merge process can be very quick or take a long time.

You should use snapshots very sparingly in a production environment anyway, but you might need to do one before a patch/software install.

By the way, VMware merges snapshots while the VM is running, without requiring any downtime.

Sizing virtual machine hosts

How do you size a virtual machine host?

There are 4 main criteria which you have to evaluate:

  • CPU
  • Memory
  • Storage
  • Network


Make sure you have CPUresources sufficient to eclipse the most demanding guest VM that you are planning to run on the host.  If you are planning on running a SQL server, get at least a quad-core proc.  Not to belittle this component, but you are unlikely to run into a problem with processor speed, since most processors are severely under-utilized as it is.  The most important thing I can say about processors is to think ahead.  IF, at some point, you think the server you are designing might be part of a VMware cluster, go look at the processor compatibility list for VMware.  Some of the features, such as fault tolerance (FT) require the exact same model processor in all the nodes in cluster.  I’m sure Microsoft Hyper-V has similar restrictions, so if Hyper-V is your preference, check the compatibility guides for Microsoft as well.


The more the better.  Memory is cheap these days.  Get as much as you can afford or as much as the physical server you are installing can support, whichever threshold you reach first.  In addition, keep in mind that with most servers, memory slot population is very important.  Doubly so when you have a dual proc config.  On top of that, VMware ESX 4 is extremely picky when it comes to the memory slot population.  Have you ever heard of a NUMA node?  Well, you don’t want to learn about it when VMware ESX fails to boot because the NUMA node requirements for your server/blade have not been met.  Most likely, if you follow the guidelines for your server on memory slot population, you will also meet the NUMA node requirements for VMware.  At least, that is what  VMware support will tell you when you call them in a panic… 🙂.  Moving along.  If you have a single or dual proc server that has fully populated memory slots, which you should, it isn’t likely to be an issue anyway.


This is the most difficult thing to get right and the hardest thing to fix if you get it wrong.  So…get it right.  For one, you are going to need more storage than you think you will need, unless you are just a gross overestimator.  Here are some of the things you need to plan for:

  • Amount of storage: you are going to need space for your OS, data, snapshots,  pagefiles, and, at least in VMware’s case, .vswp files.  A .vswp file is a file created in a datastore that is equal to the size of the amount of memory in your virtual machine; created when you boot the VM.  Not a big deal when you have a machine with 2 – 4 GB of RAM.  A bigger deal when you have a SQL VM that has 20 GB of RAM in it.  You are  also going to need room to grow.  If you are consolidating a bunch of physical servers, I would recommend adding up the total amount of used space on all of them and multiplying by at least 4.  That way, you have plenty of room to grow, and you have room to keep multiple generations of full VM backups on disk for quick restore if necessary.

  • Type of storage: this depends on what kinds of VMs you are going to be running.  To some degree, you can plan it like you would storage for separate physical servers.  Example:  say you need to put up a SQL VM.  So, that means you are going to need some fast storage, such as that provided by a RAID 10, for the log files.  And you are going to need another volume, on separate disks if possible, for the database files themselves; that can probably reside on a RAID5 or 6.  You will also need a separate volume for the OS, which can probably just be a RAID1.  If you are working on a large virtualization project, you most likely have shared storage, such as a SAN.  So, you might break out two large disks into a RAID 1 config to host the OS disks for several VMs.  Then, you can take 4 disks and carve that out for a RAID10 for high performing storage for your log files.  Then, you can take the remaining disks and partition them into a large RAID5 or 6 for general storage such as  for your database files.   These volumes can all be  shared by many different VMs.  How many will depend on what types of VMs you have and the speed and capacity of your disks.  General guidelines I have come across when learning about shared SAN storage say this:
  1. Shoot for LUN sizes of up to 500 – 600 GB
  2. Use a single LUN to support up to 15 – 20 virtual disks


Make sure you have plenty of network adapters in your physical server.  I would recommend 4 network adapters (ethernet ports) per physical server, and I will use VMware ESX to give an example.  With 4 adapters, you can dedicate one to the service console, which is where all the management traffic is handled.  Another adapter can be dedicated to VMotion.  Finally, you can either set up NIC teaming on the other two adapters in VMware and present them to your VMs as a single NIC, or just pass along two NICs to each VM and have two connections on each server.  I recommend the former, since it avoids you having to set up NIC teaming in your VM for two separate connections.

Also, a couple of websites that I would recommend for virtualization news and information:

TechTarget – SearchServerVirtualization

VMware Support (lots of documentation here, some specific to VMware, some general virtualization design info)

Microsoft Virtualization Calculator – Meeting your licensing requirements in your virtual environment

Thanks for reading!

Posted via email from Aaron Johnstone

Virtual Machine Performance Tweaks

Came across this in a TechTarget article:

Easy Mistake 1: Virtual machine screensavers
Screensavers are an absolute requirement for desktops in the hallways of our brick-and-mortar offices. They ensure that a user who walks away from his computer returns to one that has been secured against prying eyes. Screensavers can also provide protection in data centers. If screensavers on servers activate and lock the console after a few minutes of inactivity, they can protect that environment from an intruder who gains physical access.

But screensavers are a quiet consumer of processor resources. No matter how insignificant that screensaver seems, the processor power required to draw the pipes crawling across the screen or to scroll your favorite company slogan consume a percentage points of overall processor power. While that might not seem like much, consolidated virtual environments might have 10 or 15 virtual machines (VMs) running on a single virtual host. These percentage points add up when they are multiplied by the number of VMs. Even worse, if your environment uses hosted desktops through a virtual desktop implementation, this practice likely costs even more.

So turn them off. Remember that many environments enforce screensavers through group policies, which may mean an exclusion from existing group and corporate security policies.

Easy Mistake 2: Managing from the console
This second mistake is one of my favorites, because it is common among IT administrators everywhere. Do you manage your infrastructure components by remoting and logging into their individual servers? Do you run the Exchange Management Console from your Exchange server? Do you check domain name server (DNS) settings from the server’s console? Do you manage Active Directory by remoting your domain controllers?

If you are, stop.

As with screensavers, this practice is a big no-no in virtualized environments because of the level of resources required to create and maintain an instance of the Explorer shell. Just logging into a virtual machine is hard on that VM’s processor utilization. The process of creating a shell for the console can spike processor utilization during the login and logout process. Actually using any of the consoles on that server further consumes valuable resources. Logging in and accomplishing activity on your VMs’ desktops increases the amount of memory they consume.

Microsoft provides the Remote Systems Administration Toolkit, PowerShell and VBScript, as well as many other tools for efficient virtual machine management. All these lightweight tools require much less VM capacity than a traditional login. So use them, and avoid wasting processing power and memory like an amateur.

Easy Mistake 3: Antivirus and anti-malware scanning of VM disk files
Your corporate security policy might not allow for the exclusion of Virtual Hard Disk or Virtual Machine Disk Format (VMDK) files from antivirus and anti-malware scans. But be aware that the real-time scans of such products can substantially reduce the overall performance of these files — and, thus, their virtual machines. Since a VM’s processing is highly dependent on its disk subsystem, any extra activities that slow down that process slow it down as well.

That’s not to say that VM disk files shouldn’t be subject to security scanning. Scheduled scans of such files can ensure that they don’t get infected, without the processing overhead of real-time scans. Also, some of today’s more advanced scanning products are beginning to incorporate virtualization awareness to reduce their overall impact. If your security policy will allow it — or if you can bribe your security officer to look the other way — definitely consider excluding these files from your real-time scans.

Easy Mistake 4: Windows Server’s power options
At conferences around the country, I’ve encountered the final mistake repeatedly. The default power option of Windows Server 2008 upon installation is set to "Balanced." Of the three options available — Balanced, Power Saver and High-Performance — this is the second of the three in terms of overall system performance. You might save a few dollars on energy, but at the cost of wasting some of the server’s processing power. Resetting the radio button to the high-performance option has a noticeable effect on how well VMs will perform.

Group policy is probably the easiest way to do so. If you create a new policy and navigate to "Computer Configuration > Policies > Administrative Templates > System > Power Management," look for the policy called "Select an Active Power Plan." Configuring this policy across your server infrastructure ensures that you always run with highest performance.

Posted via email from Aaron Johnstone