Slow startup on VMs with Virtual Fibre Channel

Problem

After you enable Virtual Fibre Channel on a Hyper-V VM it takes forever to start up. In this instance forever equals about two minutes. The VM is stuck in the Starting… stat for most of this period.

Analysis

During startup, the Hypervisor waits for LUNs to appear on the virtual HBA before the VM is allowed to boot the OS. When there are no LUNs defined for a VM, i.e. when you are deploying a new VM, the Hypervisor patiently waits for 90 seconds before it gives up. Thus startup of the VM is delayed by 90 seconds if there are no LUNs presented to the VM, or if the SAN is down or misconfigured. Event ID 32213 from Hyper-V-SynthFC is logged:

SNAGHTML24190ea1

Solution

Depending on your specific cause, one of the following should do the trick:

  • Present some LUNs
  • Remove the Virtual HBA adapters if they are not in use
  • Correct the SAN config to make sure the VM is able to talk to the SAN

Author: DizzyBadger

SQL Server DBA, Cluster expert, Principal Analyst

3 thoughts on “Slow startup on VMs with Virtual Fibre Channel”

  1. I have the same issue , as soon as i add VFC to VM , the VM stuck at startup for up to 60-70 sec. And in case of live migration the delay is also 60-70 sec. But i cannot find this event in event viewer.

    Any idea how to solve this issue.

    1. Sounds like you may be experiencing a similar issue. Have you checked the Hyper-V event logs on both hosts during migration?

      Also, ask your SAN admin about multipath-settings and check if the LUNs are mirrored on the SAN-side. I have seen some trouble related to MPIO path verification. If it is disabled on the VM and/or host, try enabling it. If it is enabled, try to disable it.

      The most common issue I see is where the LUNs are only presented to the one set of virtual WWNs. Both sets are used during migration of the VM.

      FC switches (the physical ones) may also be worth looking in to. You may have to update their firmware to properly support virtual FC. The firmware on the SAN itself may also be an issue.

  2. The LUNs are properly configured on the SAN and after 60 sec delay the VMs starts properly and show all LUNs. The issue is delay in startup & live migration.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.