Skip to main content

FAQ: VM Migration and UUID Changes on a Standalone Hyper-V Host

VM Migration and UUID Changes on a Standalone Hyper-V Host

Q1: What happens when a VM is migrated off a standalone Hyper-V host?

A: Unlike clustered setups where Druva queries peer nodes via WMI to track moved VMs, a standalone host operates in isolation.

Expected behavior:

  • Discovery loss: The VM will no longer be found on the original standalone host.

  • Job failures: Scheduled backups for the VM will fail with error codes such as HYPERV10 ("VM not found") or Phoenix279 ("VM UUID not found").

  • No auto-tracking: Druva cannot automatically detect that the VM has moved because no cluster relationship exists.

  • Manual setup required: The VM must be freshly discovered and configured for backup on the destination host (which must also have an active Druva agent installed).

Q2: What errors will appear if a VM is missing from the standalone host?

A: You will typically encounter one or more of the following status messages in the console:

  • HYPERV10 — VM not found for UUID

  • Phoenix279 — Requested Hyper-V Virtual Machine does not exist

  • VM UUID not found

  • VM not found on any host

Q3: What happens if a VM's UUID changes (e.g., due to cloning or re-importing)?

A: When a VM's UUID (BIOS GUID) changes, Druva treats it as an entirely new entity:

  • On the source host:

    • The original backupset becomes orphaned because the old UUID no longer exists.

    • Scheduled backup jobs for the old VM entry will fail with "VM not found" errors.

  • On the destination host (or same host after re-import):

    • The VM appears as a newly discovered, unconfigured VM during the next discovery cycle.

    • It must be configured from scratch for backup protection.

    • Previous backup history and restore points will not link to the new VM entry.

    • An initial full backup is required—incremental backups cannot resume from the old backup chain.

Q4: How often does Druva refresh the VM listing on a standalone host?

A: Druva automatically updates the VM inventory on a Hyper-V host approximately every 6 hours.

  • Manual Refresh: You can trigger a manual discovery/refresh anytime directly from the Druva Management Console.

  • Newly added/imported VMs: Appear as Unconfigured following the refresh.

  • Removed VMs: Remain listed until the next discovery cycle completes.

Q5: Can I avoid taking a full backup after migrating a VM to a new standalone host?

A: No. Even if the VM UUID remains unchanged, moving a VM between standalone hosts creates a new backupset association.

While existing restore points stay linked to the original host's backupset:

  • Incremental backups cannot resume from a different host's backup chain.

  • A new full backup is mandatory on the target host to establish a new baseline.

Q6: What scenarios cause a VM UUID to change on a standalone host?

A: A VM's UUID will change in any of the following scenarios:

  • Importing as a copy: Using the Hyper-V Import wizard with the option "Copy the virtual machine".

  • Recreating configuration: Deleting the .vmcx file and building a new VM attached to the existing VHDX.

  • Cloning: Duplicating the VM manually or via Sysprep.

  • Alternate restores: Restoring a VM from backup to an alternate location (which generates a new VM ID).

  • Hardware swaps: Major host hardware changes that alter the system board UUID (rare).

The VM UUID does NOT change when:

  • The VM is simply powered off and restarted on the same host.

  • Disks (VHDX) are resized or additional disks are added.

  • The Druva agent is reinstalled on the host (UUIDs exist independently of the agent).

Related Articles
Did this answer your question?