Passing LUN through Virtual HBAs on Server 2012 R2

Question

i have two Hyper-V hosts running Server 2012 R2 connected to a Fibre Channel SAN with an EMC back end.  I am at the point where I have configured the zoning and can see the LUNs on the Hyper-V nodes using virtual HBA initiators.  However, I cannot
find any way to pass the LUNs through to the Virtual Machines running Server 208 R2.  If I used the method of a shared SCSI controller I don't see the pint of the Virtual HBAs.
Needless to say, the Virtual OS does not see any LUNs at this point.
PC_Doctor

Answer 1

First, you must be sure that your HBA vendor supports virtual fibre channel - not all vendors do.
Configuring vHBAs for VMs is just like configuring HBAs on the physical hosts - only twice as much work.  You have to zone and mask for the individual VMs, just like you zone and mask for the physical hosts.  Except the VMs have twice as many WWNs
as the hosts because they need it for live migration to work.
If you search TechNet you will find blogs and design guides that can assist in setting this up.
"I don't see the pint of the Virtual HBAs."
For the most part I agree with you.  In a Microsoft environment, there are very few cases where vHBAs make sense (imo).  Before Windows Server 2012 with Hyper-V customers asked for vHBAs because VMware had that as a method for sharing volumes between
a pair of nodes to enable failover clustering.  Also, early on, there were performance benefits to be realized by going directly to physical storage rather than using virtual disks that resided on physical storage.
2012 changed all that.  Yes, it introduced vHBA, but R2 also introduced shared VHDX.  2012 also significantly improved virtual disk performance to the point where the difference between physical and virtual is not noticeable in almost all
cases. 
Shared VHDX is much, much easier to implement and manage than is vHBA.  It requires a box to be checked to enable sharing.  vHBA requires two sets of zones/masks for each VM compared to one set for a physical server.
Shared VHDX allows for complete hardware independence.  In other words, because all storage is virtual, the VM can be moved to any other platform.  vHBA locks you to a specific hardware configuration.  You are tied to the storage array addressed
by the WWNs.
Bottom line for me is that learning to use vHBA is an interesting exercise (which I did perform), but I have yet to run across a situation where I would opt to use vHBA instead of shared VHDX.
. : | : . : | : . tim