Rules to Better Hyper-V
RuleSummaryIntro
Hold on a second! How would you like to view this content?
Just the title!
A brief blurb!
Gimme everything!
Page Content
This is an advanced topic. The pre-requisites are that you already have Clustered nodes setup, and then your SAN.
Then you enable your Hyper-V role on your cluster.
First refer to all rules listed in "Rules to Better Hyper-V" as these are the basics for Hyper-V.
- Figure: The following rules are referring to the 2nd column on Hyper-V (this also tells you why choose Hyper-V Live Migration over VMWare VMotion)
Let's continue with the rules specially for clustering...
When SysAdmins first get going with Hyper-V, they often choose to use dynamically expanding VHD’s. They often do this to increate VHD creation time and reduce hard disk usage.
The problem with dynamically expanding VHD’s is that they reduce the performance of the Virtual Machine. It is much better to use a fixed VHD when the Virtual Machine is used in a production environment.
Microsoft lists several recommended and supported network configurations. It is very important that you configure your Hyper-V Cluster with one of the supported network types otherwise you will have performance issues once you load up the cluster.
Figure: Check you have one of the supported configurations listed on the >Microsoft Hyper-V Live Migration – Network Configuration page (this example has 3 networks)
It may work fine initially on a non-supported configuration but when you start loading more Virtual Machines on to the cluster the performance will be degrade dramatically.
When formatting a new virtual disk you have attached to a Hyper-V Virtual Machine, you can choose to to format the disk as a
Basic disk or
Dynamic disk.
A
Dynamic disk might be useful in situations where you want to create a software RAID array, but when using Hyper-V this not a good idea because it prevents Microsoft Data Protection Manager (DPM) from doing Child State Backups (backups while the machine is running).
For this reason, never use
Dynamic disks inside Hyper-V Virtual Machines.
Figure: Bad Example - DPM cannot backup this Virtual Machine's child state as it has a Dynamic Disk
Good example – Using Basic Volumes allows DPM to backup the Virtual Machine’s child state
Having the network flooded with a virus is bad news – but it will be worse news if iSCSI traffic is going across the same network. This is why you should have your iSCSI or SAN traffic on a different VLAN.
Figure: A managed switch allows VLANing
Note: An even better and more expensive solution is purchase a separate Switch for each network (this example means 3 network adapters = 3 networks)
Occasionally when you estimate the size of a VHD that you will be using in a server, you can get it wrong and you will need to give the Virtual Machine some more space. Instead of adding a bigger data disk in the Virtual Machine and migrating data, you can expand the existing disk.
When your Hyper-V environment is spread across multiple hosts and contains many Virtual Servers, it can get very confusing to find the one you are looking for amongst them all. This is why you should use a standard naming convention for all your Virtual machines.
Bad Example - How do you know what machine is what?The standard we use for Production Virtual Machine naming is as follows:
NetBIOSName-ServiceName
For example:
Falcon-SCVMM
The standard we use for Development Virtual Machine naming is as follows:
DEV-NetBIOSName-ServiceName-DeveloperInitials
For example:
DEV-demo2010a-SP2010MSInfoWorker-JL
Good Example - It is easy to tell which VM is which when they are named to a standard
If you need to move a virtual machine from one Hyper-V server to another, you should using the Hyper-V Managers export option rather than just moving the VHD files.
If your machine has snapshots and you copy them rather than export them, it can cause issues with the VHD’s and AVHD’s (Snapshot VHD’s) because Hyper-V does not know there has been a snapshot when you load it onto the new Hyper-V Host. You also lose the settings for your Network Adapter, like its static IP address.
To export a Virtual Machine from the
Hyper-V Manager:
- Right click on it when it is shut down and clicking Export...
- Choose the location you wish to export the Virtual Machine to and click on Export
Don't log in and make manual changes to the clustered nodes.
When working with clustered environments it is important that settings be consistent across every node. The best way to handle this is through group policy.
Create a policy that you would like applied to each node of the cluster using the Group Policy Management.
Figure: Bad Example - Do not manually change settings on each node
Figure: Good Example - Changing settings through Group Policy keeps node settings the same
It is important have the Live Migration and Cluster traffic on a separate network interface than the iSCSI or SAN traffic. If you do not you will see a performance hit while migrating virtual machines and the process will be a lot slower.
To specify the roles of each network adapter:
- Open the Failover Cluster Manager
- Expand the Networks section and you will see all of your network adapters listed
- Right click on the network that you are using for LAN and ISCSI and make sure that the following setting is selected
Figure: Network properties window
This setting prevents ISCSI and LAN traffic from going over the cluster network
Snapshots are a very convent way to back up a system before a big change is made. It is important to note that Microsoft does not support snapshots of running systems. This is because a snapshot is taken of the system exactly as is, with open connections and interrupt requests. For more information on this you can read Brian Harry’s blog post here: http://blogs.msdn.com/bharry/archive/2010/02/10/a-tfs-2010-upgrade-success-story.aspx
This is why you MUST shut down your server before taking a snapshot.
- Shutdown the virtual server
- In the Hyper-V Manager, ensure the Virtual Machine has the state of Off
- Right click on the virtual machine you wish to snapshot and click Snapshot
- The snapshot should run very quickly and you will notice the snapshot in the Snapshots area of the Hyper-V Manager

You will see the snapshots associated with a Virtual Machine when you click on them
- You can start your server back up again
Snapshots are a very handy tool for a System Administrator, but they can quickly turn into a nightmare if they are not managed properly. Snapshots take far more hard drive space than a virtual machine without, and if you don’t clean up your snapshots you may run out of drive space.
Figure: Snapshots are useful, but they can take up a lot of space
When you delete a snapshot you can no longer restore the virtual machine to the point in time the snapshot was taken. Deleting a snapshot does not affect any other snapshots, nor will it affect the current state of the virtual machine.
Set yourself a calendar reminder 3 weeks after you make a snapshot so you remember to apply the snapshot to the Virtual Machine (assuming you are happy with the virtual machine after the snapshot).
- In the Hyper-V Manager, click on the virtual machine you want to apply the snapshot to
- In the Snapshots window, right click on the snapshot you wish to apply and click Delete Snapshot…
- Confirm the snapshot deletion.
- Wait for the merge process to complete (this may take a while if you have had the snapshot running for a long time and it has grown large in size).
As Hyper-V Clustering requires some advanced networking technologies make sure you download the very latest drivers for all your network cards – don’t just rely on the out of box driver.
Being able to communicate with the domain is so important for Hyper-V and clustering. To protect yourself from Active Directory problems, you can completely separate your primary Active Directory domain.
Having a separate Active Directory domain will allow your Hyper-V machines to run without problems in the case that your main Active Directory domain fails for any reason.
When you setup a new Active Directory domain for your Hyper-V cluster, create a trust between to 2 domains.
It is important to properly decommission a Virtual Machine rather than just delete it. Developers have a knack for leaving important files everywhere, and inside a Virtual Machine is no exception.
- Let the people that may have been using the Virtual Machine that it is going to be decommissioned. This might be difficult if it was being used for testing or staging.
- Make a text file that matches the name of the Virtual Machine.
- Note down the Virtual Machines static IP address in the text file.
- Check the DNS Manager on a domain controller and note down any DNS names that pointed to the IP Address of the Virtual Machine.
- Copy the Virtual Machines folder to a file server or backup drive.
- Copy the text file into the same location.
- Set a calendar reminder for yourself to delete the Virtual Machine if it hasn’t been requested in 3 months.
When clustering it is important that the software setup of each node in a cluster is identical. It is also important to have a stable Active Directory. For this reason, each node of your cluster should be an Active Directory domain controller, and a Global Catalog server.
To improve performance, it's a good idea to disable NetBIOS over TCP/IP on your cluster NIC and iSCSI NIC. NetBIOS isn't used in Server 2008 R2 clusters.
Figure: Good example – the NetBIOS is disabled on the dedicated NIC's (iSCSI & Cluster Communications)