[Stevenjwilliams83]

We are looking to get our first Virtual environment going using Hyper-V and I am looking for suggestions on the best way to approach this or what is common. To have failover clustering each Node needs to see the same LUN on the SAN, but what if I have two SAN's? Is the best practice to cluster the SAN's using the vendor software and build your arrays over multiple SAN's and point the hosts to logical IP of the multiple SAN's? Also is one VM per LUN best practice or a requirement?

[Virtual]

Implement a Hyper-V R2 Cluster and ensure you implement a Clustered shared Volume (CSV). You then don't need to have one VM per LUN.

This is worth a review.

http://support.microsoft.com/kb/980643

[Dumber]

If you have a FC environment, you basically can use both SANs at the time.
If you are using iSCSI then there is still no issue as long you can connect them over IP.

Most SANs are HA already, so...

However you need to tell more about the storage environment, eg where are they located, what type of connections are there, what storage devices do you have etc.

[Stevenjwilliams83]

Two EMC SAN's, one at HQ and one at DR. Two Hosts per location clustered to one SAN. SAN's will replicate VHD's via replication software.

What is the best practices with clustering and SAN's? I assume both hosts must see the same LUN so that VM's can be migrated from one host to another?

We have seen in the past though that when a LUN is seen by two hosts the SAN gets confused and starts corrupting the VHD files.

[Virtual]

Originally Posted by Stevenjwilliams83

Two EMC SAN's, one at HQ and one at DR. Two Hosts per location clustered to one SAN. SAN's will replicate VHD's via replication software.

What is the best practices with clustering and SAN's? I assume both hosts must see the same LUN so that VM's can be migrated from one host to another?

We have seen in the past though that when a LUN is seen by two hosts the SAN gets confused and starts corrupting the VHD files.

I had responded to this one but my logon must have timed out at the time, so my post didn't make it.


With regards to your Hyper-V cluster setup per location, which are tied to their own SAN, you could explore the following options.

• Use stretched vLANs, so VMs within both locations are in the same subnet, so helps with a failover situation. Replicate the relevant SAN volumes from your production environment to DR and spin the VMs up in DR should DR ever need to be invoked.
• Use stretched vLANs or leave subnets as they are and make the applicaiton highly available. For example, Exchange 2010 using a DAG and ensuring at least one DC and Exchange 2010 server with CAS/HT and MB roles are within DR, where production data and changes will be replicated to them.

There are other options but just some thoughts based on what we do for some of our Managed services and DR customers. Of course, the options or approach you take will be dictated by Company policy, the technology at your disposal and SLAs.


Best practice with regards to clustering and SANs with Hyper-V woul be to use a CSV as posted earlier in this thread. The article posted is worth a review. As you point out, the LUNs will need to be presented to all Hyper-V Hosts in the cluster. If you are using an iSCSI SAN, ensure that it supports iSCSI-3, which is persistant connections.


CSV allows the LUN to be accesible by all Hyper-V Hosts at the same time. I have never known VHDs to corrupt in a CSV. However, for example, we use Dell Compellents, which have a space saving feature for NTFS LUNs. This does not support CSV volumes, so say a SAN has similar features or other features, verify the support for CSV volumes, in case that corrupts data or VHDs.