N_Port Virtualization (NPIV) Requirements

N_Port Virtualization ( is an ANSI T11 standard that describes how a single Fibre Channel Physical HBA port can register with a fabric using several worldwide port names (WWPNs), what might be considered Virtual WWNs. This in turn means that since there are multiple Virtual HBAs per physical HBA, we can allow WWNs to be assigned to each VM.

An advantage I see from VMs having their own WWNs is possibly Quality of Service (QoS) measurement. With each VM having its own WWN, you could perceivably track Virtual Machine traffic in the fabric if you had the appropriate tools. Masking and zoning could be configured per virtual machine vice per adapter. Also, you may get more visibility of VMs at the storage array level. But you have to use Raw Device Mappings (RDMs) mapped to the VM for NPIV, which means you do not get all the benefits associated with VMFS and VMDKs

If you plan to enable NPIV on your virtual machines, you should be aware of certain requirements.

The following requirements exist:

-NPIV can be used only for virtual machines with RDM disks. Virtual machines with regular virtual disks use the WWNs of the host’s physical HBAs.

-HBAs on your host must support NPIV.

See the vSphere Compatibility Guide and refer to your vendor documentation for more information.

-Use HBAs of the same type, either all QLogic or all Emulex. VMware does not support heterogeneous HBAs on the same host accessing the same LUNs.

-If a host uses multiple physical HBAs as paths to the storage, zone all physical paths to the virtual machine. This is required to support multipathing even though only one path at a time will be active.

-Make sure that physical HBAs on the host have access to all LUNs that are to be accessed by NPIV-enabled virtual machines running on that host.

-The switches in the fabric must be NPIV-aware.

-When configuring a LUN for NPIV access at the storage level, make sure that the NPIV LUN number and NPIV target ID match the physical LUN and Target ID.

-Use the vSphere Client to manipulate virtual machines with WWNs.

Configure vCenter Server storage filters

vCenter Server provides storage filters in its advanced settings to help you avoid storage device corruption or performance degradation that can be caused by an unsupported use of LUNs. These filters are available by default. We have a few different ones to choose from: VMFS filter, RDM filter, Same Host and Transports filter, and Host Rescan Filter.
We see the keys on the right next to the different kind of filters, we can look for these in vCenter Advanced settings to change or disable them. To do this:
– Log into vCenter using the vSphere Client
– Go to Home > vCenter Server Settings
– Click Advanced Settings
– Enter or modify the keys above
– Click ok

Understand and apply VMFS resignaturing

Each VMFS 5 datastore contains a Universally Unique Identifier (UUID). The UUID is stored in the metadata of your file system called a superblock and is a unique hexadecimal number generated by VMware.

When a duplicated (byte-for-byte) copy of a datastore or underlying LUN is executed, the resultant copy will contain the same UUID. As a VMware administrator, you have two options when bringing the duplicate datastore online:

1. VMware prevents two data stores with the same UUID from mounting. What you can do is choose to unmount the initial datastore and bring the second, duplicate datastore with the same UUID online after.

2. Alternatively, you may create a new UUID (this is known as a resignature) for the datastore and this way both disks may be brought online at the same time. A resignatured disk is no longer a duplicate of the original because it has a different UUID.

Windows administrators can relate to this when they clone Windows systems. A new SID must be generated for any cloned machine. Otherwise, you will encountered duplicate SID errors on your network when you bring multiple machines with the same SID online at the same time.

Using the vMA to determine the relationship between the UUID and the datastore name

I am continuing to prepare for the VCAP-DCA, a big part of this process is practicing my command line skills.

Today I was using the vMA to practice some list commands and there was one in particular I wanted to share.

You can list the path names to your virtual machines that are registered with the target server (server you are running the commands against).

To do this use:

vmware-cmd -l | more

Your results may look something like:

From there you may notice the 3rd directory in the path to the .vmx file. This is the UUID (universally unique identifier) of the file system on which the virtual machine is residing.

To figure out which UUID belongs to which datastore, use:

esxcli storage filesystem list

Now I can tell which UUID is associated to the “Local01” and “Shared” datastores. Using these two commands, I can tell that “TestVM01” resides on the “Local01” datastore.