Umzug mit iSCSI-Storage von 6.0 auf 6.7

[ArndN]

Hallo zusammen,

wir legen zwei Standorte zusammen. Der alte Standort hat vSphere 6.0, der neue 6.7. Ich möchte gerne die VMs vom alten Standort samt dem iSCSI-Storage zum neuen Standort umziehen. Dort ist bereits ein Cluster eingerichtet und Storage etc. angebunden. Da ich nur ein WE Zeit habe, würde ich gerne einfach das iSCSI-Storage vom alten Standort am neuen Standort anschließen und nicht den Umweg über Datensicherungen etc. gehen.

Wir würdet ihr vorgehen. Was mir nicht klar ist: wie funktioniert die Zuordnung der virtuellen HDs in der Maschine, wenn ich das Storage an einem neuen Cluster anschließe? Wir haben die HDs teilweise über mehrere LUNS verteilt. Geht dasErkennen über die ID automatisch? Also einfach Storage am neuen Standort einbinden, mounten und VM auf dem neuen vSphereCenter-Server neu registrieren?

Ich kenne das Szenario nur innerhalb eines vSphereCenterServers, nicht aber die Migration auf eine komplett neue Umgebung. Der Umweg über die DASI (Veeam) dauert mir einfach zu lagen, die Maschinen sind recht umfangreich.

Gefahren? Andere Ideen? Danke für jeden Tip oder Hinweis!

[irix]

Moin,
altes Storage und zumind. einen ESXi, welcher vor dem Shutdown ALLE VMs auf sich vereint hat zum anderen Standort schaffen und dem vorhandenen vCenter beitreten lassen. Host aufnehmen und einzeln bzw. in einem Einzelcluster betreiben. Mit dem vCenter dann die VMs migrieren

Voraussetzungen
- vCenter must noch Platz haben fuer einen Host (Lizenztechnisch)
- vCenter darf max. 6.7 und noch nicht 7.0 sein

Wenn das nicht geht und du nur das Storage migrierst dann....
- Wenn das unterschiedliche iSCSI Arten sind (Binding oder Non-Binding) dann bekommst du die schwer bis gar nicht zusammen an einen der neuen Hosts
- Wenn es nicht autom. gemountet wird kann man mit "esxcfg-volume -l nachgucken
- Du kannt eine neue Signatur/GUID beim Mounten des Datastores erzeugen lassen was auch zwingend waere wenn die GUID schon besteht. Ich weis das er auf jeden Fall in das Filesystem reinguckt und nicht nur die aeusere Art und Weise der Praesentation wie Controller:Tartet:LUN als Referenz benutzt
- Wenn eine neue GUID erzeugt wird dann hat das keine Auswirkungen auf VMs welche alle vDisks in einem gemeinsamen Ordner haben. ABER wir du geschrieben hast sind bei einigen VMs die vDisks auf mehrere Datastores verteilt. Da ueber einen absoluten Pfad basierend auf der GUID referenziert wird verlierst du hier die vDisks der VMs und diese starten dann nicht. Evtl. kannst du das auf dem alten Storage erstmal noch wieder korrigeren
- Siehe zu das du vorher ALLE Snapshots loescht
- Ziehe vorher mit RVtools mal einen Report

Gruss
Joerg

[ArndN]

Hallo Jörg,

vielen Dank für die Antwort.
Die Idee ist gut. Ich migriere vor dem Umzug alle VMs auf eine Maschine und nehme diese temporär mit.
Hört sich erstmal gut an. Ich habe zwar lizenztechnisch das Problem, dass ich nur eine Essentials Plus habe,
aber für den kurzen Moment der Migration kann ich einen der neuen Hosts rausnehmen. Dann ziehe ich alle Maschinen auf die neuen Hosts um und verteile die später neu.

Frage: aus deiner Sicht ist es kein Problem, in ein VCSA67 einen 6.5 Host aufzunehmen? Ich könnte das alternativ auch über Veeam B&R10 machen. Hier würde ich auch einen einzelnen Host einbinden können und die VMS von dort migrieren. Ist nur eine Frage der Performance letztlich.

Auf jeden Fall vielen Dank für den Input, das eröffnet für den Umzug neue Perspektiven. Dennoch merkwürdig, dass Vmware dieses Szenario nicht vernünftig abdeckt. Wir sind ja nicht die Ersten. die in ein neues RZ umziehen und die VMs einfach mitnehmen wollen.

Nice day!

[irix]

Moin,

"Rule of Thumb" ist das ein vCenter immer bis zu 2 Versionen abwaertskompatibel ist was die Verwaltung von ESXi Hosts angeht. Sprich ein VCSA 7.0 kann auch ESXi 7.0, 6.7 und 6.5 verwalten. Das ganze ist kein Problem und wir haben das schon seit Jahren so am laufen weil
1. Nicht alle Hosts so gleichzeitig aktualisiert werden
2. Nicht alle Hosts (gleich) zertifiziert sind bzw. auf dem Papier nicht mehr kompatibel sind

- Wer frisch beginnt hat immer 60 Tage Eval
- Wer ein Major Release Upgrade macht dort wird die Lizenz zurueck gesetzt auf Eval

Du koenntest auch einen deiner alten Hosts schnell neuinstallieren um 60 Tage Eval zu haben und das ist dann auch der Migrationshost. Somit wuerde man auch ein svMotion machen koennen und hat zumind. keine lange Downtime was das migrieren der VMs vom alten auf das neue Storage angeht, wenn dieser Host dann in dem neuen vCenter/Cluster ist. Hier dann aber kurz wegen EVC nachdenken.

Es ist nicht VMware ihr Problem wenn du keine vernuenftige Leitung zwischen den RZ hast

Gruss
Joerg

[ArndN]

Ja, mit einer sehr breitbandigen Verbindung von RZ zu RZ wäre manches einfacher. Mehr als 100 Mbit synchron haben wir aber leider nicht und darüber zu replizieren oder zu migrieren ist mir zu gefährlich.

Bis auf zwei Maschinen (ca. 2 TB) sind die VMs auf nicht zu groß, Downtime ist bis auf den Exchange auch nicht das Problem am Umzugs-WE. Insofern kann ich die herkömmlich offline migrieren, dafür reicht das WE aus.

Danke!