Virtualization Strategies for the CIOBecause of the natural growth of workloads, sometimes it's necessary to modify the logical unit number (LUN) size where the VM resides. After extending a LUN in a Hyper-V cluster, however, the volume GUID can change. This causes Quick Migration problems and will display an "unsupported cluster configuration" in System Center Virtual Machine Manager (SCVMM).
Figure 1
(Click image for an enlarged view.)
This problem occurs because the LUN has changed its volume GUID, but the Hyper-V setting has the old volume GUID.
Figure
Requires Free Membership to View
When you register, my team of editors will also send you the latest expert resources covering all areas of server virtualization, such as platforms, architectures and strategies, server hardware, managing virtual environments, application issues and more.
Margie Semilof, Editorial Director
2
(Click image for an enlarged view.)
Figure 3
(Click image for an enlarged view.)
Some Hyper-V cluster performance problems are not the vendor's fault or the result of unexpected failures. At times, IT administrative errors happen, and you need to take the blame. In Hyper-V R1, there are complex requirements for Quick Migration, such as having a LUN for each VM. In one cluster, I have more than 100 VMs, meaning there are more than 100 LUNs of varying sizes. On top of that, each LUN is presented to six nodes, so the VM LUNs can mount on any node. A problem occurs, however, if a LUN isn't presented to every node. One time, I had a handful of VMs that would not move to a particular host. The host was new, so I thought there was a firmware or driver issue. A VM would go into a save state and un-mount the disk. Then, when the cluster tried to move the LUN to another node, it would fail and bounce to another cluster node. After the firmware and drivers checked out, I investigated the configuration of servers. Ultimately, I had forgotten to present the older, existing VM LUNs to the new host. Because there wasn't a Fibre Channel path to the VM LUNs, the new node could not mount the LUN. Luckily, this issue has been resolved with Hyper-V R2's Cluster Shared Volumes (CSV) or through the use of a third party product like Melio FS, because these solutions do not rely on the one-LUN-per-VM architecture. Until there is a product that can catch everything that slips my mind, careful assessment and re-certification of virtual cluster environments after changes is necessary to prevent IT administrative errors. Ultimately, for all the stability and redundancy that a Hyper-V cluster can add to a virtual environment, it does create a significant level of complexity as well. In my opinion, the trade-off is definitely worth it. But there are bound to be implementation shortcomings because of bugs or IT administrative errors. Knowing how to quickly stabilize your environment is a skill that needs to be developed. In part four, I will focus on some strange virtual network issues and explain when it's necessary to take drastic action to recover from virtual network problems. Until then, send me any feedback or issues you have seen. About the expert Rob McShinsky is a senior systems engineer at Dartmouth Hitchcock Medical Center in Lebanon, N.H., and has more than 12 years of experience in the industry -- including a focus on server virtualization since 2004. He has been closely involved with Microsoft as an early adopter of Hyper-V and System Center Virtual Machine Manager 2008, as well as a customer reference. In addition, he blogs at VirtuallyAware.com, writing tips and documenting experiences with various virtualization products.
This was first published in December 2009
Join the conversationComment
Share
Comments
Results
Contribute to the conversation