NPIV with ESX3.?? virtual machines and NPIV capable fiber switch

[duchaj]

Wondering when VMWare will support NPVI (N-Port ID Virtualization) with Emulex LP11000 HBAs attached to an NPIV capable fibre switch such as a Brocade??

Anyone know if it is on the roadmap??

Have seen plenty of online documents but nothing to say when/if it will be coming out.

Thanks for any qualified input you might have.

[Ken_Cline]

I'm curious - what is the business problem that you see NPIV solving for you?

[Jean-Yves_Cheva]

I am answering this based on Emulex's perspective (we co-sponsored NPIV through T11 with IBM and demoed and released in a variety of environments).

NPIV-based solutions enable you to establish logical FC connections independent of the physical N-port. This gives two basic capabilities:

\- multiple connections mapped to VMs (or applications or users)

\- portable connections (can re-establish the same WWN on a different physical link).

What users tell us they are interested in:

\- zoning at the VM-level (same as they had for hardware-based servers before they virtualized them). This is big for many users, but especially when security clearance policies are based on zones, or multiple customers share the same infrastructure.

\- use fabric tools such as switch-based traffic flow control to provide preferred bandwidth to some VMs over others. Also traffic monitoring and chargeback is of value to many.

Emulex has released (GR) the firmware extensions on our 4Gbit PCI-X and PCI-Express HBAs (this firmware also supports OEM-branded derivatives) and a Windows and MS Virtual Server driver and wizard that enable those customers to exercise NPIV, and more importantly enable the vendor community to test, and get familiar with, NPIV core capabilities and user interfaces. Emulex has also submitted NPIV Linux extensions for insertion in the upstream kernel (and use by Linux within as well as without Xen).

Emulex and VMware have developed, demonstrated and tested NPIV capabilities including driver, VMkernel and Virtual Center extensions. We are looking to jointly support a limited of end user Betas in the near future. Future productization is being discussed - dates and conditions are under VMware control. I would welcome further comments by VMware based on what they feel ready to share.

[oreeh]

I agrre with Massimo at this:

Exposing physicals to VMs doesn't make any sense.

http://it20.info/blogs/main/archive/2007/03/11/4.aspx

[Jean-Yves_Cheva]

Agree there too.

The way NPIV is implemented in drivers does not give control or visibility to the application or user inside a VM, it just makes the VM visible from the fabric side. It is more a tool for fabric and storage management, and in the future ESX or hypervisor-level resource management, than it is for connection management from inside a VM.

[oreeh]

it just makes the VM visible from the fabric side

I know - but I don't see any benefit.

[duchaj]

With the ability to have a virtual machine present its own WWPN to the SAN would be a great benefit.

The virt machine will have its own zone and lun masking entry but the catch....

Will ESX server pass the masked luns to the virtual machine with the virtual WWPN without configuring ESX server as is today?

[duchaj]

The benefit would be to reduce the amount of physical machines that need to present an HBA WWNN to the SAN for lun masking, etc....

[oreeh]

Why would you want this?

Virtual machines don't need direct access to LUNs.

[oreeh]

With storage virtualization only the virtualization layer has a direct connection to the SAN.

[RBurns-WIS]

You DO need NPIV for two main reasons.

1. You need to be able to do zoning of your VMs according to a dedicated wwn rather than using the wwn's of every ESX host the VM will live on. If a VM with a mapped LUN is moved from one host to another it will not be able to see its storage unless the new ESX host is also zoned. The more hosts you expose with zoning the higher the risk to your data.

2. NPIV allows for Raw Device mappings so that VMs can execute SAN commands directly to the SAN for reasons like Management, granular disk commands, Snapshots, fine tuned backups functions etc.

On top of all this you can now track proper usage per VM. If you want to see how much traffic a certain volume is using it gets hard when the ESX host owns the wwn and not the VM. This also allows for traffic control & storage-like QoS.

Cheers,

[Texiwill]

Hello,

1. You need to be able to do zoning of your VMs according to a dedicated wwn rather than using the wwn's of every ESX host the VM will live on. If a VM with a mapped LUN is moved from one host to another it will not be able to see its storage unless the new ESX host is also zoned. The more hosts you expose with zoning the higher the risk to your data.

Currently you must present the LUN to ESX as well as the WWN of the VM. You must create an RDM inside ESX and map it to the VM. If NPIV fails then everything falls back to the RDM.

2. NPIV allows for Raw Device mappings so that VMs can execute SAN commands directly to the SAN for reasons like Management, granular disk commands, Snapshots, fine tuned backups functions etc.

Yes, but you still need to create a RDM and NPIV only currently works for disk LUNs.

On top of all this you can now track proper usage per VM. If you want to see how much traffic a certain volume is using it gets hard when the ESX host owns the wwn and not the VM. This also allows for traffic control & storage-like QoS.

This is the main benefit to NPIV. But as already stated it is used mostly for storage management of Disk based LUNs.

I would like to see a virtual HBA presented to the VM so that I can present any LUN direct to the VM whether it is a disk or tape.... Alas that is a future element.

Best regards,

Edward L. Haletky

VMware Communities User Moderator

====

Author of the book 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', Copyright 2008 Pearson Education.

Blue Gears and SearchVMware Pro Blogs: http://www.astroarch.com/wiki/index.php/Blog_Roll

Top Virtualization Security Links: http://www.astroarch.com/wiki/index.php/Top_Virtualization_Security_Links