Skip to main content

Hyper-V Import

The Hyper-V Import tool transfers virtual machines directly from an individual Microsoft Hyper-V host to eEVOS. This guide covers preparation, saved connections, VM selection, network mapping, job monitoring and validation.

For an existing exported VM image, use the VM Import Wizard. For VMware sources, see vSphere Import.

Result: A successful import creates a powered-off destination VM. The source remains shut down and its original disks are retained. Guest boot and application checks must be performed separately.

Before you begin

  • Have administrator access to eEVOS and the Windows Hyper-V host, with the Hyper-V role and PowerShell module available to the Windows account.
  • Create a current, recoverable backup and agree on downtime, application shutdown, acceptance checks and a rollback window.
  • Prepare a mounted destination drive. Reserve the full provisioned virtual disk capacities plus 256 MiB per VM and operational headroom; thin source-file size is not the capacity estimate.
  • For checkpoints, reserve space on the source host for temporary standalone disk copies.
  • Prepare destination networks and switch profiles. Plan an isolated first boot where duplicate identities could reach production.
  • For TPM-bound encryption, verify recovery material or prepare decryption before migration.

Source host and connectivity

Requirement Check
WinRM Configured listener, reachable from eEVOS: normally TCP 5985 for HTTP or 5986 for HTTPS, unless a custom port is configured.
Disk transfer TCP 445, administrative drive shares such as D$, account access to the disks and SMB 3 encryption.
Source paths Host-local disk and staging paths. UNC source paths, SCVMM and automatic cluster-owner discovery are unsupported. Connect to the current owning host.

Test connection checks WinRM and inventory access. It does not prove that SMB disk access, destination capacity, conversion or guest boot will succeed. No migration agent is required inside the guest.

Manage connections

  1. Open VM tools → Hyper-V Import → Manage connections.
  2. Choose Add connection. Enter a connection name, host name/IP, Windows administrator account and password.
  3. Select WinRM transport and port. HTTP uses NTLM message encryption; HTTPS adds TLS. Prefer a trusted certificate matching the host name. Leave Allow an untrusted HTTPS certificate disabled unless you deliberately accept that source certificate.
  4. Set a host-local temporary folder for flattening checkpoints, for example C:\ProgramData\euroNAS\HyperVImport.
  5. Choose Save connection, select the host and run Test connection.

Saved passwords are encrypted and are not displayed in the list. When editing, leave Password blank to retain the saved password. Deleting a connection removes the saved record, not source VMs; its connection cannot be deleted during an active import.

Start an import

1. Connect

Return to the overview, choose Start Hyper-V Import, select the saved host and click Next to discover its VMs.

2. Select VMs

  1. Select each workload and its Target drive.
  2. Check Target name: 1–35 letters, numbers or hyphens. Names must be unique; existing destinations are never overwritten.
  3. Verify Guest OS. Recognized metadata preselects a profile; choose it manually when unavailable. Linux KVP reporting may be absent, especially for stopped guests.
  4. Read any reason shown for an unavailable VM. Off and Running sources can be discovered; saved, paused and transitional states are blocked.

3. Map networks

Map every used source switch/access-VLAN pair to an eEVOS network or virtual switch. For a profile-capable switch, optionally select a compatible Switch network profile. Verify that the target policy supplies the intended VLAN and connectivity. Classic networks do not use switch profiles.

Choose Do not connect (no adapter) to omit adapters for one mapping, or Import without network adapters to omit all adapters. Mapped adapters retain their MAC addresses; omitted adapters can be added later in VM Management.

4. Review

  1. Verify source-to-target names, drives, guest profiles and every network/profile mapping.
  2. For running sources, explicitly select Shut down selected running source VMs gracefully for this import, or shut them down yourself and rediscover.
  3. Within the agreed downtime window, choose Start import.

No forced power-off: a running source must shut down gracefully before conversion. If graceful shutdown fails, that VM fails import. Keep the source off and unchanged throughout conversion and validation.

Disks are converted over encrypted, read-only SMB. Checkpoint disks are flattened on Hyper-V first; checkpoint history and Hyper-V runtime policies are not transferred. Import neither deletes the source nor starts the destination.

Monitor jobs

The overview shows each VM, target drive, phase and result. Jobs continue when the browser is closed. Return to Hyper-V Import, use Refresh if needed and open Job log for details.

A batch may contain completed and failed VMs. Inspect every row. A conversion percentage indicates the current phase, not remaining time. Complete — powered off confirms conversion, not guest or application validation. Never start a destination while its import is active.

TPM, encryption and Secure Boot

An ordinary Generation 2 VM with TPM can be imported with a new destination TPM 2.0. The source TPM identity, key protectors and sealed keys are not transferred. Shielded VMs are unsupported.

  1. Identify encrypted volumes and other secrets bound to the source TPM.
  2. Verify recovery keys and an approved recovery procedure, or decrypt affected disks before migration.
  3. For each affected VM, acknowledge Import with a new TPM 2.0. I have prepared recovery keys or removed TPM-bound encryption. Review repeats the warning.

The importer does not verify keys, suspend encryption, decrypt disks or re-bind the guest. Windows/BitLocker recovery has not been validated. Source protection remains unchanged.

The new persistent software TPM is initialized on first start. Include its state in backups. On supported shared storage, eligible nodes need the required TPM runtime. Recreating missing TPM state creates another identity and cannot recover sealed keys; restore the correct state when identity continuity is required.

Generation 1 maps to BIOS and Generation 2 to UEFI. Secure Boot requires the Windows / Secure Boot profile and signed OVMF firmware. General Linux Secure Boot template conversion is unsupported.

Validate and cut over

  1. After completion, open VM Management and check CPU, startup memory, firmware, disk count/order, networks and console access.
  2. Keep the source shut down. Start the destination, initially isolated where appropriate.
  3. Check boot, all disks, partitions, mounts, storage/network drivers and application data.
  4. Check IP addresses, routes, DNS, firewall rules and guest interface naming; preserving the MAC does not guarantee identical interface names.
  5. Validate services, databases, scheduled tasks, licenses, time synchronization and client access with the application owner.
  6. Complete any approved encryption recovery and TPM re-binding. For shared storage, validate operation on another eligible node.
  7. Create and verify a destination backup. Retain the source until formal acceptance.

Troubleshooting

Symptom Action
Connection fails Check DNS/IP, WinRM listener, transport/port, firewall, Windows credentials and Hyper-V PowerShell access. Use a trusted matching HTTPS certificate.
Test works; disk access fails Check TCP 445, administrative shares, SMB 3 encryption and disk permissions.
VM missing or unavailable Connect to its current owning host. Read the displayed reason: shielding, replication, pass-through/shared disks, trunk adapters and unsupported power states are blocked.
Capacity or checkpoint flattening fails Check full virtual disk capacity plus overhead, source staging space and permissions. Do not remove active job files or checkpoint parents.
Only some VMs complete Inspect per-VM logs and retry failed VMs after fixing the cause. Completed target names already exist.
Destination does not boot Inspect console errors, firmware mode, disk order, guest profile, drivers and encryption recovery requirements.
TPM or cross-node startup fails Check supported TPM helper/runtime, state paths and ownership, eligible-node access, cluster authentication and storage health.

The importer attempts to clean a newly created failed destination. If it was started externally, it is retained for review. Inspect logs before retrying or deleting anything; do not manually remove VM disks or mounted work folders.

Rollback and support

Shut down and isolate the destination before restoring or restarting the source. Account for writes made after cutover, which are absent from the retained source. Never run both copies on the same production network with duplicate IP, MAC or host identities.

For support, record source host/VM, target name/drive, time, per-VM phase/result, job log and exact console errors. State whether checkpoints, Secure Boot, TPM or encryption are involved. Do not include passwords or recovery keys in routine logs or screenshots.

Based on Hyper-V Import Administrator User Guide 1.0, October 2026; feature baseline 17 October 2026. Available capabilities depend on the installed eEVOS release.

Back to top