On Windows Server 2019 Hyper-V Cluster VM failed to start after proper shutdown. Event ID 1069 & 21502.

Question

Dear Community,

I have a 6 node Windows Server 2019 Hyper-V cluster. After a proper VM shutdown I can not start the VM. The VM is in failed state in Failover Cluster Manager. The configuration resource is in failed state:

The following events registered after this error:

Event ID 1069:
Cluster resource 'Virtual Machine Configuration SAM-SRV' of type 'Virtual Machine Configuration' in clustered role 'SAM-SRV' failed. The error code was '0x2' ('The system cannot find the file specified.').

Event ID 21502:
'Virtual Machine Configuration SAM-SRV' failed to register the virtual machine with the virtual machine management service.

The Virtual Machine Management Service failed to register the configuration for the virtual machine 'FA544067-DEE7-4B03-AA22-4826DEB21CCF' at 'C:\ClusterStorage\volume1\SAM-SRV': The system cannot find the file specified. (0x80070002). If the virtual machine is managed by a failover cluster, ensure that the file is located at a path that is accessible to other nodes of the cluster.

What I tried to fix this error:
The configuration files are accessible from the server:

Quick migrate the server: Server migrates, but stays in failed state at Failover Cluster Manager. In Hyper-V manager I can not see the server.

Can you help me? Did anyone experienced this error?

Thank You,

Krisztián

Answer 1

Hi，

1. Please check the state of the CSV which stores the VM, check if the CSV is online, and accessible via C:\ClusterStorage\volume1.
2. Please check the files of the VM, verify if the VHD of the VM is well in CSV.
3. If the issue only occurs on the VM and the VHD of the VM is accessible, we may try to recreate the VM with the VHD, check if the new VM can be online. (Use the original VHD to recreate the VM will keep the data of the VM, only configuration file will be recreated.)

Thanks for your time!
Best Regards,
Anne

-----------------------------

If the Answer is helpful, please click "Accept Answer" and upvote it.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 2

Old question but I recently had the same issue. Recreating the machine as mentioned in the answer above started the machine in its pre-checkpoint state with a lot of missing updates/data and broken domain trusts. So for anyone who has the same issue in the future, here's what I did:

1. Delete the affected VM role(s) from the cluster otherwise you will not be able perform the following steps.
2. Make a backup of your disks just in case.
3. Next we will need to fix the VHD chain so the differencing disk (.avhd/.avhdx) knows which parent it is associated with. We can do this with Set-VHD and the -IgnoreIdMismatch switch:

Set-VHD -Path 'Path to your differencing disk' -ParentPath 'Path to the main virtual disk' -IgnoreIdMismatch

1. The two disks are now linked to each other and can now be merged using Merge-VHD: Merge-VHD -Path 'Path to your differencing disk' -DestinationPath 'Path to the main virtual disk'
2. Perform the steps above for any additional data disks you may have connected to the VM(s).
3. Now the disks are merged we can start the VM(s), they should now boot correctly in their post checkpoint state with the updated configuration version.
4. Rename the VM in Hyper-V to remove the checkpoint addition Hyper-V added to the machine.
5. Re-add the machines to the cluster using the wizard.