Event ID 16010 and 20148: Hyper-V storage operations fail and VMs go missing

Fix it now

The management service tried to reach a path and could not, so machines drop out of the console and storage operations fail part-way. The machines themselves are almost always intact on disk; what has broken is the registration that tells the host where they live.

Get-VMHost | Select-Object VirtualMachinePath, VirtualHardDiskPath
Get-VM | Select-Object Name, State, Path
Get-Volume

1. Read the path out of the event and compare it with the host defaults and with what Get-VM still believes. A path that no longer resolves is the answer.
2. Confirm the storage is present. For clustered storage, check the volume is online in Failover Cluster Manager rather than in Disk Management.
3. For a machine that has vanished from the console but whose files exist, check it first with Compare-VM -Path '<path to the .vmcx>' and read the incompatibilities it reports.
4. Register it in place with Import-VM -Path '<path to the .vmcx>' -Register, which keeps the files and the identifier where they are.

Register in place. Importing as a copy creates a new identifier, which quietly breaks the per-machine disk permissions and any cluster configuration that refers to the old one.

If every machine appears with a path that resolves, stop here. If several vanished at once, the next section explains why that is one fault rather than several.

Why it happens

A virtual machine is a set of files: a configuration file, its runtime state and its virtual disks. The management service keeps a registration pointing at that configuration file, and the console shows you registrations rather than files. When a pointer cannot be followed, the machine drops out of the console and every operation against it fails, even though nothing has been deleted and the files are exactly where you left them.

Storage changes are the usual trigger. A drive letter that moved, a LUN that came back offline, a cluster volume that is paused, a file share that is unreachable, or a folder moved with a copy tool rather than through Hyper-V all break the pointer in the same way. Hyper-V’s own storage move updates the registration as it goes, which is the entire difference between Move-VMStorage and dragging a folder in Explorer.

Neither the events nor the code that comes with them is published by Microsoft, and none of them is specific enough to diagnose from anyway. Treat them as markers and work from the path named in the entry beside them. That path tells you whether you are looking at a volume, a share, a cluster volume or a folder somebody moved, and each of those has a different fix.

Full reference

Working out what the host cannot reach

Import, compare and move, and what each one changes

Run Compare-VM before every import you are not certain about. It costs nothing, changes nothing, and it turns a failed import into a list of things to fix first. The usual entry on that list is a virtual switch the machine expects and this host does not have.

Machines on a file share

1. Test the path from the host console, not from your workstation. The two use different credentials and often get different answers.
2. Grant the host computer accounts full control on the share and on the folder. The worker processes run as the host, so the host’s computer account is what reaches the file server.
3. If the console works and remote management does not, configure constrained delegation for the file server so your credentials can be passed on.
4. Re-test from both places afterwards, because fixing one does not fix the other and you want to know which you fixed.

What not to do

• Do not repair this by editing the host’s data root by hand or recreating the links it keeps there. Use import and storage move so the service writes its own registrations.
• Do not force a clustered disk online outside the cluster. Two nodes writing to the same volume corrupts it, and the corruption is not always immediate or obvious.
• Do not import as a copy to make a missing machine reappear. It works, and it gives the machine a new identifier that its disk permissions and any cluster configuration do not know about.
• Do not move virtual machine folders with a file copy tool. Use Move-VMStorage, which rewrites the registration as part of the move rather than leaving you to notice later.

After a move done the wrong way

If the files have already been copied by hand, the recovery is straightforward as long as you do it in order. Put the files where they are going to live permanently. Run Compare-VM and fix what it reports. Register in place. Then re-apply the per-machine permissions on the disks, because a file copy does not carry them and the machine will fail to start with a storage error that looks like a completely different problem. Only then start the machine.

None of this costs anything. It is a storage path and registration problem on infrastructure you already own and licence, and re-importing a machine you already have consumes nothing.

Every code this article covers

Confirm the fix worked

1. Every machine appears in Get-VM with a path that resolves.
2. One recovered machine starts and boots.
3. A storage operation that previously failed now completes.
4. For clustered storage, Get-ClusterSharedVolume shows the volume online and the mount point present on the node.
5. Machines recovered by file copy have their per-machine disk permissions back.

Questions people ask about this