In this last part of three Aaron Denton shares his experiences after ther upgrade from Hyper-V 1.0 to Hyper-V 2.0.

In the previous posts for this series, I discussed why we decided to upgrade our virtual machine host servers from Windows Server 2008 to revision 2. I also outlined the implementation plan.

Now that I’ve gone through the actual upgrade, I want to share how it went.

Cluster Shared Volumes ^

While there may not be any performance or high availability gains from this feature, I consider it a great one from an administrative standpoint.

To illustrate my point, consider the number of disks needed to have clustered Exchange 2007 servers running as VMs in revision 1. For each server one disk for Windows, a disk for each database, and a disk for each set of transaction logs is needed. With just one mailbox store, six iSCSI disks are needed. When you add in the disks you need to run Hub Transport and Client Access servers you easily need 8-10 disks just for email.

Hyper-V Upgrade - Cluster Shared Volume

Hyper-V Upgrade - Cluster Shared Volumes

Throw in the other disks you need for redundant domain controllers, remote access servers, and SharePoint, and they begin to add up. Compare this with cluster shared volumes where the only “disk” is accessed using C:\ClusterStorage. Now one disk is provided and vhds are maintained. If a server requires more space than anticipated, simply expand the vhd. This is much easier than taking the iSCSI target offline, extend that image, and then expand the vhd.

An additional bonus in VM disk management in R2 is the ability to add virtual hard disks while the VM is still online. No more shutting down Exchange to add another drive for that new database you need to create.

Further reading:

Requirements for Using Cluster Shared Volumes in a Failover Cluster in Windows Server 2008 R2

Dynamic Memory ^

I mentioned in previous posts that I wanted to take advantage of all that memory sitting in my hosts and still allow all VMs to failover to one host in disaster scenarios. Dynamic Memory solved that problem. We no longer have 50% of our RAM sitting around unused when the hosts are under normal conditions.

To accomplish this we simply kept the total startup RAM assigned below the total available RAM on one host. Attention was also paid to the memory buffer percentage so that even with the additional RAM that setting allocates, we still sat below the total available RAM. The maximum RAM setting allowed us to provide additional RAM capacity when unused RAM is available.

Hyper-V Upgrade - Dynamic Memory

Hyper-V - Dynamic Memory

Finally, using the Memory weight setting allowed us to prioritize important VMs such as an Exchange mailbox server over less important VMs such as a redundant domain controller. Dynamic Memory is also very easy to configure.

Further reading:

Hyper-V Dynamic Memory Configuration Guide

Live Migration ^

Being conservative from a budget standpoint, we’ve been looking forward to having Live Migration without the need for additional expense of System Center Virtual Machine Manager (SCVMM).

Hyper-V Upgrade - Live Migration

Hyper-V - Live Migration

I’m happy to report that the feature has worked well so far. There’s really not much else to say about this feature. It lets us move VMs around without having them lose connectivity which means we can do maintenance during working hours.

Further reading:

Hyper-V: Using Live Migration with Cluster Shared Volumes in Windows Server 2008 R2

In summary, we’ve been very happy with the improvements that R2 brings to the table. The key features that moved us to upgrade perform as advertised.

Articles in series

Hyper-V upgrade

4 Comments
  1. CypherBit 10 years ago

    Great series.

    I'm also on R2 and am utilizing all the top features mentioned except for Dynamic Memory. I have a two node cluster and the memory allocation is the same you had before moving to R2 (about half so they can failover to one node).

    I'm curious have you also configured Dynamic Memory on Exchange, it's not recommended:
    http://technet.microsoft.com/en-us/library/cc794548(EXCHG.80).aspx

  2. Author
    Aaron D 10 years ago

    I've not configured Dynamic Memory on mailbox servers as the store would not benefit from it.
    However; because of more flexibility elsewhere, I was able to bump up the static allocation.

    So for the mailbox servers dynamic memory is a definite no-no.

    Everything I've read so far has the same opinion for the Hub Transport and Client Access role servers. However; I've yet to read where anyone has a concrete similar to way the store service works.

    I'm trying dynamic memory on the HT and CA servers for now. So far no issues...

  3. Author
    Aaron D 10 years ago

    clarification on my previous comment:

    it should read ...I've yet to read where anyone has sited a concrete example similar to the way the store service works.

  4. CypherBit 10 years ago

    Thank you Aaron, all clear.

Leave a reply

Please enclose code in pre tags

Your email address will not be published. Required fields are marked *

*

© 4sysops 2006 - 2021

CONTACT US

Please ask IT administration questions in the forums. Any other messages are welcome.

Sending

Log in with your credentials

or    

Forgot your details?

Create Account