Неопознанная ошибка 0x80004005 hyper v

Migration operation on ‘<VM Name>’ failed.

1. 0x80041024
2. 0x8000FFFF

Virtual machine migration operation failed at migration source.

Failed to create folder.

Event ID: 21002 & 16300 & 1106

Cannot load a virtual machine configuration: Unspecified error (0x80004005). (Virtual machine ID <Virtual Machine GUID>)

vm\service\migration\vmmsvmmigrationdestinationtask.cpp(1781)\vmms.exe!00007FF650130A43: (caller: 00007FF65013359D) Exception(312) tid(19b4) 80004005 Unspecified error

vm\service\vmmgr\vmmsvirtualmachinemanager.cpp(4128)\vmms.exe!00007FF64FC867EB: (caller: 00007FF64FD83CC0) LogHr(97) tid(19b4) 80004005 Unspecified error
Msg:[vm\service\vmmgr\vmmsvirtualmachinemanager.cpp(5782)\vmms.exe!00007FF65025928F: (caller: 00007FF64FDA68AE) Exception(308) tid(19b4) 80004005 Unspecified error
]

Note: The Memory ranges, process ID’s and exception codes do not need to match the above, just the presence of 80004005.

1. You cannot live migrate a VM back onto a hypervisor where it has been previously.
   This can occur if your Hypervisor loses storage (i.e. iSCSI). The Hyper-V VMMS process will obtain an opportunistic, persistently stuck request for a handle to a resource that was on the disk but can no longer be found. Restarting the hypervisor doesn’t clear the lock because it re-establishes when VMMS starts. Even if presented with the file resource, the lock will not establish.In the interest of safety, I strongly recommend exporting/Live migrating all VMs off of the hypervisor before attempting this fix. If you do not, you may lose the VMs and have to re-import them from their config files.Once the hypervisor has been drained of all VMs. Open services.msc and stop all Hyper-V processes. If they will not stop, reboot and then stop themBrowse to C:\ProgramData\Microsoft\Windows\Hyper-V.

   Delete data.vmcs

   Delete the contents of all xxxx Cache folders (e.g. Groups Cache, Planned Snapshots Cache… etc)

   Delete the contents of the Resource Types folder

   Reboot the server and retry the live migration

2. Delete the VM configuration files for the VM in question and attach its existing VHDX(s) to a new set of configuration files. This will force the creation of a new VMID which will bypass the lock. This will not however solve the original issue (which may lead to other problems in the future) and for Windows VM’s may require Windows to be reactivated.

Event ID:
20864

1. The configuration file references a VM checkpoint data-set that either has been lost from the file system or does not exist in the context of a VM that has been restored from backup. You will need to restore the checkpoint or edit the Virtual Machine Configuration file to resolve the error.For more information see ‘Hyper-V VM Stuck checkpoint after restore from backup‘

Event ID: 16000

1. One or both of the Hyper-V servers has an invalid or inaccessible IP address/network address on the “Incoming live migrations” list on the “Live Migrations” tab in Hyper-V settings.
2. The live migration network is down, the/a cable is unplugged or faulty.
3. On the destination Hypervisor issue the command:
   netstat -an | find "6600"
   If the query returns no results for TCP 6600 issue the command:
   net stop vmms & net start vmms
   Now re-test the netstat command.
   If the initial netstat command returns a result, or after it returns a result the migration still does not work, there is a firewall blocking traffic into TCP port 6600 on the destination hypervisor.

For more on this, seem my in-depth article.

1. Check that you have enough disk space on the volume to perform the VSS. If your volume is sub-15%, try using the Hyper-V Manager to change the snapshot directory to another volume – plug in an external NTFS formatted hard drive if you have to.
2. Check the permissions of the VHD stated in the error.
   icacls “C:\Users\Public\Documents\Hyper-V\Virtual Hard Disks\<VHD File>” /grant “NT VIRTUAL MACHINE\Virtual Machines”:F
3. Check that you can manually checkpoint/snapshot the VM while it is running.
   In Hyper-V Manager or in PowerShell, force a checkpoint on the VM and then delete it and wait for it to merge back. If this works, you are not having a physical VSS issue. If it fails, you need to troubleshoot this and not the WSB error.
4. Live Migrate the VM off of the current server and onto a different Hypervisor, attempt the backup here, then bring it back to the original server and try again. This process will reset the permissions on the VM file set. If you cannot live or offline migrate the VM, the you need to troubleshoot this and not the WSB error.
5. Ensure that all VHDX files associated with the VM are on the same storage volume and not spread across multiple Volumes/LUNs (be it individual disks, logical RAID or iSCSI disks). If they are, move them to a common location and retry the operation.

Event ID:
32000

1. Under Hyper-V Settings> Replication Configuration. Ensure that the path shown under ‘Specify the default location to store Replica files:’ is a valid path on the server

For more on this, see my in-depth article.

1. If you are using a management console (not the local Hyper-V console to perform the migration. You must setup Kerberos Constrained Delegation for all of your Hyper-V hosts machine accounts in Active Directory.
2. Ensure that both NetBIOS and fully qualified DNS entries exist in the Constrained delegation (click the “Expanded” check box to verify this) e.g. myserver1 and mysever1.mydomain.local for both “CIFS” and “Microsoft Virtual System Migration Service”.
3. For Hyper-V 2008, 2008 R2, 2012 and 2012 R2 “Trust this computer for delegation to specified services only” should be used along with “Use Kerberos only”.
4. For Hyper-V 2016 and 2019 or a mixed environment “Trust this computer for delegation to specified services only” must be used along with “Use any authentication protocol”.

1. For more on this see 0x80004005, Event ID 21002 & 16300 & 1106

Event ID: 20306

1. The Live Migration firewall rules have not been enabled in Windows Firewall (or your third party firewall). This is especially easy to forget on Server Core and Hyper-V Server installs.
2. No DNS server(s) or invalid DNS server(s) have been specified on the network configuration for the hypervisor.
3. Specified DNS server(s) are unreachable.
4. An intermediate firewall or IDS blocked the request. Ensure that you check that your migration NIC connections are not running in a ‘public/restricted LAN profile.

Event ID: 20306

1. If you are using a Windows NIC Team, there is a chance that the Hyper-V Management Service loaded before the NIC Team converged. This created a failed race condition. Consequently, the VMMS service will not have bound to Port 6600, causing this error. You can check for this condition by executing either of the following.
   CMD:
   netstat -an | find "6600"
   PowerShell:
   netstat -an | find `"6600`"If no results are returned for TCP Port 6600, you are impacted by this race condition.
   to solve the issue in the immediate term, execute either of the following.
   CMD:
   net stop vmms & net start vmms
   PowerShell:
   restart-service vmmsTo resolve the issue long-term. Use service.msc to set the ‘Hyper-V Management Service from ‘Automatic’ start to ‘Delayed Start’. This will usually be sufficient to ensure that the service binds correctly. If it is not, you will need to add a watchdog on the port binding and service.
2. An intermediate firewall or IDS blocked the request. Ensure that you check that your migration NIC connections are not running in a ‘public/restricted LAN profile.

Event ID: 20302, 20306

The Virtual Machine Management Service failed to authenticate the connection for a Virtual Machine migration at the source host: The logon attempt failed (0x8009030C).

The Virtual Machine Management Service failed to establish a connection for a Virtual Machine migration with host ‘<hostname>’: The logon attempt failed (0x8009030C).

Live Migration worked previously and Kerberos Constrained Delegation is verified as being correctly setup on the Domain Controller. Port 6600 is correctly servicing on both Hyper-V peers on the correct IP interface.

If you enable Kerberos Ticket Auditing on your domain controllers you receive Event ID 4769 with a failure code of 0x29:

A Kerberos service ticket was requested.

Account Information:
Account Name: <hostname>$@<domain name>
Account Domain: <domain name>
Logon GUID: {00000000-0000-0000-0000-000000000000}

Service Information:
Service Name: Microsoft Virtual System Migration Service/<fqdn>
Service ID: NULL SID

Network Information:
Client Address: ::ffff:172.16.1.8
Client Port: 58871

Additional Information:
Ticket Options: 0x40830000
Ticket Encryption Type: 0xFFFFFFFF
Failure Code: 0x29
Transited Services: –

Error Code 0x29 or error KRB_AP_ERR_MODIFIED means that the Kerberos message checksum failed and the message is suspected of being modified in transit as a result of the checksum mismatch.

Possible ‘natural’ explanations for this include:

1. The authentication data was encrypted with the wrong key for the intended server.
2. The authentication data was modified in transit by a hardware or software error, or by an attacker.
3. The client sent the authentication data to the wrong server because incorrect DNS data caused the client to send the request to the wrong server.
4. The client sent the authentication data to the wrong server because DNS data was out-of-date on the client.

In this case it is likely that it is being caused by a bug in the Kerberos Service on Windows Server Domain Controllers as identified in an emergency out-of-bound patch release on 14th November 2021 for Windows Server 2008 R1 and higher.

View: Windows Message Centre Announcement

“Take action: Out-of-band update to address authentication issues on DCs relating to Kerberos delegation scenarios

Microsoft is releasing Out-of-band (OOB) updates today, November 14, 2021, to resolve issues in which authentication might fail on DCs with certain Kerberos delegation scenarios on all supported versions of Windows Server when used as a Domain Controller. To get the standalone update package, search for it in the Microsoft Update Catalog. You can import this update into Windows Server Update Services (WSUS) manually. See the Microsoft Update Catalog for instructions. Note These updates are not available from Windows Update and will not install automatically.”

You need to patch your Domain Controllers (not the Hypervisors) with the following KB’s and restart them to fix the problem:

• Windows Server 2019: KB5008602
• Windows Server 2016: KB5008601
• Windows Server 2012 R2: KB5008603
• Windows Server 2012: KB5008604
• Windows Server 2008 R2 SP1: KB5008605
• Windows Server 2008 SP2: KB5008606