vmotion verwendet eine falsche destination IP -> ABBRUCH!

[blue_focus]

Hallo Leute,

ich habe heute wieder mal ein sehr exquisites Problem.
Ich schaffe es beim besten Willen nicht VMs via vMotion auf einen anderen Host zu migrieren. Der Vorgang bricht immer mit der Meldung "Operation is not allow in the current state...Check your vmotion network settings..."
In den Einstellungen kann ich aber kein Problem feststellen.

Wir haben Management und vmotion Traffic von einander getrennt. Vmotion läuft ausschließlich in einem nicht geroutetdem VLAN. Jeder Host hat somit eine IP im Management-Netz und eine im vMotion Netz.

Soweit ich es eingrenzen konnte versuchen meine beiden betroffenen Hosts eine vMotion-Session über deren vMotion-vmk auf die Management-IP des Destinationhosts aufzubauen. Ist natürlich totaler Schwachsinn da dies routing-/firewalltechnisch schon mal gar nicht möglich ist.

Habe dazu folgendes in meiner vmkernel.log gefunden:

Code: Alles auswählen

Migrate: vm 2658371: 3234: Setting VMOTION info: Source ts = 1366026273258248, src ip = <172.19.19.237> dest ip = <10.39.32.32> Dest wid = 8160368 using SHARED swap


172.x.x.x = vMotion VLAN
10.x.x.x = Management VLAN

Ich verstehe nicht woher der ESXi diesen Blödsinn an Information her nimmt und wie ich ihm das ohne Reboot wieder ausreden kann. Kommt das vom vCenter, dem HA-Agent oder wo ist das statisch hinterlegt?

HA-Agent und alle Management-Agents habe ich bereits neugestartet -> bringt nix.
Alle vMotioneinstellungen habe ich auch schon mehrfach im kompletten Cluster entfernt und neu eingerichtet. Ich behaupte mal das ist fehlerfrei.

Ich bringe diesen Fehler nur mit folgender Aktion meinerseits in Zusammenhang.
Ich habe im Zuge der Migration von 5.0 U1 auf 5.1 diese beiden Hosts mit noch 5.0 U1Installation im laufenden Betrieb vom alten 5.0er vCenter in das neue 5.1er umgehangen. Dabei fiel mir auf, dass wieder mal der Profilbug zu geschlagen hatte, dass vmk0 vmotion und vmk1 Management zugewiesen war. Das sollte umgekehrt sein, daher habe ich das entsprechend richtig gestellt.
Jetzt scheint mir da aber irgendwie so ein Konfig-Mischmasch zustande gekommen zu sein.

Hat hier jemand ne Idee wie ich nun meine laufenden und hoch produktiven VMs von den beiden Hosts bekomme ohne dabei die VMs runterfahren zu müssen??!

SG
Manuel

[weigeltchen]

vMotion ist auf dem Managementnetwork deaktiviert? Mgl. vergessen worden beim vertauschen der vmk.

[MarcelMertens]

Denke ich auch. vMotion auf dem MGMT Interface aktiviert

[blue_focus]

Schön wäre es. Das war auch mein erster Gedanke. Nach x-maliger Kontrolle kann ich hier aber keinen Fehler feststellen.

Hier ein Auszug all meiner vmotion IPs

Code: Alles auswählen

PS C:\> get-vmhost | % {(get-view $_.id).config.vmotion.ipconfig} | select ipaddress, subnetmask

IpAddress                                                       SubnetMask
---------                                                       ----------
172.19.19.210                                                   255.255.255.192
172.19.19.211                                                   255.255.255.192
172.19.19.212                                                   255.255.255.192
172.19.19.213                                                   255.255.255.192
172.19.19.224                                                   255.255.255.192
172.19.19.220                                                   255.255.255.192
172.19.19.221                                                   255.255.255.192
172.19.19.223                                                   255.255.255.192
172.19.19.222                                                   255.255.255.192
172.19.19.225                                                   255.255.255.192
172.19.19.233                                                   255.255.255.192
172.19.19.234                                                   255.255.255.192
172.19.19.231                                                   255.255.255.192
172.19.19.232                                                   255.255.255.192
172.19.19.241                                                   255.255.255.192
172.19.19.242                                                   255.255.255.192
172.19.19.243                                                   255.255.255.192
172.19.19.207                                                   255.255.255.192
172.19.19.205                                                   255.255.255.192
172.19.19.206                                                   255.255.255.192
172.19.19.198                                                   255.255.255.192
172.19.19.208                                                   255.255.255.192
172.19.19.249                                                   255.255.255.192
172.19.19.250                                                   255.255.255.192


Ich verstehe einfach nicht wie der dann auf die Idee kommt, Daten über mein Management-Netz zu schippern. Und was ich noch viel weniger verstehe -> eine VM habe ich gefunden die kann ich kreuz und quer migrieren wie ich will. Kein Problem. Bei allen anderen VMs bei denen ich es probiert habe gehts aber genau aus besagtem Problem nicht

[weigeltchen]

Dein Management Network auf allen Hosts sollte so aussehen.





Kannst Du auf der Console alle Host über die vMotion-IP pingen?

[blue_focus]

Jo... genau so schaut es auch aus.

Allerdings hab ich jetzt einen Workaround rausgefunden.
Das Lustige ist ja, manche VMs lassen sich verschieben, andere wieder nicht - wegen genau des beschriebenen Verhaltens.

Der Trick ist nun bei den betroffenen VMs zuerst eine svmotion auf einen anderen DS zu machen (nein es besteht kein Zusammenhang mit dem DS ob vmotion geht oder nicht. Die nicht funktionierenden VMs sind quer durch auf den verschiedensten DS verteilt).

Nach einer svmotion funkt auch die normale vmotion wieder. Warum weiß der Teufel. Das muss wohl irgendeine Art Configcaching im vmotion-Mechanismus sein welcher durch die svmotion resettet wird.

Konnte dazu im Netz keine stichhaltige Erklärung für das Verhalten finden.