About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.
Many organisations run their servers as virtual machines on one or two physical Hyper-V hosts. The virtual machines get the attention: they are what users depend on, and they are what most backup plans are built around. The host itself is easy to forget, until its boot drive fails, its motherboard is replaced or Windows on it will not start.
At that point the question is not only "are the virtual machine files safe?" but "can a new or rebuilt host run them?". Microsoft's documentation shows that a virtual machine depends on several things held by the host, not inside its own files. This article sets them out for a standalone host, so they can be written down before they are needed.
It does not cover failover clusters, where other hosts take over, or guarded fabrics using the Host Guardian Service, which have their own processes.
The host is a physical server with its own recovery plan
A Hyper-V host is an ordinary physical Windows Server with a role added. Everything that applies to a physical server applies to it: firmware, drivers, storage controller settings, network adapter configuration, the operating system and its updates.
In our reading, there are two broad ways to bring a failed host back:
- Restore the host from its own system backup onto the same or identical hardware.
- Rebuild the host: install Windows Server and the Hyper-V role on repaired or replacement hardware, recreate its configuration, then bring the virtual machines back onto it.
The second path is common when hardware changes, and it is the one where the dependencies below matter most. Even with the first path, it is worth knowing them, because a host restore that comes back on different hardware can meet the same problems.
Bringing virtual machines back: import, and the three ways to do it
Microsoft describes export and import as a quick way to move or copy virtual machines. An export gathers all required files into one unit: virtual hard disks, configuration files and any checkpoint files. Importing registers the virtual machine with a Hyper-V host, either the same one or a new one. Microsoft adds that when importing to the same host you don't need an export first, because Hyper-V tries to recreate the virtual machine from the files that are there.
The import offers three types, which matter in recovery:
- Register in place uses the files where they are and retains the virtual machine's ID.
- Restore copies the files to a location you choose, or the default location, and keeps the virtual machine’s exported ID.
- Import as a copy copies the files to a location you select, and with the option to generate a new ID the virtual machine will be given a new unique identifier, not the one in the configuration file. Microsoft notes this is useful when importing several copies, since each must have a unique identifier.
Our reading is that for a recovery of the original virtual machines, keeping the original identity is usually what you want, and that a copy with a new ID belongs to test restores, where the original might still exist elsewhere. Whichever is chosen, it is a decision, and it should be made on purpose.
The files can come from an export, from the old host's storage if it survived, or from whatever a backup product restores. In each case, the receiving host has to be ready for them.
Dependency 1: the configuration version
Every Hyper-V virtual machine configuration has a version number. Microsoft's guidance is clear on direction: you can only import a virtual machine if the Hyper-V host supports that configuration version. Typically that means a virtual machine can go to a host running a newer version of Hyper-V, but one created on a newer version can't be imported to an older one.
Microsoft's configuration version page explains that virtual machines are created at the host's default version, that older versions can be chosen when a virtual machine must be able to move to an older host, and that a virtual machine's version can be upgraded once its hosts have been upgraded.
For a rebuild, verify each VM configuration version against the explicit supported-version table for the target host. A newer operating system can drop support for older configuration versions. Record the host build and configuration versions, and retain suitable installation media rather than assuming a simple newer-is-compatible rule.
Dependency 2: virtual switches, by name
A virtual machine's network adapter connects to a virtual switch by name. Microsoft's own example on the Compare-VM page shows an import that fails because the virtual network adapter was connected to switch Production and the host had no switch by that name. The error reads "Could not find Ethernet switch 'Production'".
Compare-VM produces a compatibility report so that such issues can be resolved before import. The Import Virtual Machine wizard also helps you fix incompatibilities between hosts, which Microsoft says are commonly differences in memory, virtual switches and virtual processors.
Microsoft's virtual switch guide describes three switch types (external, internal and private) and notes that creating an external switch warns that it may disrupt network connectivity, since it takes over a physical adapter.
Our recommendation is to record, for each host:
- every virtual switch name and type
- which physical adapter each external switch uses, and any VLAN or teaming arrangement the network relies on
- which virtual machine adapters connect to which switch
Recreating the intended switch mapping can resolve that specific incompatibility; other import checks still apply.
Dependency 3: virtual TPM certificates and key protectors
This is the dependency most likely to surprise, and the one with the most serious consequence.
Generation 2 virtual machines can have a virtual Trusted Platform Module, which modern guest operating systems use for features such as BitLocker. Microsoft's Generation 2 security settings page says a virtual machine with a virtual TPM can be migrated to any host running a supported version of Windows Server or Windows, but if you migrate it to another host, you might not be able to start it. The key protector must be updated to authorise the new host.
Microsoft's troubleshooting guide for virtual TPM, shielded VM and HGS issues explains why. Virtual TPM and shielded virtual machines require signing and encryption certificates, and problems arise if they are missing or improperly restored during migration or export and import. It adds that certificates that are accidentally deleted or not restored cause virtual machines to become nonoperational. The error it lists is "The key protector for the virtual machine could not be unwrapped."
The documented resolutions include exporting the certificates with their private keys from the source host and importing them on the destination. For missing certificates, Microsoft's guide describes creating a new virtual machine from the original virtual hard disk and configuring the virtual TPM and key protector settings again.
In our reading, the weak point for a standalone host is plain: on a host without a Host Guardian Service, those certificates live on the host. If the host's operating system is lost and the certificates were never exported, there is nothing to import. Our understanding is that a new virtual TPM is then a different TPM as far as the guest is concerned, so anything in the guest that was sealed to the old one, such as BitLocker keys, would need its own recovery method, for example a BitLocker recovery key. This is our inference from how TPM-sealed keys work, not a sentence from the Hyper-V pages, and it is worth confirming in your own test.
Our recommendations:
- Know which virtual machines have a virtual TPM enabled.
- Export the host's virtual TPM certificates with their private keys, protect the export as sensitive key material, and store it away from the host. In our view an export with private keys deserves the same care as a password vault, because it is what lets a host unlock those virtual machines.
- Make sure guest BitLocker recovery keys are recorded somewhere that does not depend on the virtual machine starting.
- Test the move on a non-production virtual machine with a virtual TPM before you need it.
Checkpoints are not backups
A failed host often has checkpoints on its virtual machines, and it can be tempting to treat them as recovery points. The cited checkpoint page describes Windows 10 and 11 Hyper-V; check the actual Windows Server version and VM settings before applying its client-interface instructions to a host. Microsoft's checkpoint guidance is direct about standard checkpoints: a snapshot is not a full backup and can cause data consistency issues with systems that replicate data between nodes, such as Active Directory.
Production checkpoints use the Volume Shadow Copy Service inside Windows guests, or a file system freeze on Linux, to capture a data-consistent state without memory. They are the default. Microsoft also documents a setting under which, if a production checkpoint fails, a standard checkpoint is created instead, and another under which it is not.
In our reading, two points follow. First, checkpoints commonly share the VM’s storage failure domain, so whatever destroys the virtual machine's files usually destroys its checkpoints too. Second, Microsoft warns that when Apply is chosen without first creating a checkpoint, the action cannot be undone, so applying one during a stressful recovery should be a deliberate choice. The dialog also offers Create Checkpoint and Apply, which captures the current state first; neither option substitutes for an independent backup. Restoring a domain controller from a standard checkpoint, in particular, carries the replication risk Microsoft names.
What to record before the host fails
These are our recommendations, drawn from the dependencies above. A short document per host, kept away from the host, covers most of a rebuild:
- Hardware and firmware: model, firmware version, storage controller mode, network adapters.
- Windows Server version and edition, and where the installation media is.
- Storage layout: where virtual machines and virtual hard disks are stored.
- Virtual switches: names, types, physical adapters, VLAN or teaming details.
- Each virtual machine: generation, configuration version, memory, processors, switch connections, virtual TPM on or off.
- Virtual TPM certificates: confirmation they are exported with private keys, and where the protected export is held.
- Guest recovery keys for any BitLocker-protected virtual machine.
- Backups: what backs up the virtual machines, what backs up the host, and when each was last restored in a test.
Then test it once. Rebuild a host, even a spare or lab machine, from the document, import one ordinary virtual machine and one with a virtual TPM, and note where the document was missing something.
Compatibility is a table, not an age comparison
A newer Hyper-V host does not necessarily support every configuration version accepted by an older host. Match the VM’s recorded configuration version against Microsoft’s supported-version table for the proposed target. Recreating a switch name resolves only that particular network mapping; it does not establish CPU, memory, storage, security or guest compatibility. Keep the original configuration and all dependent virtual disks together while deciding the supported import route.
The acceptance check should distinguish host recovery from guest recovery. First establish that the VM can be imported with its intended network isolation and storage paths. Then verify its security dependencies, including the key protector for a virtual TPM and any guest disk recovery key. Finally test the application inside the guest. A host that lists the VM successfully has not yet demonstrated that an encrypted guest can boot or that its application data is usable.
Risks and limits of this article
- It covers standalone Hyper-V hosts. Failover clusters and guarded fabrics change several of these answers.
- The virtual TPM guidance comes from Microsoft troubleshooting and settings pages; the effect on guest BitLocker is our inference and is labelled as such.
- Behaviour may differ between Windows Server versions and configuration versions.
- No steps were carried out for this article, and none of the commands in Microsoft's pages were run.
- It does not compare or recommend backup products.
Sources
Writer research: 11 November 2026. Independently reopened for review: 13 November 2026.
- Microsoft Learn: Export and import virtual machines
- Microsoft Learn: Import-VM
- Microsoft Learn: Compare-VM
- Microsoft Learn: Upgrade virtual machine version in Hyper-V
- Microsoft Learn: Create a virtual switch for Hyper-V virtual machines
- Microsoft Learn: Generation 2 virtual machine security settings for Hyper-V
- Microsoft Learn: Troubleshoot vTPM, shielded VM and HGS issues
- Microsoft Learn: Choose between standard or production checkpoints
This article was originally published on .