15
VCenter 6.5 Migration nach 6.7 VSCA mit neuem Hostnamen
Hallo Admins,
ich möchte meinen vCenter 6.5 Server, der sich momentan auf einem Blech (W2012R2) befindet in eine 6.7 VSCA migrieren.
Ich habe deshalb gestern den Migrationsassistenten von vmware bemüht.
Leider musste ich feststellen, dass bei der Migration über den Assistenten, die Appliance mit dem gleichen Hostnamen und der gleichen IP erstellt wird.
Schlimmer noch, bei der Migration wurde der Windows Server auf dem der vCenter 6.5 lief aus der Domäne gekickt.
Dort läuft aber auch noch das Veritas Backup Exec und da dort der Zertifizierungsstellendienst läuft, war es ein hartes Stück arbeit den wieder in die Domäne zu bekommen.
Alle Versuche den Hostnamen der Appliance zu ändern führen dazu, dass der vCenter am danach nicht mehr lief, bzw der vSphere Web Client nicht mehr funtionierte.
Bis ich dann auf den Artikel gestoßen bin:
https://kb.vmware.com/s/article/2130599
"vCenter Server 6.x does not support changing the PNID after deployment."
Das das ein Problem sein könnte hatte ich nicht auf der Uhr und die Appliance wieder gelöscht und den vCenter 6.5 Plattform Server wieder in Betrieb genommen.
Wie ich das sehe wird mir nichts anderes übrig bleiben, als die VSCA als Neuinstallation mit dem neuen Namen und IP zu deployen.
Meine Frage ist nur, gibt es eine Möglichkeit die Host und Cluster Konfiguration vom vCenter 6.5 zu übernehmen?
Ich denke das ist auch Problematisch, da das Datenbanksystem von SQL Express auf PostgresSQL wechselt. Sonst hätte man ja vielleicht ein Backup der vCenter-Datenbank einspielen können.
Für sachdienliche Hinweise wäre ich sehr dankbar.
VG.
ich möchte meinen vCenter 6.5 Server, der sich momentan auf einem Blech (W2012R2) befindet in eine 6.7 VSCA migrieren.
Ich habe deshalb gestern den Migrationsassistenten von vmware bemüht.
Leider musste ich feststellen, dass bei der Migration über den Assistenten, die Appliance mit dem gleichen Hostnamen und der gleichen IP erstellt wird.
Schlimmer noch, bei der Migration wurde der Windows Server auf dem der vCenter 6.5 lief aus der Domäne gekickt.
Dort läuft aber auch noch das Veritas Backup Exec und da dort der Zertifizierungsstellendienst läuft, war es ein hartes Stück arbeit den wieder in die Domäne zu bekommen.
Alle Versuche den Hostnamen der Appliance zu ändern führen dazu, dass der vCenter am danach nicht mehr lief, bzw der vSphere Web Client nicht mehr funtionierte.
Bis ich dann auf den Artikel gestoßen bin:
https://kb.vmware.com/s/article/2130599
"vCenter Server 6.x does not support changing the PNID after deployment."
Das das ein Problem sein könnte hatte ich nicht auf der Uhr und die Appliance wieder gelöscht und den vCenter 6.5 Plattform Server wieder in Betrieb genommen.
Wie ich das sehe wird mir nichts anderes übrig bleiben, als die VSCA als Neuinstallation mit dem neuen Namen und IP zu deployen.
Meine Frage ist nur, gibt es eine Möglichkeit die Host und Cluster Konfiguration vom vCenter 6.5 zu übernehmen?
Ich denke das ist auch Problematisch, da das Datenbanksystem von SQL Express auf PostgresSQL wechselt. Sonst hätte man ja vielleicht ein Backup der vCenter-Datenbank einspielen können.
Für sachdienliche Hinweise wäre ich sehr dankbar.
VG.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 398970
Url: https://administrator.de/forum/vcenter-6-5-migration-nach-6-7-vsca-mit-neuem-hostnamen-398970.html
Ausgedruckt am: 27.12.2024 um 11:12 Uhr
15 Kommentare
Neuester Kommentar
Hi,
so oder so:
Wenn der VSCA einen anderen Namen bekommen soll, dann musst Du die ESX eh von einem vCenter ins andere migrieren. Und das geht nur, wenn da keine VM's aus dem alten vCenter drauf laufen. Also eh Wartungsfenster je ESX. Und da man VM's nicht im laufenden Zustand von einem vCenter ins andere migrieren kann, muss Du also auch für jede VM ein Wartungsfenster einplanen, wo die VM ausgeschaltet ist. Und da kannst Du man gleich so planen, ein neues vCenter parallel einzurichten und die ESX + VM's zwischen denen zu migrieren.
E.
so oder so:
Wenn der VSCA einen anderen Namen bekommen soll, dann musst Du die ESX eh von einem vCenter ins andere migrieren. Und das geht nur, wenn da keine VM's aus dem alten vCenter drauf laufen. Also eh Wartungsfenster je ESX. Und da man VM's nicht im laufenden Zustand von einem vCenter ins andere migrieren kann, muss Du also auch für jede VM ein Wartungsfenster einplanen, wo die VM ausgeschaltet ist. Und da kannst Du man gleich so planen, ein neues vCenter parallel einzurichten und die ESX + VM's zwischen denen zu migrieren.
E.
Hi,
das sehe ich anders. Man kann einen ESX Host mit laufenden VMs durchaus von einem vCenter Server trennen und mit einem anderen Verbinden. Dann bekommt man beim Einbinden in das neue vCenter die Liste der auf dem Host laufenden VMs angezeigt und diese werden eingebunden. Aber Achtung: Dabei gehen Zuordnungen zu Ordnern, ResourcePools oder Shares verloren. Etwas nervig kann das werden, falls du distributed Switche einsetzt. Die können nicht so einfach in ein anderes vCenter übernommen werden.
Wir haben diese Migrationsmethode bereits in einem großen Projekt erfolgreich eingesetzt. Solange das Ziel-vCenter mindestens die gleiche Version hat ist dies kein Problem
Viele Grüße
Terminatorthree
das sehe ich anders. Man kann einen ESX Host mit laufenden VMs durchaus von einem vCenter Server trennen und mit einem anderen Verbinden. Dann bekommt man beim Einbinden in das neue vCenter die Liste der auf dem Host laufenden VMs angezeigt und diese werden eingebunden. Aber Achtung: Dabei gehen Zuordnungen zu Ordnern, ResourcePools oder Shares verloren. Etwas nervig kann das werden, falls du distributed Switche einsetzt. Die können nicht so einfach in ein anderes vCenter übernommen werden.
Wir haben diese Migrationsmethode bereits in einem großen Projekt erfolgreich eingesetzt. Solange das Ziel-vCenter mindestens die gleiche Version hat ist dies kein Problem
Viele Grüße
Terminatorthree
Zitat von @Terminatorthree:
Wir haben diese Migrationsmethode bereits in einem großen Projekt erfolgreich eingesetzt. Solange das Ziel-vCenter mindestens die gleiche Version hat ist dies kein Problem
Du hast einen ESX mit laufenden VM's aus einem vCenter austreten lassen können und auch wieder in ein anderes eintreten? Das wäre mir neu.Wir haben diese Migrationsmethode bereits in einem großen Projekt erfolgreich eingesetzt. Solange das Ziel-vCenter mindestens die gleiche Version hat ist dies kein Problem
Aber selbst wenn das (inzwischen) gehen sollte: Ein vCenter macht doch nur wirklich Sinn, wenn man Cluster bildet, oder? Und spätestens beim Beitritt zu einem Cluster dürfen die VM's nicht laufen.
Hi,
ja genau das. Du kannst den Host einfach vom vCenter trennen (natürlich ohne Maintenance Mode), dann sind die VMs in diesem vCenter natürlich auch disconnected, da sie dann auf einen Standalone Host laufen.
Danach kannst du ganz normal einen Standalone Host zu einem (neuen) vCenter inklusive seiner VMs hinzufügen.
Auch Cluster stellen hier kein Problem dar. Du kannst jederzeit laufende VMs oder auch Hosts mit laufenden VMs von einem Cluster in andere schieben. Wenn man es auf die Spitze treiben will, kann man auch beide vCenter im linked Mode aufbauen (Achtung, ab hier wirds unsupported, da der Linked Mode zwischen 6.5 und 6.7 nur zu Upgradezwecken supported wird) und dann ein Cross-vCenter, Cross-Cluster Enhanced vMotion machen, bei dem du gleichzeitig noch den Storage verschiebst. Ist aber für dieses Szenario hier gar nicht nötig.
Unser Migrationsprojekt hat etwa 3000 laufende VMs auf 40 Hosts umfasst, die ohne Unterbrechung weitergelaufen sind. Wir haben von einer VCSA 5.5 auf 6.0 migriert. Wie gesagt, solange kein distributed Switch im Einsatz ist. Dann ist etwas mehr Aufwand nötig.
ja genau das. Du kannst den Host einfach vom vCenter trennen (natürlich ohne Maintenance Mode), dann sind die VMs in diesem vCenter natürlich auch disconnected, da sie dann auf einen Standalone Host laufen.
Danach kannst du ganz normal einen Standalone Host zu einem (neuen) vCenter inklusive seiner VMs hinzufügen.
Auch Cluster stellen hier kein Problem dar. Du kannst jederzeit laufende VMs oder auch Hosts mit laufenden VMs von einem Cluster in andere schieben. Wenn man es auf die Spitze treiben will, kann man auch beide vCenter im linked Mode aufbauen (Achtung, ab hier wirds unsupported, da der Linked Mode zwischen 6.5 und 6.7 nur zu Upgradezwecken supported wird) und dann ein Cross-vCenter, Cross-Cluster Enhanced vMotion machen, bei dem du gleichzeitig noch den Storage verschiebst. Ist aber für dieses Szenario hier gar nicht nötig.
Unser Migrationsprojekt hat etwa 3000 laufende VMs auf 40 Hosts umfasst, die ohne Unterbrechung weitergelaufen sind. Wir haben von einer VCSA 5.5 auf 6.0 migriert. Wie gesagt, solange kein distributed Switch im Einsatz ist. Dann ist etwas mehr Aufwand nötig.
Zitat von @Terminatorthree:
Hi,
ja genau das. Du kannst den Host einfach vom vCenter trennen (natürlich ohne Maintenance Mode), dann sind die VMs in diesem vCenter natürlich auch disconnected, da sie dann auf einen Standalone Host laufen.
Danach kannst du ganz normal einen Standalone Host zu einem (neuen) vCenter inklusive seiner VMs hinzufügen.
Auch Cluster stellen hier kein Problem dar. Du kannst jederzeit laufende VMs oder auch Hosts mit laufenden VMs von einem Cluster in andere schieben. Wenn man es auf die Spitze treiben will, kann man auch beide vCenter im linked Mode aufbauen (Achtung, ab hier wirds unsupported, da der Linked Mode zwischen 6.5 und 6.7 nur zu Upgradezwecken supported wird) und dann ein Cross-vCenter, Cross-Cluster Enhanced vMotion machen, bei dem du gleichzeitig noch den Storage verschiebst. Ist aber für dieses Szenario hier gar nicht nötig.
Unser Migrationsprojekt hat etwa 3000 laufende VMs auf 40 Hosts umfasst, die ohne Unterbrechung weitergelaufen sind. Wir haben von einer VCSA 5.5 auf 6.0 migriert. Wie gesagt, solange kein distributed Switch im Einsatz ist. Dann ist etwas mehr Aufwand nötig.
Hi,
ja genau das. Du kannst den Host einfach vom vCenter trennen (natürlich ohne Maintenance Mode), dann sind die VMs in diesem vCenter natürlich auch disconnected, da sie dann auf einen Standalone Host laufen.
Danach kannst du ganz normal einen Standalone Host zu einem (neuen) vCenter inklusive seiner VMs hinzufügen.
Auch Cluster stellen hier kein Problem dar. Du kannst jederzeit laufende VMs oder auch Hosts mit laufenden VMs von einem Cluster in andere schieben. Wenn man es auf die Spitze treiben will, kann man auch beide vCenter im linked Mode aufbauen (Achtung, ab hier wirds unsupported, da der Linked Mode zwischen 6.5 und 6.7 nur zu Upgradezwecken supported wird) und dann ein Cross-vCenter, Cross-Cluster Enhanced vMotion machen, bei dem du gleichzeitig noch den Storage verschiebst. Ist aber für dieses Szenario hier gar nicht nötig.
Unser Migrationsprojekt hat etwa 3000 laufende VMs auf 40 Hosts umfasst, die ohne Unterbrechung weitergelaufen sind. Wir haben von einer VCSA 5.5 auf 6.0 migriert. Wie gesagt, solange kein distributed Switch im Einsatz ist. Dann ist etwas mehr Aufwand nötig.
Also ich dachte auch, dass man den Host vom vCenter trennen kann, ohne die VM's zu beenden. Jedenfalls funktioniert das wenn man kein Cluster eingerichtet hat.
Den Cluster habe ich erst seit ca. einem Monat laufen, da wir die Lizenz aufgebohrt haben, deshalb bin ich mir unsicher.
Also wäre Deine Empfehlung:
1. Die 6.7 VSCA deployen
2. Den Datacenter und Cluster einrichten
3. Die Hosts aus dem vCenter 6.5 trennen und in den 6.7 hinzufügen und ins Cluster bugsieren.
???
Hi,
ja genau so würde ich es machen. Natürlich zunächst mit einem Host auf dem nur eine unwichtige VM läuft testen. Nach der Migration prüfen, je nach Lizenz, dass HA, Shares und ähnliches im neuen vCenter arbeiten wie gewünscht.
Viele Grüße
ja genau so würde ich es machen. Natürlich zunächst mit einem Host auf dem nur eine unwichtige VM läuft testen. Nach der Migration prüfen, je nach Lizenz, dass HA, Shares und ähnliches im neuen vCenter arbeiten wie gewünscht.
Viele Grüße
Mit nur einem Host HA testen?!
Haha, ich meinte nach Abschluss der gesamten Migration. Solange man im alten vcenter die settings nochmal nachschlagen kann wenn etwas nicht passt.
Der vmware-Support hat mir die Vorgehensweise jetzt bestätigt. Allerdings muss man ein paar Sachen beachten:
...
Um zurueck zu Ihrere Frage zu kommen, die beste Option fuer Sie waere ein neues vCenter mit Datencenter und Cluster zu erstellen und die Hosts anschliessend zu diesem zu bewegen.
Im grossen und ganzen werden die vSwitch Einstellungen mit den Hosts mitgenommen. Falls vDS im Einsatz sind, muessten wir diese uebertragen (https://kb.vmware.com/s/article/2034602).
Vieles allerdings muesste manuell neu eingestellt werden, wie z.b. Tags, Rollen und Berechtigungen, Zertifikate usw. Hier finden Sie einen Artikel wo das beschrieben ist: https://kb.vmware.com/s/article/2144536
...
Ist ja auch logisch.
Dann werde ich mich am WE mal dranmachen.
...
Um zurueck zu Ihrere Frage zu kommen, die beste Option fuer Sie waere ein neues vCenter mit Datencenter und Cluster zu erstellen und die Hosts anschliessend zu diesem zu bewegen.
Im grossen und ganzen werden die vSwitch Einstellungen mit den Hosts mitgenommen. Falls vDS im Einsatz sind, muessten wir diese uebertragen (https://kb.vmware.com/s/article/2034602).
Vieles allerdings muesste manuell neu eingestellt werden, wie z.b. Tags, Rollen und Berechtigungen, Zertifikate usw. Hier finden Sie einen Artikel wo das beschrieben ist: https://kb.vmware.com/s/article/2144536
...
Ist ja auch logisch.
Dann werde ich mich am WE mal dranmachen.
Zitat von @Terminatorthree:
Hi,
ja genau das. Du kannst den Host einfach vom vCenter trennen (natürlich ohne Maintenance Mode), dann sind die VMs in diesem vCenter natürlich auch disconnected, da sie dann auf einen Standalone Host laufen.
Danach kannst du ganz normal einen Standalone Host zu einem (neuen) vCenter inklusive seiner VMs hinzufügen.
Hi,
ja genau das. Du kannst den Host einfach vom vCenter trennen (natürlich ohne Maintenance Mode), dann sind die VMs in diesem vCenter natürlich auch disconnected, da sie dann auf einen Standalone Host laufen.
Danach kannst du ganz normal einen Standalone Host zu einem (neuen) vCenter inklusive seiner VMs hinzufügen.
Leider funktioniert das doch nicht. Wenn man die Hosts die im Cluster laufen vom vCenter trennen will kommt die Meldung, dass der Host erst in den Maintanance Mode versetzt werden muss. Das ist Mist, weil ich dann Downtime habe.
Ich konnte einen Host, der nicht im Cluster lief einfach so trennen und einfügen, aber bei den Cluster-Hosts klappt das nicht.
Kennt jemand einen Workarround, sonst muss ich bis zum WE warten und dann wieder Übestunden schieben.
Zitat von @Bl0ckS1z3:
Leider funktioniert das doch nicht. Wenn man die Hosts die im Cluster laufen vom vCenter trennen will kommt die Meldung, dass der Host erst in den Maintanance Mode versetzt werden muss.
Ich konnte einen Host, der nicht im Cluster lief einfach so trennen und einfügen, aber bei den Cluster-Hosts klappt das nicht.
So habe ich das auch in Erinnerung. Schrieb ich ja schon.Leider funktioniert das doch nicht. Wenn man die Hosts die im Cluster laufen vom vCenter trennen will kommt die Meldung, dass der Host erst in den Maintanance Mode versetzt werden muss.
Ich konnte einen Host, der nicht im Cluster lief einfach so trennen und einfügen, aber bei den Cluster-Hosts klappt das nicht.
Kennt jemand einen Workarround, sonst muss ich bis zum WE warten und dann wieder Übestunden schieben.
Die harte Tour. Das alte VC offline nehmen und die Host einfach so dem neuen VC beitreten lassen. Wenn es denn geht.Die Frage ist nur, ob man diese Host dann im neuen VC einem Cluster betreten lassen kann, während auf diesen VM's laufen. Das weiß ich jetzt nicht auswendig. Wenn das geht, dann aber in jedem Fall nur dann, wenn der neue Cluster die selben EVC-Einstellungen hat, wie der Host sie im alten Cluster hatte.
Hi,
Da mich das gerade auch etwas gewundert hat, habe ich nochmal mit dem Kollegen gesprochen, der bei uns die Migration durchgeführt hat.
Es gibt folgende 2 Optionen
a) einfach den Host im Ziel-vCenter verbinden ohne ihn vorher zu trennen. Dann gibt es eine Meldung, der Host wäre bereits in einem anderen vCenter und man kann ihn trotzdem zwingen (diese Variante haben wir gemacht)
b) die VMs aus dem Cluster raus auf den Host außerhalb des Clusters schieben, diesen trennen, im anderen vCenter verbinden, VMs dort wieder in einen Cluster schieben, Host wieder zurück zum alten vCenter, neue Ladung VMs drauf usw...
Viele Grüße
Da mich das gerade auch etwas gewundert hat, habe ich nochmal mit dem Kollegen gesprochen, der bei uns die Migration durchgeführt hat.
Es gibt folgende 2 Optionen
a) einfach den Host im Ziel-vCenter verbinden ohne ihn vorher zu trennen. Dann gibt es eine Meldung, der Host wäre bereits in einem anderen vCenter und man kann ihn trotzdem zwingen (diese Variante haben wir gemacht)
b) die VMs aus dem Cluster raus auf den Host außerhalb des Clusters schieben, diesen trennen, im anderen vCenter verbinden, VMs dort wieder in einen Cluster schieben, Host wieder zurück zum alten vCenter, neue Ladung VMs drauf usw...
Viele Grüße
Ok, danke Therminatorthree ich werde die Variante A heute abend testen.
Die Variante B ist für mich zu aufwendig, da der Host außerhalb des Clusters nicht mit dem Storage verbunden ist.
VG
Die Variante B ist für mich zu aufwendig, da der Host außerhalb des Clusters nicht mit dem Storage verbunden ist.
VG
Hallo emeriks,
die Clustereinstellungen sind identisch, auch der EVC-Mode.
Danke heute abend gibt es die harte Tour.
VG.
die Clustereinstellungen sind identisch, auch der EVC-Mode.
Danke heute abend gibt es die harte Tour.
VG.
Hallo Admins,
wollte noch mal eine Rückmeldung zum aktuellen Geschehen geben.
Die harte Tour hat super und schnell funktioniert. Alle VM's wurden so im laufenden Betrieb auf das neue vCenter migriert.
Man muss nur aufpassen, dass man bei der Übernahme nicht die Lizenz aus dem alten vCenter herauszieht und dem Host bei der Übernahme erst einmal die 60 Tage Testlizenz zuweist.
Da hatte ich beim letzten mal das Problem, dass dem noch nicht migrierten Host im alten vCenter irgendwie die Lizenz entzogen wurde und der dann auch im alten vCenter getrennt wurde.
Wenn alle Hosts übernommen sind, kann man dann seine gekaufte Lizenz in das neue vCenter einspielen und den entsprechenden Items zuweisen.
Da weiss man was man hat, Guten Abend
wollte noch mal eine Rückmeldung zum aktuellen Geschehen geben.
Die harte Tour hat super und schnell funktioniert. Alle VM's wurden so im laufenden Betrieb auf das neue vCenter migriert.
Man muss nur aufpassen, dass man bei der Übernahme nicht die Lizenz aus dem alten vCenter herauszieht und dem Host bei der Übernahme erst einmal die 60 Tage Testlizenz zuweist.
Da hatte ich beim letzten mal das Problem, dass dem noch nicht migrierten Host im alten vCenter irgendwie die Lizenz entzogen wurde und der dann auch im alten vCenter getrennt wurde.
Wenn alle Hosts übernommen sind, kann man dann seine gekaufte Lizenz in das neue vCenter einspielen und den entsprechenden Items zuweisen.
Da weiss man was man hat, Guten Abend
