Skip to content

V2V Import Fails

Two distinct symptoms, two different causes. Match the exact message in the task drawer.

Symptom 1 — "filesystem was mounted read-only"

A vCenter/ESXi → KVM V2V import fails almost immediately after the source disk finishes downloading, during the Inspecting the source step:

virt-v2v: error: filesystem was mounted read-only, even though we asked
for it to be mounted read-write.  This usually means that the filesystem
was not cleanly unmounted.  Possible causes include trying to convert a
guest which is running, or using Windows Hibernation or Fast Restart.

The task shows ❌ Failed in the task drawer right after Inspecting the source, even though the source VM appears poweredOff in vCenter.

Root cause

The guest's NTFS boot volume has its dirty bit set. libguestfs refuses to mount a dirty NTFS filesystem read-write (to avoid corrupting it), so virt-v2v can't inject drivers and aborts. poweredOff in vCenter is not proof the filesystem was cleanly unmounted — it only means the VM isn't currently running.

The two common causes, in order of likelihood:

  • Windows Fast Startup (hybrid shutdown) — enabled by default on many Windows builds. It leaves the boot volume in a hibernated-resume state even though the VM shows powered off.
  • Actual hibernation was used to shut the guest down instead of a full shutdown.

Less common: the VM was suspended in vCenter rather than truly powered off — check for suspended, not just anything other than poweredOn.

Fix

Disable hibernation on the guest before retrying the import:

  1. Before powering anything on, in vCenter change the source VM's network adapter to the VLAN/port group already created for it on the destination MFCONSOLE cluster — do not leave it on its old vCenter network for this step.
  2. Power on the source VM in vCenter.
  3. Inside Windows, elevated Command Prompt / PowerShell: 
    powercfg /h off
    This disables hibernation and also removes the "Turn on fast startup" option from Power Options (fast startup depends on hibernation).
  4. Fully shut down — not Restart: 
    shutdown /s /t 0
  5. Confirm in vCenter the VM shows poweredOff (not suspended).
  6. Retry the import from mfcloud.

Set the network before power-on, not after

Step 1 has to happen first. Powering the guest on while it's still attached to its old vCenter network, then moving it, risks the VM coming up on the wrong segment — switch it to the MFCONSOLE VLAN while it's off.

Symptom 2 — "qemu-nbd did not start up"

The import gets further — the source disk downloads, and it fails during Setting up the source:

qemu-nbd: Failed to blk_new_open '<vm>-000002.vmdk': Could not open
backing file: Could not open '<vm>-000001.vmdk': No such file or directory
virt-v2v: error: qemu-nbd did not start up.  There may be errors printed
by qemu-nbd above.

The "qemu-nbd did not start up" line is generic boilerplate — the real error is the Could not open backing file line right above it in the task log.

Root cause

The source VM's disk is a snapshot chain: <vm>-000002.vmdk is a snapshot delta whose descriptor references a parent delta, <vm>-000001.vmdk, as its backing file. Only the top-of-chain file got downloaded, so the parent is missing once virt-v2v tries to open it.

There's a preflight check that's supposed to catch this before the import even starts (routers/vms/v2v.py — refuses to queue the import if vCenter reports an active snapshot on the VM), but it can miss this specific case: deleting a snapshot in vCenter clears the "has snapshots" state immediately, even when the background consolidation of the delta files back into the base disk hasn't finished or silently failed. The object model says no snapshot; the datastore still has the delta files.

Fix

  1. In vCenter, select the source VM → Summary tab → look for a "Configuration Issues: disks consolidation needed" banner. If present, right-click the VM → Snapshots → Consolidate.
  2. If Consolidate isn't offered, open Snapshot Manager → Delete All, then check the datastore browser for the VM's folder — you want to see only <vm>.vmdk, no -000001.vmdk / -000002.vmdk files left over.
  3. Retry the import only once the datastore shows a single flat disk file.

Fix the guest before you retry

There's no resume or dedup on the source download — every V2V attempt wipes the local staging copy and re-downloads the entire disk from vCenter from scratch. Retrying before consolidation is actually finished just re-downloads the disk to fail at the same step again.

Good news: no manual cleanup needed

The staged download is removed on every exit path — success, failure, or cancel — so a failed import never leaves a partial copy of the disk behind on the datastore.

See also