docs: add hyper-v migration findings and solutions
This commit is contained in:
parent
036321bd98
commit
ab811f9495
26
infrastructure/hyperv_migration_2026.md
Normal file
26
infrastructure/hyperv_migration_2026.md
Normal file
|
|
@ -0,0 +1,26 @@
|
||||||
|
# Hyper-V Cluster Migration & Setup Erkenntnisse (Juli 2026)
|
||||||
|
|
||||||
|
## 1. Das Double-Hop / Kerberos Problem bei Hyper-V Migrationen
|
||||||
|
Wenn per WinRM (`Invoke-Command`) ein Skript auf einem Hyper-V Host ausgeführt wird, das eine VM auf einen *anderen* Host verschieben soll (`Move-VM`), schlägt dies standardmäßig fehl ("Double-Hop").
|
||||||
|
**Lösung:** Die Migration per `schtasks` als lokaler Task im Hintergrund ausführen lassen. Dadurch wird eine interaktive Logon-Session simuliert, die den Zugriff auf das Netzwerk (Kerberos) erlaubt. Wichtig: Die Aufgabe muss unter einem Domain-Admin-Konto (`CONSORO\Administrator`) mit Passwort-Übergabe erstellt werden.
|
||||||
|
|
||||||
|
## 2. AD Trust und DNS Einstellungen für Hyper-V Hosts
|
||||||
|
Damit ein Hyper-V Host sich mit der Active Directory authentifizieren kann (und Kerberos Delegation zulässt), **muss** als primärer DNS-Server ein lokaler Domain Controller eingetragen sein.
|
||||||
|
**Fehlerbild:** Wenn z.B. Google-DNS (`8.8.8.8`) auf dem vEthernet-Adapter des Hosts konfiguriert ist, verliert der Host seine "Secure Channel" Trust-Verbindung zur AD. Commands wie `Move-VM` scheitern dann mit "Ihre Domäne ist nicht verfügbar", und `nltest /sc_verify:consoro.de` liefert `ERROR_NO_LOGON_SERVERS`.
|
||||||
|
**Fix:** Immer die IPs der internen Domain Controller (`192.172.0.10` für dc1, `192.172.0.20` für dc2) in die vEthernet (intern) Konfiguration des Hosts übernehmen.
|
||||||
|
|
||||||
|
## 3. FQDN bei Move-VM
|
||||||
|
Bei `Move-VM` darf nicht nur der Hostname (`consoro-hyperv4`) verwendet werden, wenn Kerberos-Authentifizierung aktiv ist. Es muss der FQDN (`hyperv4.consoro.de`) genutzt werden, damit der SPN für WinRM und Kerberos erfolgreich gematched werden kann.
|
||||||
|
|
||||||
|
## 4. Live Migration zwischen AMD und Intel
|
||||||
|
Live Migrationen (Memory-State Übertragung im laufenden Betrieb) zwischen Hosts mit AMD-Prozessoren (z.B. `HyperV2`) und Intel-Prozessoren (z.B. `HyperV4`) werden von Hyper-V hart blockiert:
|
||||||
|
`"Ein virtueller Computer, der ausgeführt wird oder gespeichert ist, kann nicht zu einem physikalischen Computer migriert werden, der einen Prozessor eines anderen Herstellers besitzt."`
|
||||||
|
**Workaround:** Die VM muss **ausgeschaltet** (`Off`) sein, bevor sie verschoben werden kann.
|
||||||
|
|
||||||
|
## 5. Veeam Setup & Replikation
|
||||||
|
- Bei Host-Leerungen (`HyperV2`) müssen betroffene Hosts aus den Veeam-Jobs ausgeschlossen werden.
|
||||||
|
- Eine Replikation des Veeam-Management-Servers (`Veeam.consoro.de` auf `HyperV1`) sollte auf einem separaten Host (`HyperV4`) eingerichtet werden, um im Fall eines Ausfalls von `HyperV1` Zugriff auf Backups zu behalten.
|
||||||
|
|
||||||
|
## 6. OPNsense Routing & DHCP
|
||||||
|
(Ergänzend zu vorherigen Tasks)
|
||||||
|
- Interne IP-Zuordnungen, Mac-Adressen und Tunnels werden standardmäßig über den Mailcow-Server oder das Consoro-Network geregelt und müssen in Firewall-NAT und DHCP-Reservations festgehalten werden.
|
||||||
Loading…
Reference in a new issue