Sporadische Fehler bei Livemigration

[Goldielocks 0]

Hallo,

 

zunächst einmal zum Setup.

Wir haben hier zwei physikalische Server, die als Hyper-V Hosts dienen, auf einem läuft Windows Server 2012 R2 (ich werde ihn den "2012er" nennen), auf dem anderen läuft Windows Server 2016 (der "2016er").

 

Beide Server gehören zur selben Domäne und sind Teil eines Clusters (erstellt auf dem 2012er), ein externes Volume ist per iSCSI als Cluster Shared Volume eingebunden. Auf diesem CSV liegen die VMs und VHDs.

 

Nun möchte ich eine Livemigration zwischen beiden VM-Hosts einrichten. Als Authentifizierung wird CredSSL verwendet, nicht Kerberos. Es ist eingestellt, dass eine Migration zwischen Geräten mit unterschiedlichen Prozessortypen möglich ist.

 

Folgendes Problem:

Migriere ich vom 2016er auf den 2012er funktioniert das wunderbar - innerhalb von unter 1 Minute ist die Migration erfolgreich abgeschlossen.

Migriere ich jedoch vom 2012er auf den 2016er, dauert es erst mal 5 Minuten, bis er mich nach dem Virtual Switch frägt. Dann vergehen nochmal etwa 10 Minuten und die Migration ist entweder abgeschlossen (ca. 20% der Fälle), oder sie bricht mit einer von zwei Fehlermeldungen ab.

 

Die Test-VM ist nicht im Cluster oder der Domäne, die Fehler treten auf, egal ob sie läuft oder nicht. Sie wurde auf dem 2012er erstellt und hat die Konfigurationsversion 5.0.

 

Diese Fehlermeldungen lauten:

 

-----

Fehler beim Migrationsvorgang für den virtuellen Computer am Migrationsziel.

 

Fehler beim Suchen des angegebenen virtuellen Computers am Migrationsziel.

 

Der Gespeicherte Zustand des virtuellen Computers an Quelle und Ziel ist nicht konsistent.

 

Fehler beim Migrationsvorgang für den virtuellen Computer "Test-VM" am Migrationsziel "2016er". (ID des virtuellen Computers: <ID Test-VM>)

 

Test-VM. Fehler beim Suchen der angegebenen ID (<ID Test-VM>) für den geplanten virtuellen Computer mit gültigem Zustand am Migrationsziel:ADie Gruppe oder Ressource haben für diesen Zustand nicht den richtigen Zustand. (0x8007139F). (ID des virtuellen Computers: <ID Test-VM>)

 

Fehler beim Migrieren des virtuellen Computers "Test-VM", da der gespeicherte Zustand von Quelle und Ziel nicht konsistent ist. (ID des virtuellen Computers: <ID Test-VM>)

-----

 

Der zweite Fehler (der häufiger auftritt) lautet:

-----

Fehler beim Migrationsvorgang für den virtuellen Computer an der Migrationsquelle.

 

Fehler beim Herstellen einer Verbindung mit dem Host "2016er": Element nicht gefunden. (0x8007490).

 

Fehler beim Herstellen einer Verbindung, da die Anforderung vom Zielhost abgelehnt wurde: Element nicht gefunden. (0x80070490).

 

Fehler beim Migrationsvorgang für den virtuellen Computer "Test-VM" an der Migrationsquelle "2012er". (ID des virtuellen Computers: <ID Test-VM>)

 

Fehler des Verwaltungsdiensts für virtuelle Computer beim Herstellen einer Verbindung für die Migration eines virtuellen Computers mit dem Host "HIVE": Element nicht gefunden. (0x80070490).

 

Vom Verwaltungsdienst für virtuelle Computer konnte keine Verbindung für die Migration des virtuellen Computers hergestellt werden, da die Anforderung vom Zielhost abgelehnt wurde: Element nicht gefunden. (0x80070490).

-----

 

Hat jemand eine Ahnung, was los ist?

[NilsK 2.934]

Moin,

 

ich würde nicht ausschließen, dass es sich hier um einen Bug in Windows Server 2016 handelt. Leider sehen wir derzeit eine ganze Menge davon.

 

Möglich wären aber auch andere Probleme. Wie sind denn die Netzwerkanbindungen der beiden Systeme? Ist da Teaming im Spiel? Verschiedene Netzwerksegmente? ... usw.

 

Gruß, Nils

[Goldielocks 0]

Moin,

 

ich würde nicht ausschließen, dass es sich hier um einen Bug in Windows Server 2016 handelt. Leider sehen wir derzeit eine ganze Menge davon.

 

Möglich wären aber auch andere Probleme. Wie sind denn die Netzwerkanbindungen der beiden Systeme? Ist da Teaming im Spiel? Verschiedene Netzwerksegmente? ... usw.

 

Gruß, Nils

 

Hm... wäre es ein Bug würde das heißen, ich müsste den 2016er neu aufsetzen, als 2012. Wäre natürlich ärgerlich.

 

Der 2016er ist direkt per Ethernetkabel mit der Eternus verbunden - der dafür verwendete Port hat ein eigenes Netz. Verwaltet wird er ganz normal über das Büronetz. Der 2012er ist über das normale Büronetz verbunden, da er in einem anderen Raum steht. Das würde evtl die unterschiedliche Dauer erklären, andererseits handelt es sich in beiden Fällen um Gigabit-Ethernetverbindungen und das Netzwerk ist mit 3 Servern, 3 PCs und 2 VMs jetzt nicht so ausgelastet.

 

Ich kann jetzt sagen, dass die Migration vom 2012er auf den 2016er in ca. 10% der Versuche funktioniert. Ansonsten tritt aktuell primär der "Element nicht gefunden"-Fehler auf. Der "ungültige Zustand"-Fehler ist seit heute Vormittag nicht mehr aufgetreten.

bearbeitet 18. Januar 2017 von Goldielocks

[NilsK 2.934]

Moin,

 

hm ... "Büronetz", "direkt mit der Eternus verbunden", "Gigabit" ... klingt für mich jetzt nicht nach einem Best-Practice-Design. Ich sage nicht, dass du da was falsch eingerichtet hast (dafür fehlen die Details), aber aus Erfahrung weiß ich, dass bei solchen Ad-hoc-Setups oft Konfigurationsfehler vorliegen, durch die z.B. Netzwerkpakete nicht den richtigen Weg nehmen. Zumindest solltest du da also noch mal prüfen, ob alles korrekt eingerichtet ist.

 

Gruß, Nils

[Goldielocks 0]

Moin,

 

hm ... "Büronetz", "direkt mit der Eternus verbunden", "Gigabit" ... klingt für mich jetzt nicht nach einem Best-Practice-Design. Ich sage nicht, dass du da was falsch eingerichtet hast (dafür fehlen die Details), aber aus Erfahrung weiß ich, dass bei solchen Ad-hoc-Setups oft Konfigurationsfehler vorliegen, durch die z.B. Netzwerkpakete nicht den richtigen Weg nehmen. Zumindest solltest du da also noch mal prüfen, ob alles korrekt eingerichtet ist.

 

Gruß, Nils

 

Hm, eigentlich wird empfohlen, die Server über separate Ports direkt mit der Eternus zu verbinden. Das ist momentan mit dem 2012er nur nicht möglich, da er eben woanders steht und es tatsächlich nicht möglich ist, in 20 Kilometern Umkreis ein Ethernetkabel mit vernünftiger Länge zu bekommen.

Ich dachte eigentlich, fehlgeleitete Pakete und Kollisionen gäbe es seit den Switches nicht mehr.

Das heißt, ich werde mal schauen müssen, dass ich irgendwie Kabel organisiere und das dann nochmal neu aufbauen.

[Nobbyaushb 1.471]

Ansonsten schau mal bei Deutschen Hyper-V-Guru Carsten & Co vorbei:

https://www.hyper-v-server.de/hypervisor/

 

Da findest du auch Best-Practice etc.

 

Geht viel schneller als alles zu tippen...

 

Außerdem wie meinst du das mit den 20km? Stehen die un anderen Standorten?

 

;)

[Goldielocks 0]

Ansonsten schau mal bei Deutschen Hyper-V-Guru Carsten & Co vorbei:

https://www.hyper-v-server.de/hypervisor/

 

Da findest du auch Best-Practice etc.

 

Geht viel schneller als alles zu tippen...

 

Außerdem wie meinst du das mit den 20km? Stehen die un anderen Standorten?

 

;)

 

Danke, ich werds mir morgen mal anschauen. Und nein, die stehen nur in anderen Räumen. Aber es gibt in der ganzen Umgebung kein Geschäft wo man Ethernet-Kabel kaufen könnte.

[Doso 77]

Wenn du kannst, installiere den 2016er als 2012R2 neu. Windows Server 2016 hat leider noch viele Kindekrankheiten.

[Nobbyaushb 1.471]

Wenn du kannst, installiere den 2016er als 2012R2 neu. Windows Server 2016 hat leider noch viele Kindekrankheiten.

Das Problem ist ein anderes, und bei mir läuft das einwandfrei, der Patch vom Dezember muss halt drauf.

 

Wenn ich den OP richtig lese, sind beide Member von einem Cluster.

 

Den Produktivbetrieb sollte man nicht mischen, Best-Practice bei einem 2-Node ist anders.

 

:)

[NilsK 2.934]

Moin,

 

Ich dachte eigentlich, fehlgeleitete Pakete und Kollisionen gäbe es seit den Switches nicht mehr.

 

das hat mit Switches wenig zu tun. Eine Fehlkonfiguration kann kein Switch dieser Welt korrigieren.

 

Gruß, Nils

[Goldielocks 0]

Das Problem ist ein anderes, und bei mir läuft das einwandfrei, der Patch vom Dezember muss halt drauf.

 

Wenn ich den OP richtig lese, sind beide Member von einem Cluster.

 

Den Produktivbetrieb sollte man nicht mischen, Best-Practice bei einem 2-Node ist anders.

 

:)

 

Naja, das ist ja (zum Glück) noch nicht produktiv. Wir testen das aktuell aus, ob wir das später verwenden können.

 

Nachtrag:

Ich habe gerade gelesen, dass man die Livemigration auch via Failover-Cluster-Manager ausführen kann. Dafür muss man die VM dem Cluster als Rolle hinzufügen. Das scheint um einiges zuverlässiger zu sein. Solange die virtual Switches auf beiden VM-Hosts gleich heißen, wird das offenbar anstandslos ausgeführt.

Ich werde noch prüfen, ob das mit einer optimaleren Verkabelung auch vom Hyper-V-Manager aus besser funktioniert und das dann auch hier noch reinschreiben.

bearbeitet 19. Januar 2017 von Goldielocks

[NorbertFe 2.034]

Ich habe gerade gelesen, dass man die Livemigration auch via Failover-Cluster-Manager ausführen kann.

Wie hast du das denn bisher erledigt? 8)

[NilsK 2.934]

Moin,

 

Dafür muss man die VM dem Cluster als Rolle hinzufügen. Das scheint um einiges zuverlässiger zu sein. Solange die virtual Switches auf beiden VM-Hosts gleich heißen, wird das offenbar anstandslos ausgeführt.

Ich werde noch prüfen, ob das mit einer optimaleren Verkabelung auch vom Hyper-V-Manager aus besser funktioniert und das dann auch hier noch reinschreiben.

 

das musst du sowieso tun, sonst gibt es ja keine HA für die VM. Den Cluster könntest du dir dann schenken.

 

[Hyper-V: Sind meine VMs wirklich geclustert? | faq-o-matic.net]
http://www.faq-o-matic.net/2015/05/04/hyper-v-sind-meine-vms-wirklich-geclustert/

 

Gruß, Nils