Stall The Ball

So here’s the problem. You have multiple Virtual Server hosts running Virtual Server guests and your storage is on a SAN.

The supported way of exposing the SAN to the Virtual Server guest is to present the SAN to the host as drive letters and then use pass through to get the guests to see the disks. See pic below from Microsoft.

It works but truth be told it’s clunky and has a few drawbacks.

It’s a pain to set-up and migrating Virtual Server from one host to another host gets you into re-zoning to present the same SAN storage to the new Virtual Server host.

Microsoft sum it up quite neatly.
http://download.microsoft.com/download/d/f/6/df6accd5-4bf2-4984-8285-f4f23b7b1f37/WinHEC2007_VMPilot.doc

• Implementing SAN Management Best Practices. Since all VMs on a physical server share the same physical HBAs, they can all address the same storage. Typical SAN tools and best practices, such as fabric zoning and array-level logical unit number (LUN) masking, rely on the HBA’s WWPN. When the WWPN of a physical HBA is shared, all the VMs on the server reside in the same zone and are masked to the same storage. This violates best practices commonly implemented by SAN administrators. The current remedy in Virtual Server 2005 R2 is to manually mask LUNs from the server. This creates two issues. First, it introduces another server administrator–managed procedure and tool in addition to those already in use by the storage administrator. Second, it scales very poorly. Array-level masking only requires one change for all connected servers, while server-level masking requires changes for each virtual server.
• Using Standard SAN Management Tools. Common SAN management tools that utilize the WWPN to identify applications for chargeback or quality of service (QoS) can only perform those tasks at the level of the physical machine. Specific SAN resources cannot be prioritized for VMs running mission-critical applications, limiting the capability to manage QoS.
• Migrating Virtual Machines. One of the key features of virtual environments is the ability to quickly overcome server hardware over-utilization or failure by moving VMs to alternate servers. If a physical sever fails, this capability is restricted when physical HBA WWPNs are lost along with the server. This also typically means that when a VM is moved to a new physical host, the data for the VM must be copied to a new Virtual Hard Disk (VHD). The storage connectivity on the new host must also be reconfigured to point to the new VHD—a tedious and time-consuming process that slows the recovery time for the VM. Users who want to enjoy the benefits of virtualization have a workaround, which is to implement open zoning for all virtual servers. This solution is only applicable when the role of the virtual server is limited to noncritical file and print server consolidation. It should not be deployed for mission-critical workloads where zones are used to enforce application and server isolation.

There is a ray of light though, Emulex have released a product called VMPilot whish allows you to create virtual HBA cards on the Virtual server. This allows you to set up zoning, LUN masking etc as normal but if you move the Virtual Server the virtual HBA moves with it, so everything still works.

This is a huge step forwards for high availability scenarios. Previously, if you adopted SAN best practices, moving a Virtual Server was at best a 20 min manual job. Now its a few seconds.

Joe Barreto has gone to the trouble of listing all the possible combinations of storage available to Hyper-V. Table 3 comment (f) is the VMPilot scenario.

There is a fly in the ointment though. Despite extensive searches the I’m finding it difficult to find any SAN vendor apart from IBM that has certified this virtual HBA. EMC have expressly refused to support it with a comment along the lines of “If you want to use it fine, but don’t expect us to stand over it”

Bit of a predicament, an elegant solution to a thorny issue versus your SAN vendor support.