Virtual fibre channel storage loss during live migration

Sharma Nikhil 80 Reputation points
2026-08-14T02:50:47.35+00:00

Hi Microsoft Community,

I am working with a Hyper-V environment where one of our virtual machines uses Virtual Fibre Channel adapters to access SAN storage. The VM runs normally on the current host, but when I perform a Live Migration to another cluster node, the SAN disks suddenly become unavailable inside the guest OS.

I checked the physical Fibre Channel HBAs on the destination host and found that they appear to be mapped to incorrect NPIV WWN pools. This seems to prevent the VM from maintaining the expected SAN connectivity after migration.

I have already reviewed the vFC configuration and SAN connectivity, but I am still not sure how the WWN mappings, virtual SAN switches, and physical HBA zoning should be aligned correctly.

What is the recommended approach for configuring the Hyper-V vFC switches, NPIV WWN pools, and SAN zoning so that storage remains available during Live Migration?

Any guidance from the community or Microsoft experts would be greatly appreciated. Thanks in advance.

Windows for business | Windows 365 Enterprise
0 comments
Answer accepted by question author
Domic Vo 29,480 Reputation points Independent Advisor
2026-08-14T09:51:36.13+00:00

Dear Sharma Nikhil,

In a Hyper‑V environment with Virtual Fibre Channel, Live Migration only works reliably if the virtual SAN switches are consistently mapped across all cluster nodes and the NPIV WWN pools are properly aligned. Each VM must be assigned a static pair of WWNs, and those WWNs must be zoned on the SAN for every host in the cluster. If the destination host’s HBA is mapped to a different NPIV pool, the VM will lose connectivity because the SAN does not recognize the WWN presented after migration.

The recommended approach is to configure identical Virtual SAN switches on each host, pointing to the same physical HBA ports. Then, assign static WWN pairs to the VM using PowerShell (Set-VMFibreChannelPort -VMName <VM> -WWPN <WWN1> -WWNN <WWN2>). Ensure that these WWNs are included in the SAN zoning and masking rules for all HBAs in the cluster. This way, when the VM migrates, the SAN still sees the same WWN identity and maintains disk access. Without static WWN assignment and consistent SAN zoning, NPIV will generate mismatched identities and break the path. Once the configuration is uniform across nodes, Live Migration will preserve SAN connectivity seamlessly.

If my answer is useful for you, please hit Accept the answer to support me.

Thank you,

Domic.

Was this answer helpful?

1 person found this answer helpful.
0 comments
Answer accepted by question author

AI answer

2026-08-14T02:51:12.59+00:00

For Hyper-V Virtual Fibre Channel live migration, the configuration must be aligned at three layers:

  1. Virtual SAN design on each host
    • A virtual SAN is a named group of physical Fibre Channel ports connected to the same physical SAN.
    • Create virtual SANs so that each one contains only the physical Fibre Channel ports that connect to the same SAN fabric or target SAN.
    • If the host is connected to multiple SANs, define separate virtual SANs for each SAN.
    • If the design uses two paths to the same storage target, the same technique can be used to represent those paths.
  2. VM virtual Fibre Channel adapter configuration
    • A VM can have up to four virtual Fibre Channel adapters, and each adapter is associated with a virtual SAN.
    • Each adapter uses a WWN address, which can be assigned automatically or manually.
    • For live migration, each virtual Fibre Channel adapter is assigned two WWNs. Hyper-V alternates between Set A and Set B during migration so that the destination host can see the LUNs before the move completes and downtime is avoided.
    • If WWN pool alignment is wrong on the destination host, the guest can lose access to the SAN LUNs after migration because the expected WWN presented during migration is not available through the correct fabric or zoning path.
  3. NPIV and SAN support requirements
    • Virtual Fibre Channel for Hyper-V relies on NPIV. A new NPIV port is created on the host each time a VM with a virtual HBA starts, and it is removed when the VM stops on that host.
    • The HBA ports used for Virtual Fibre Channel must be configured in a Fibre Channel topology that supports NPIV, and the SAN must also support NPIV ports.

Recommended approach:

  1. Match virtual SANs consistently across all cluster nodes
    • Ensure every migration target host has the required physical Fibre Channel ports connected to the same SAN fabric.
    • Ensure the virtual SAN definitions on every host map to the correct physical ports for that SAN.
    • Use separate virtual SANs for separate SANs or separate path groups as needed.
  2. Validate live migration WWN behavior
    • Confirm the VM’s virtual Fibre Channel adapters are configured so both WWN sets used during live migration are valid in the SAN environment.
    • Since Hyper-V alternates between Set A and Set B WWNs during migration, zoning and storage presentation must allow both WWN identities to reach the required LUNs.
  3. Verify NPIV end to end
    • Confirm NPIV is supported and enabled in the Fibre Channel topology used by the host HBAs.
    • Confirm the SAN is configured to accept NPIV ports from all cluster nodes that can host the VM.
  4. Check destination host storage visibility before migration
    • Ensure the destination host can access the VM storage paths and that the SAN connectivity is correct before migration.
    • In clustered environments, also verify host and cluster health, supported Windows Server versions, and that storage is reachable on the destination host.
  5. If this affects Windows Server 2012 or 2012 R2 guest clustering over Synthetic Fibre Channel
    • There is a documented issue where, after live migration, the target Hyper-V host cannot restore the Synthetic Fibre Channel LUN on behalf of the VM.
    • For Windows Server 2012 R2, install update rollup 2903939.
    • For Windows Server 2012, apply the supported hotfix described for that issue.
  6. If old WWPNs remain on the source host after migration
    • A known Windows Server 2012 R2 issue can leave the old WWPN on the source host because the old WWPN is not deleted from the Virtual Fibre Channel on the source host.
    • That condition is tied to a WMI issue where the HBA driver never receives the corresponding WMI call.

In practice, the key requirement is that the VM’s virtual Fibre Channel adapters, both live-migration WWN sets, the host virtual SAN definitions, NPIV-capable HBAs, and SAN zoning all line up identically across every possible source and destination host. If any destination host presents the VM through the wrong physical Fibre Channel ports or a WWN that is not zoned to the required LUNs, the guest loses SAN access after migration.

AI-generated content may be incorrect. Read our transparency notes for more information.

Was this answer helpful?

1 person found this answer helpful.

0 additional answers

Sort by: Most helpful
Most helpful Newest Oldest

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.