If you power on an NPIV-enabled virtual machine on a host with Emulex Fibre Channel HBAs, the virtual machine might not be able to create a VPORT. Instead, the virtual machine fails back to the RDM path provided by the physical port. If you inspect the VMkernel log file, you can see entries similar to the following:
ScsiNpiv: 1308: Created vport for world 5114, vmhba0, rv 0
ScsiNpiv: 1140: NPIV vport rescan complete, [0:18] (0x41000803bc40) [0x41000cc01150] status=0x0
ScsiScan: 1059: Path 'vmhba139:C0:T1:L18': Vendor: 'DGC ' Model: 'RAID 5 ' Rev: '0326'
ScsiScan: 1062: Path 'vmhba139:C0:T1:L18': Type: 0x0, ANSI rev: 4, TPGS: 0 (none)
ScsiNpiv: 1119: Phys [status=bad0039] does not equal Virt [status=0], NPIV Disabled for this VM
ScsiNpiv: 1140: NPIV vport rescan complete, [1:18] (0x410008045fc0) [0x41000cc01150] status=0x0
ScsiNpiv: 1754: Failed to Create vport for world 5114, vmhba0, rescan failed, status=bad0001
LinScsiLLD: scsi_remove_host: Removing Host Adapter vmhba139
This happens because for the NPIV-enabled virtual machine, the discovery order on the VPORT should exactly match the discovery order on the host's physical port. With the Emulex HBA, each VPORT independently discovers targets in the SAN by starting its own discovery process. When a response from one or more targets is delayed, the VPORT might discover targets in an order different from that for the physical port. This results in a failure to create the VPORT on a virtual machine.
To resolve this problem, perform the following:
lpfc_discovery_threads=1
configuration option for the lpfc820
driver using the command:esxcfg-module –s “lpfc_discovery_threads=1” lpfc820
esxcfg-boot -b
esxcfg-module -g lpfc820
lpfc820 enabled = 1 options = 'lpfc_discovery_threads=1'