Intel Sandy Bridge Processors Require W2008 R2 SP1 for Hyper-V

If you plan to run Hyper-V on machines that have Intel Sandy Bridge CPUs then you will need to deploy Service Pack 1, either in the form of the add-on or integrated build for Windows Server 2008 R2 or Hyper-V Server 2008 R2.  That’s according to a Microsoft blog written by “Blauge”.

This is because of a new AVX instruction in the CPU.  It seems that a VM will fail to start on a host with this CPU type without SP1.  You’ll get this error:

<VM Name> could not initialize

The fix is to install SP1.

According to Wikipedia, the AVX “instruction set is an advanced form of SSE and is suited for floating-point-intensive applications.  The two-operand instruction limit is increased to three operands, and advanced data rearrangement functions are included.  New features include mask loads, data permutes, increased register efficiency and use of parallel loads, as well as smaller code size.  The AVX instruction provides up to double peak FLOPS performance compared to using SSE4 instructions on CPUs”.  That’s Martian to me, to be honest, but it sounds like more CPU horsepower.

Some Downloads For You To Consider: iSCSI and SCVMM

Microsoft was busy yesterday and released a bunch of downloads that you might be interested in.

Microsoft iSCSI Software Target 3.3

One of the challenges of trying out things like Hyper-V and clustering in a lab is the storage.  SANs are expensive.  There are solutions like Windows Storage Server (sold as OEM on storage appliances) and StarWind (a economic and highly regarded iSCSI target to install on Windows Server).

Now, if you want a simple iSCSI target that you can download and install, you can do it.  Jose Bareto blogged about (with instructions) the Microsoft iSCSI 3.3 target being available to the general public.  This was previously only available as a part of Storage Server.  Now you can download it and install it on a Windows Server 2008 R2 machine to create a simple iSCSI storage solution.  So if you want a quick and cheap “SAN” to try out clustering … you got it!

This isn’t limited to the lab either.  The iSCSI target is supported in production usage.  So if you need a cheap shared storage solution for a cluster, this is one way you can go.  Sure, it won’t match a SAN appliance for functionality or performance, and the likes of StarWind and Datacore offer other features, but this opens up some opportunities at the lower end of the market.

SCVMM 2012 MpsRpt Beta Tool

A lot of people are trying out the beta for System Center Virtual Machine Manager 2012.  I keep telling people that the virtualisation folks in Microsoft are serious about gathering and acting on feedback.  This is evidence of that.  This tool will enable support for collecting trace logs in SCVMM 2012 Beta.  Documentation is available here.

System Center Virtual Machine Manager 2008, 2008 R2, and 2008 R2 SP1 Configuration Analyzer

This tool has been updated to add support for SCVMM 2008 R2 SP1.

“The VMMCA is a diagnostic tool you can use to evaluate important configuration settings for computers that either are serving or might serve VMM roles or other VMM functions. The VMMCA scans the hardware and software configurations of the computers you specify, evaluates them against a set of predefined rules, and then provides you with error messages and warnings for any configurations that are not optimal for the VMM role or other VMM function that you have specified for the computer.

Note: The VMMCA does not duplicate or replace the prerequisite checks performed during the setup of VMM 2008, VMM 2008 R2, or 2008 R2 SP1 components.”

Mastering Hyper-V Deployment Excerpts

Sybex, the publisher of Mastering Hyper-V Deployment, have posted some excerpts from the book.  One of them is from Chapter 1, written by the excellent Patrick Lownds (Virtual Machine MVP from the UK).  As you’ll see from the table of contents, this book is laid out kind of like a Hyper-V project plan, going from the proposal (Chapter 1), all the way through steps like assessment, Hyper-V deployment, System Center deployment, and so on:

Part I: Overview.

  • Chapter 1: Proposing Virtualization: How to propose Hyper-V and virtualisation to your boss or customer.
  • Chapter 2: The Architecture of Hyper-V: Understand how Hyper-V works, including Dynamic Memory (SP1 beta).

Part II: Planning.

  • Chapter 3: The Project Plan: This is a project with lots of change and it needs a plan.
  • Chapter 4: Assessing the Existing Infrastructure: You need to understand what you are converting into virtual machines.
  • Chapter 5: Planning the Hardware Deployment: Size the infrastructure, license it, and purchase it.

Part III: Deploying Core Virtualization Technologies.

  • Chapter 6: Deploying Hyper-V: Install Hyper-V.
  • Chapter 7: Virtual Machine Manager 2008 R2: Get VMM running, stock your library, enable self-service provisioning.  Manage VMware and Virtual Server 2005 R2 SP1.
  • Chapter 8: Virtualization Scenarios: How to design virtual machines for various roles and scales in a supported manner.

Part IV: Advanced Management.

  • Chapter 9: Operations Manager 2007 R2: Get PRO configured, make use of it, alerting and reporting.
  • Chapter 10: Data Protection Manager 2010: Back up your infrastrucuture in new exciting ways.
  • Chapter 11: System Center Essentials 2010: More than just SCE: Hyper-V, SBS 2008 and SCE 2010 for small and medium businesses.

Part V: Additional Operations.

  • Chapter 12: Security: Patching, antivirtus and where to put your Hyper-V hosts on the network.
  • Chapter 13: Business Continuity: A perk of virtualisation – replicate virtual machines instead of data for more reliable DR.

Linux Integration Components 2.1 RTM

You wanted 4 virtual CPU’s in a Hyper-V Linux virtual machine?  You wanted clock sync and host shutdown sync?  Now you got it!

Ben Armstrong has just blogged that the version 2.1 integration components (or services if you are a VMM head) are released.  Mike Sterling is the man in the know so you can read what he has blogged to get all the news.  BTW, I included this version of the IC’s in Mastering Hyper-V Deployment. *end shameless plug*

This release is a huge step forward in gaining acceptance for Hyper-V from the Linux admins because SLES and RHEL are really equal citizens on Hyper-V now.  Now we just need VMM to catch up 😉

Thoughts on Hyper-V VDI Hosts

Lots of out-loud thinking here ….

If you put a gun to my head right now and asked me to pick a hardware virtualization solution for VDI then I honestly wouldn’t pick Hyper-V.  I probably would go with VMware.  Don’t get me wrong; I still prefer Hyper-V/System Center for server virtual machines.  So why VMware for VDI?

  • I can manage it using Virtual Machine Manager.
  • It does have advanced memory management features.

The latter is important because I feel that:

  • Memory is a big expense for host servers and there’s a big difference between PC memory cost and data centre memory cost.
  • Memory is usually the bottleneck on low end virtualisation.

Windows Server 2008 R2 Service Pack 1 will change my mind when it RTM’s thanks to Dynamic Memory.  What will be my decision making process then, because we do have options.  You can always switch to Hyper-V then if you have to push out VMware (free ESXi) hosts now.

Will I want to make the VDI virtual machines highly available?

Some organizations will want to keep their desktop environment up and running, despite any scheduled or emergency maintenance.  This will obviously cost more money because it requires some form of shared storage.  Thin provisioning and deduplication will help reduce the costs here.  But maybe a software solution like that from DataCore is an option?

Clustering will also be able to balance workloads thanks to OpsMgr and VMM.

Standalone hosts will use cheaper internal disk and won’t require redundant hosts.

Will I have a dedicated VDI Cluster?

My thinking is that VDI should be isolated from server virtualisation.  This will increase hardware costs slightly.  But maybe I can reduce this by using more economic hardware.  Let’s face it, VDI virtual machines won’t have the same requirements as SQL VM’s.

What sort of disk will my VDI machines be placed on?

OK, let me start an argument here.  Let’s start with RAID:  I’m going RAID5.  My VDI machines will experience next to no change.  Data storage will be on file servers using file shares and redirected folders.  RAID5 is probably 40% cheaper than RAID10.

However, if I am dynamically deploying new VM’s very frequently (for business reasons) then RAID10 is probably required.  It’ll probably make new VM deployment up to 75% faster.

What type of disk?  I think SATA will do the trick.  It’s big and cheap.  I’m not so sure that I really would need 15K disk speeds.  Remember, the data is being stored on a file server.  I’m willing to change my mind on this one, though.

The host operating system & edition?

OK: if the Hyper-V host servers are part of the server virtual machine cluster then I go with Windows Server 2008 R2 Datacenter Edition, purely because I have to (for server VM Live Migration).

However, I prefer having a dedicated VDI cluster.  Here’s the tricky bit.  I don’t like Server Core (no GUI) because it’s a nightmare for hardware management and troubleshooting.  If I had to push a clustered host out now for VDI then I would use Windows Server 2008 Enterprise Edition.  That will give me a GUI, Failover Clustering, and Live Migration.

If I had time, then I would prepare an environment where I could deploy Hyper-V Server 2008 R2 from something like WDS or MDT.  That would allow me to treat a clustered host as a commodity.  If the OS breaks, then 5 minutes of troubleshooting, followed by a rebuild with no questions asked (use VMM maintenance mode to flush VM’s off if necessary).

Standalone hosts are trickier.  You cannot turn them into a commodity because of all the VM’s on them.  There’s a big time investment there.  They lose points for this.  This might force me into troubleshooting an OS (parent partition) issue if it happens (to be honest, I cannot think of one that I’ve had in 2 years of running Hyper-V).  That means a GUI.  If my host has 32GB or less of RAM then I choose W2008 R2 Standard Edition.  Otherwise I go with W2008 R2 Enterprise Edition.

I warned you that I was thinking out loud.  It’s not all that structured but this might help you ask some questions if thinking about what to do for VDI hosts.

Rough Guide To Setting Up A Hyper-V Cluster

EDIT: 18 months after I wrote it, this post continues to be one of my most popular.  Here is some extra reading for you if this topic is of interest:

A lot of people who will be doing this have never set up a cluster before.  They know of clusters from stories dating back from the NT4 Wolfpack, Windows Server 2000 and Windows Server 2003 days when consultants made a fortune from making things like Exchange and SQL on 5 days per cluster projects.

Hyper-V is getting more and more widespread.  And that means setting up highly available virtual machines (HAVM) on a Hyper-V cluster will become more and more common.  This is like Active Directory.  Yes, it can be a simple process.  But you have to get it right from the very start or you have to rebuild from scratch.

So what I want to do here is walk through what you need to do in a basic deployment for a Windows Server 2008 R2 Hyper-V cluster running a single Cluster Shared Volume (CSV) and Live Migration.  There won’t be screenshots – I have a single laptop I can run Hyper-V on and I don’t think work would be too happy with me rebuilding a production cluster for the sake of blog post screenshots 🙂  This will be rough and ready but it should help.

Microsoft’s official step by step guide is here.  It covers a lot more detail but it misses out on some things, like “how many NIC’s do I need for a Hyper-V cluster?”, “how do I set up networking in a Hyper-V cluster?”, etc.  Have a read of it as well to make sure you have covered everything.

P2V Project Planning

Are you planning to convert physical machines to virtual machines using Virtual Machine Manager 2008 R2?  If so and you are using VMM 2008 R2 and Operations Manager 2007 (R2), deploy them now (yes, before the Hyper-V cluster!) and start collecting information about your server network.  There are reports in there to help you identify what can be converted and what your host requirements will be.   You can also use the free MAP toolkit for Hyper-V to do this.  If your physical machine uses 50% of a quad core Xeon then the same VM will use 50% of the same quad core Xeon in a Hyper-V host (actually, probably a tiny bit more to be safe).

Buy The Hardware

This is the most critical part.  The requirements for Hyper-V are simple:

  • Size your RAM.  Remember that a VM has a RAM overhead of up to 32MB for the first GB of RAM and up to 8MB for each additional GB of RAM in that VM.
  • Size the host machine’s “internal” disk for the parent partition or host operating system.  See the Windows Server 2008 R2 requirements for that.
  • The CPU(s) should be x64 and feature assisted virtualisation.  All of the CPU’s in the cluster should be from the same manufacturer.  Ideally they should all be the same spec but things happen over time as new hardware becomes available and you’re expanding a cluster.  There’s a tick box for disabling advanced features in a virtual machine’s CPU to take care of that during a VM migration.
  • It should be possible to enable Data Execution Prevention (DEP) in the BIOS and it should work.  Make that one a condition of sale for the hardware.  DEP is required to prevent break out attacks in the hypervisor.  Microsoft took security very, very seriously when it came to Hyper-V.
  • The servers should be certified for Windows Server 2008 R2.
  • You should have shared storage that you will connect to the servers using iSCSI or Fibre Channel.  Make sure the vendor certifies it for Windows Server 2008 R2.  It is on this shared storage (a SAN of some kind) that you will store your virtual machines.  Size it according to your VM’s storage requirements.  If a VM has 2GB of RAM and 100GB of disk then size the SAN to be 102GB plus some space for ISO images (up to 5GB) and some free space for a healthy volume.
  • The servers will be clustered.  That means you should have a private network for the cluster heartbeat.  A second NIC is required in the servers for that.
  • The servers will need to connect to the shared storage.  That means either a fibre channel HBA or a NIC suitable for iSCSI.  The faster the better.  You may go with 2 instead of 1 to allow MPIO in the parent partition.  That allows storage path failover for each physical server.
  • Microsoft recommends a 4th NIC to create another private physical network between the hosts.  It would be used for Live Migration.  See my next page link for more information.  I personally don’t have this in our cluster and have not had any problems.  This is supported AFAIK.
  • Your servers will have virtual machines that require network access.  That requires at least a third NIC in the physical servers.  A virtual switch will be created in Hyper-V and that connects the virtual machines to the physical network.  You may add a 4th NIC for NIC teaming.  You may add many NIC’s here to deal with network traffic.  I’ve talked a good bit about this, including this post.  Just search my blog for more.
  • Try get the servers to be identical.  And make sure everything has Windows Server 2008 R2 support and support for failover clustering.
  • You can have up to 16 servers in your cluster.  Allow for either N+1 or N+2.  The latter is ideal, i.e. there will be capacity for two hosts to be offline and everything is still running.  Why 2?  (a) stuff happens in large clusters and Murphy is never far away.  (b) if a Windows 8 migration is similar to a Windows Server 2008 R2 migration then you’ll thank me later – it involved taking a host from the old cluster and rebuilding it to be a host in a new cluster with the new OS.  N+1 clusters lost their capacity for failover during the migration unless new hardware was purchased.
  • Remember that a Hyper-V host can scale out to 64 logical processors (cores in the host) and 1TB RAM.

The Operating System

This one will be quick.  Remember that the Web and Standard editions don’t support failover clustering.

  • Hyper-V Server 2008 R2 is free, is based on the Core installation type and adds Failover Clustering for the first time in the free edition.  It also has support for CSV and Live Migration.  It does not give you any free licensing for VM’s.  I’d only use it for VDI, Linux VM’s or for very small deployments.
  • Windows Server 2008 R2 Enterprise Edition supports 8 CPU sockets and 2TB RAM.  What’s really cool is that you get 4 free Windows Server licenses to run on VM’s on the licensed host.  A host with 1 Enterprise license effectively gets 4 free VM’s.  You can over license a host too: 2 Enterprise licenses = 8 free VM’s.  These licenses are not transferable to other hosts, i.e. license 1 host and run the VM’s on another host.
  • Windows Server 2008 R2 DataCenter Edition allows you to reach the maximum scalability of Hyper-V, i.e. 64 logical processors (cores in the host) and 1TB RAM.  DataCenter edition as a normal OS has greater capacities than this; don’t be fooled into thinking Hyper-V can reach those.  It cannot do that despite what some people are claiming is supported.

All hosts in the cluster should be running the same operating system and the same installation type.  That means all hosts will be either Server Core or full installations.  I’ve talked about Core before.  Microsoft recommends it because of the smaller footprint and less patching.  I recommend a full installation because the savings are a few MB of RAM and a few GB of disk.  You may have fewer patches with Core but they are probably still every month.  You’ll also find it’s harder to repair a Core installation and 3rd party hardware management doesn’t have support for it.

Install The Hardware

First thing’s first, get the hardware installed.  If you’re unsure of anything then get the vendor to install it.  You should be buying from a vetted vendor with cluster experience.  Ideally they’ll also be a reputed seller of enterprise hardware, not just honest Bob who has a shop over the butchers.  Hardware for this stuff can be fiddly.  Firmwares across the entire hardware set all have to be matching and compatible.  Having someone who knows this stuff rather than searches the Net for it makes a big difference.  You’d be amazed by the odd things that can happen if this isn’t right.

As the network stuff is being done, get the network admins to check switch ports for trouble.  Ideally you’ll use cable testers to test any network cables being used.  Yes, I am being fussy but little things cause big problems.

Install The Operating Systems

Make sure they are all identical.  An installation that is done using using an answer file helps there.  Now you should identify which physical NIC maps to which Local Area Connection in Windows.  Take care of any vendor specific NIC teaming – find out exactly what your vendor prescribes for Hyper-V.  Microsoft has no guidance on this because teaming is a function of the hardware vendor.  Rename each Local Area Connection to it’s role, e.g.

  • Parent
  • Cluster
  • Virtual 1

What you’ll have will depend on how many NIC’s you have and what roles you assigned to them.  Disable everything except for the first NIC.  That’s the one you’ll use for the parent partition.  Don’t disable the iSCSI ones.

Patch the hosts for security fixes.  Configure the TCP/IP  for the parent partition NIC.  Join the machines to the domain.  I strongly recommend setting up the constrained delegation for ISO file sharing over the network.

Do whatever antivirus you need to.  Remember you’ll need to disable scanning of any files related to Hyper-V.  I personally advise against putting AV on a Hyper-V host because of the risks associated with this.  Search my blog for more.  Be very sure that the AV vendor supports scanning files on a CSV.  And even if they do, there’s no need to be scanning that CSV.  Disable it.

Enable the Cluster NIC for the private heartbeat network.  This will either be a cross over cable between 2 hosts in a 2 host cluster or a private VLAN on the switch dedicated just to these servers and this task.  Configure TCP/IP on this NIC on all servers with an IP range that is not routed on your production network.  For example, if your network is then use for the heartbeat network.  Ping test everything to make sure every server can see every other server.

If you have a Live Migratoin NIC (labelled badly as CSV in my examples diagrams) then set it up similarly to the Cluster NIC.  It will have it’s own VLAN and it’s own IP range, e.g.

Enable the Virtual NIC.  Unbind every protocol you can from it, e.g. if using NIC teaming you won’t unbind that.  This NIC will not have a TCP configuration so IPv4 and IPv6 must be unbound.  You’re also doing this for security and simplicity reasons.

Here’s what we have now:


Once you have reached here with all the hosts we’re ready for the next step.

Install Failover Clustering

You’ll need to figure out how your cluster will gain a quorum, i.e. be able to make decisions about failover and whether it is operational or not.  This is to do with host failure and how the remaining hosts vote.  It’s done in 2 basic ways.  There are actually 4 ways but it breaks down to 2 ways for most companies and installations:

  1. Node majority: This is used when there are an odd number of hosts in the cluster, e.g. 5 hosts, not 4.  The hosts can vote and there will always be a majority winner, e.g. 3 to 2.
  2. Node majority + Disk: This is used when there are an even number of hosts, e.g. 16.  It’s possible there would be an 8 to 8 vote with no majority winner.  The disk acts as a tie breaker.

Depending on who you talk to or what GUI in Windows you see, this disk is referred to either as a Witness Disk or a Quorum Disk.  I recommend creating it in a cluster no matter what.  Your cluster may grow or shrink to an uneven number of hosts and may need it.  You can quickly change the quorum configuration based on the advice in the Failover Clustering administration MMC console.

The disk only needs to be 500MB size.  Create it on the SAN and connect the disk to all of your hosts.  Log into a host and format the disk with NTFS.  Label it with a good name like Witness Disk.

I’m ignoring the other 2 methods because they’ll only be relevant in stretch clusters than span a WAN link and I am not talking about that here.

Use Server Manager to install the role on all hosts.  Now you can set up the cluster.  The wizard is easy enough.  You’ll need a computer name/DNS name for your cluster and an IP address for it.  This is on the same VLAN as the Parent NIC in the hosts.  You’ll add in all of the hosts.  Part of this process does a check on your hardware, operating system and configuration.  If this passes then you have a supported cluster.  Save the results as a web archive file (.MHT).  The cluster creation will include the quorum configuration.  If you have an even number of hosts then go with the + Disk option and select the witness disk you just created.  Once it’s done your cluster is built.  It is not hard and only takes about 5 to 10 minutes.  Use the Failover Clustering MMC to check the health of everything.  Pay attention to the networks.  Stray networks may appear if you didn’t unbind IPv4 or IPv6 from the virtual network NIC in the hosts.

If you went with Node Majority then here’s my tip.  Go ahead and launch the Failover Clustering MMC.  Add in the storage for the witness disk.  Label it with the same name you used for the NTFS volume.  Now leave it there should you ever need to change the quorum configuration.  A change is no more than 2 or 3 mouse clicks away.

Now you have:


Install Hyper-V

Enable the Hyper-V role on each of your hosts, one at a time.  Make sure the logs are clean after the reboot.  Don’t go experimenting yet; Please!

Cluster Shared Volume

CSV is seriously cool.  Most installations will have most, if not all, VM’s stored on a CSV.  CSV is only supported for Hyper-V and not for anything else as you will be warned by Microsoft.

Set up your LUN on the physical storage for storing your VM’s.  This will be your CSV.  Connect the LUN to your hosts.  Format the LUN with NTFS.  Set it to use GPT so it can grow beyond 2TB.  Label it with a good name, e.g. CSV1.  You can have more than 1 CSV in a cluster.  In fact, a VM can have its VHD files on more than one CSV.  Some are doing this to attempt to maximise performance.  I’m not sold that will improve performance but you can test it for yourself and do what you want here.

DO NOT BE TEMPTED TO DEPLOY A VM ON THIS DISK YET.  You’ll lose it after the next step.

Use the Failover Clustering MMC to add the disk in.  Label it in Failover Clustering using the same name you used when you formatted the NTFS volume.  Now configure the the CSV.  When you’re done you’ll find the disk has no drive letter.  In fact, it’ll be “gone” from the Windows hosts.  It’ll actually be mounted as a folder on the C: drive of all of your hosts in the cluster, e.g. C:ClusterStorageVolume1.  This can be confusing at first.  It’s enough to know that all hosts will have access to this volume and that your VM’s are not really in your C: drive.  They are really on the SAN.  C:ClusterStorageVolume1 is just a mount point to a letterless drive.

Now we have this:


Virtual Networking

Hopefully you have read the previously linked blog post about networking in Hyper-V.  You should be fully educated about what’s going on here.

Here’s the critical things to know:

  • You really shouldn’t put private or internal virtual networks on a Hyper-V cluster when using more than one VM on those virtual networks.  Why?  A private or internal virtual network on host A cannot talk with a private or internal network on host B.  If you set up VM1 and VM2 on such a virtual network on host A what happens when one of those VM’s is moved to another host?  It will not be able to talk to the other VM.
  • If you create a virtual network on one host then you need to create it on all hosts.  You also must use identical names across all hosts.  So, if I create External Network 1 on host 1 then I must create it on host 2.

Create your virtual network(s) and bind them to your NIC’s.  In my case, I’m binding External Network 1 to the NIC we called Virtual 1.  That gives me this:


All of my VM’s will connect to External Network 1.  An identically named external virtual network exists on all hosts.  The physical Cluster 1 NIC is switched identically on all servers on the physical network.  That means if VM1 moves from host 1 to host 2 it will be able to reconnect to the virtual network (because of the identical name) and be able to reach the same places on the physical network.  What I said for virtual network names also applies to tags and VLAN ID’s if you use them.

Get Busy!

Believe it or not, you have just built a Hyper-V cluster.  Go ahead and build your VM’s.  Use the Failover Clustering MMC as much as possible.  You’ll see it has Hyper-V features in there.  Test live migration of the VM between hosts.  Do continuous pings to/from the VM during a migration.  Do file copies during a migration (pre-Vista OS on the VM is perfect for this test).  Make sure the VM’s have the integration components/integration services/enlightenments (or additions for you VMware people) installed.  You should notice no downtime at all.

Remember that for Linux VM’s you need to set the MAC in the VM properties to be static or they’ll lose the binding between their IP configuration and the virtual machine NIC after a migration between hosts.

Administartion of VM’s

I don’t know why some people can’t see or understand this.  You can enable remote desktop in your VM’s operating system to do administration on them.  You do not to use the Connect feature in Hyper-V Manager to open the Virtual Machine Connection.  Think of that tool as your virtual KVM.  Do you always use KVM to manage your physical servers?  You do?  Oh, poor, poor you!  You know there’s about 5 of you out there.

Linux admins always seem to understand that they can use SSH or VNC.

Virtual Machine Manager 2008 R2

VMM 2008 R2 will allow you to manage a Hyper-V cluster(s) as well as VMware and Virtual Server 2005 R2 SP1.  There’s a workgroup edition for smaller clusters.  It’s pretty damned powerful and simplifies many tasks we have to do in Hyper-V.  Learn to love the library because that’s a time saver for creating templates, sharing ISO’s (see constrained delegation above during the OS installation), administration delegation, self service portal, etc.

You can install VMM 2008 R2 as a VM on the cluster but I don’t recommend it.  If you do, then use the Failover Clustering and Hyper-V consoles to manage the VMM virtual machine.  I prefer that VMM be a physical box.  I hate the idea of chicken and egg scenarios.  Can I think of one now?  No, but I’m careful.

To deploy the VMM agent you just need to add the Hyper-V cluster.  All the hosts will be imported and the agent will be deployed.  Now you can do all of your Hyper-V management via PowerShell, the VMM console and the Self Service console.

You also can use VMM to do a P2V conversion as mentioned earlier.  VSS capable physical machines that don’t run transactional databases can be converted using a live or online conversion.  Those other physical machines can be converted using an offline migration that uses Windows PE (pre-installation environment).  Additional network drivers may need to be added to WinPE.

You can enable PRO in your host group(s) to allow VMM to live migrate VM’s around the cluster based on performance requirements and bottlenecks.  I have set it to fully automatic on our cluster.  Windows 2008 quick migration clusters were different: automatic moves meant a VM could be offline for a small amount of time.  Live Migration in Windows Server 2008 R2 solves that one.

Figure out your administration model and set up your delegation model using roles.  Delegated administrators can use the VMM console to manage VM’s on hosts.  Self service users can use the portal.

Populate your library with hardware templates, VHD’s and machine templates.  Add in ISO images for software and operating systems.  An ISO create and mounting tool will prove very useful.

Operations Manager 2008 R2

My advice is “YES, use it if you can!”.  It’s by using System Center that makes Hyper-V so much better.  OpsMgr will give you all sorts of useful information on performance and health.  Import your management packs for Windows Server, clustering, your hardware (HP and Dell do a very nice job on this.  IBM don’t do so well at all – big surprise!), etc.  Use the VMM integration to let OpsMgr and VMM to work together.  VMM will use performance information from OpsMgr for intelligent placement of VM’s and for PRO.

I leave the OpsMgr agent installation as a last step on the Hyper-V cluster.  I want to know that all my tweaking is done … or hopefully done.  Otherwise there’s lots of needless alerts during the engineering phase.


Deploy your backup solution.  I’ve talked about this before so check out that blog post.  You will also want to backup VMM.  Remember that DPM 2007 cannot backup VM’s on a CSV.  You will need DPM 2010 for that.  Check with your vendor if you are using backup tools from another company.


Don’t go running into production.  Test the heck out of the cluster.  Deploy lots of VM’s using your templates.  Spike the CPU in some of them (maybe a floating point calculator or a free performance tool) to test OpsMgr and VMM PRO.  Run live migrations.  Test P2V.  Test the CSV coordinator failover.  Test CSV path failover by disconnecting a running host from the SAN – the storage path should switch to using the Ethernet and route via another host.  Get people involved and have some fun with this stage.  You can go nuts while you’re not yet in production.

Go Into Production

Kick up your feet, relax, and soak in the plaudits for a job well done.

EDIT #1:

I found this post by a Microsoft Failover Clustering program manager that goes through some of this if you want some more advice.

My diagrams do show 4 NIC’s, including the badly named CSV (Live Migration dedicated).  But as I said in the OS installation section, you only need 3 for a reliable system: (1) parent, (2) heartbeat/live migration, and (3) virtual switch.


There are some useful troubleshooting tips on this page.  Two things should be noted.  Many security experts advise that you disable NTLM in group policy across the domain.  You require NTLM for this solution.  There are quotes out there about Windows Server 2008 failover clusters not needing a heartbeat network. But “If CSV is configured, all cluster nodes must reside on the same non-routable network. CSV (specifically for re-directed I/O) is not supported if cluster nodes reside on separate, routed networks”.

Can You Install Hyper-V in a VM?

The answer is sort of.  Strictly speaking it is possible.  You can indeed enable the Hyper-V role in a Server Core installation of Windows Server 2008 and Windows Server 2008 R2.  I’ve done it on both OS’s on both VMware Workstation 6.5 and on Hyper-V.  Logically this means you can deploy Hyper-V Server 2008 and Hyper-V Server 2008 R2 in a VM.

You can even create VM’s on the hosts.  However, the hardware requirements are not passed through to the VM’s and therefore the hypervisor never starts up.  That means you cannot start up those VM’s.

Why would you care?  You certainly cannot do it in a production scenario.  But you might find it handy when doing some demos, lab work or testing of clustering or VMM.


I have been told (but I have not tried this so I cannot say it will work) that you can get Hyper-V to install and run in an ESXi 3.X virtual machine.  The performance is said to be awful, but might be useful for a lab with limited hardware.