habs jetzt rasugefunden. der "normale" vmkping geht nicht, man muss es so machen:
vmkping -I vmk1 -S vmotion x.x.x.x (x ist die ip des vmotion interfaces des anderen hosts)
so antwortet der ping.
muss man auch wissen, hier der link, wo das erklärt wird:
vMotion vmkping pio.nz
mache gerade ein vmotion zum test. Es geht mit der 10gb Vebrindung zwar schneller, aber nicht so schnell wie erwartet. Was mich auch wundert: Als Test habe ich die apc pcns (power chute network shutdown va) genommen. Eingeschaltet zeigt es mir eine Inkompatibilität an. Ist die vm ausgeschaltet geht es. Vcenter lässt sich eingeschaltet auch nicht migrieren (ausgeschaltet habe ich logischerweise nicht getestet, weil das geht ja nicht). Bin, was 10gb und vmotion angeht, noch relativ unbewandert.
update:
habe jetzt ein bisschen gegooglet und glaube zu verstehen, was da bei mir los ist. kann mir einer die folgenden Ausführungen bestätigen, damit ich weiss, dass ich das richtig verstehe:
Situation:
3 hosts: host1 ml310e gen8, host2 ml350 gen6, host3 ml110 gen10.
vcenter va war auf host2 (computerresourcen und lokaler datastore). live migration (vmotion) von host 2 auf host 3 (ressorcen und datastore) funktionierte.
Problem:
vcenter va live migration von host3 auf host2 oder host1 geht nicht.
(mögliche) Ursache:
vcenter läuft auf host3, der die neueste cpu hat. Die vorherige Migration von host2 (ältere cpu) auf host 3 (neuere cpu) geht, umgekehrt aber nicht. auch live migration von host3 auf host1 wäre eine migration von neuerer cpu auf ältere cpu und geht demnach nicht. Soweit ich das rausgelesen habe, tritt das Problem nur auf, wenn die vm (in dem fall vcenter) auf dem neuen host einmal neu gestartet wurde. (Das wäre bei mir der fall). Hätte sie keinen Neustart nach der Migration, dann könnte ich sie auch wieder zurück verschieben. Wenn die Theorie so stimmt, frage ich mich aber, warum ich die pcns va von host1 (ältere cpu) nicht auf host 3 (neuere cpu) live migrien kann, das müsste ja gehen. ich bekomme aber folgende Fehlermeldung:
Die virtuelle Maschine benötigt Hardwarefunktionen, die auf dem Zielhost nicht unterstützt werden oder deaktiviert sind:
"""""""""""""* Allgemeine Inkompatibilitäten
"
Verwenden Sie, falls möglich, einen Cluster mit aktivierter Enhanced vMotion Compatibility (EVC); weitere Informationen hierzu finden Sie im KB-Artikel 1003212.
CPUID-Details: Inkompatibilität auf Ebene 0x1 Register 'ecx'.
Host-Bits: 0110:0010:1101:1000:0011:0010:0000:0011
Erforderlich: x1xx:xx1x:10x1:1xx0:xx1x:xx1x:x0xx:xx11
(mögliche) Lösung:
1. Möglichkeit: VM runterfahren und cold migration machen. Geht nur nicht, wenn man vcenter selbst migrieren will, bzw ich weiss nicht, wie es gehen soll, bei allen anderen vm`s geht es natürlich.
2. Möglichkeit: vcenter va auf einen shared storage verschieben, auf den beide hosts zugreifen können. Dann vcenter runterfahren, aus dem inventory des alten hosts entfernen, dem inventory des neuen hosts zuteilen und starten.
3. Möglichkeit: dieses evc einstellen (keine Ahnung, was da zu tun ist), dass alle hosts das gleiche "cpu"-level haben. Wenn ich das richtig verstehe, würde das aber bedeuten, dass alle hosts mit der "cpu-power" des schwächsten hosts des clusters laufen, also quasi der kleinste gemeinsame Nenner. Auch nicht gerade ideal.
Habe ich das soweit richtig verstanden?
Ich würde ja Option 2 (shared storage) wählen), aber leider habe ich meien TVS-1282, auf der der shared storage per iscsi angebunden laufen sollte, wegen einem Defekt innerhalb der Widerrufsfrist zurück gesendet und warte noch darauf, dass ich mein geld wieder bekomme, um eine neue zu kaufen. Das heisst, ich müsste die vcenter runterfahren, auf den lokalen PC runterladen, und von dirt auf den neuen host wieder rauf. Is tmir zu umständlich, da es ja nur um testen/lernen geht. Da warte ich lieber, bis ich den shared storage wieder einrichten kann.
Würde mich sehr freuen,w nn ihr was zu meinen Ausführungen sagen könntet, ob ich das alles richtig verstehe,