- Top 10 new features in Windows Server 2012 R2 - Mon, Jun 10 2013
- FREE: Unitrends Enterprise Backup Free Edition – Hyper-V and VMware backup - Tue, Nov 6 2012
- FREE: Remote Desktop Manager – A powerful RDP client - Wed, Sep 19 2012
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 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 - 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 - 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.
Read the latest IT news and community updates!
Join our IT community and read articles without ads!
Do you want to write for 4sysops? We are looking for new authors.
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
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…
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.
Thank you Aaron, all clear.