ESX 5.5 große virtuelle Disk verschieben ohne online Migration?
Hallo Admins,
ich muss wegen Speicherproblemem eine ca. 6TB große virtuelle Disk auf einen andern Store verschieben. Ich habe leider und die Essentials-Version, also ohne Online-Migration.
Ich müsste also die virtuelle Maschine herunterfahren, um die Migration durchführen zu können.
Das Problem ist, dass die virtuelle Maschine aber auch unser Domänen-Controller, DNS- und DHCP-Server ist und der Migrationsvorgang sicherlich eine ganze Zeit benötigen wird.
Meine Idee ist es nun die Disk (Laufwerk F auf dem Server) irgendwie offline zu schalten und temporär an eine andere virtuelle Maschine anzuhängen.
Dann die Migration durchzuführen und das Ganze dann wieder zurückzudrehen. Oder vielleicht auch gleich den Speicher über den anderen Server zur Verfügung zu stellen.
Ich habe das aber noch nie so gemacht und fürchte, dass ich einen Fehler mache und alle Daten verliere.
Natürlich habe ich eine Datensicherung, aber selbst das Wiederherstellen der Daten dürfte ein ganzes We dauern - wenn nicht sogar noch länger.
Deshalb möchte ich mir von Euch ein paar Tipps holen, vielleicht hat ja jemand von Euch so was schon mal durchgeführt.
Vielen Dank!
PS: Das ich während der Migration nicht auf die Daten zugreifen kann ist mir natürlich bewußt. Deshalb habe ich mir das Pfingstwochenende vorgenommen.
ich muss wegen Speicherproblemem eine ca. 6TB große virtuelle Disk auf einen andern Store verschieben. Ich habe leider und die Essentials-Version, also ohne Online-Migration.
Ich müsste also die virtuelle Maschine herunterfahren, um die Migration durchführen zu können.
Das Problem ist, dass die virtuelle Maschine aber auch unser Domänen-Controller, DNS- und DHCP-Server ist und der Migrationsvorgang sicherlich eine ganze Zeit benötigen wird.
Meine Idee ist es nun die Disk (Laufwerk F auf dem Server) irgendwie offline zu schalten und temporär an eine andere virtuelle Maschine anzuhängen.
Dann die Migration durchzuführen und das Ganze dann wieder zurückzudrehen. Oder vielleicht auch gleich den Speicher über den anderen Server zur Verfügung zu stellen.
Ich habe das aber noch nie so gemacht und fürchte, dass ich einen Fehler mache und alle Daten verliere.
Natürlich habe ich eine Datensicherung, aber selbst das Wiederherstellen der Daten dürfte ein ganzes We dauern - wenn nicht sogar noch länger.
Deshalb möchte ich mir von Euch ein paar Tipps holen, vielleicht hat ja jemand von Euch so was schon mal durchgeführt.
Vielen Dank!
PS: Das ich während der Migration nicht auf die Daten zugreifen kann ist mir natürlich bewußt. Deshalb habe ich mir das Pfingstwochenende vorgenommen.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 373236
Url: https://administrator.de/contentid/373236
Ausgedruckt am: 24.11.2024 um 19:11 Uhr
10 Kommentare
Neuester Kommentar
Moin,
Du hast doch sicher einen zweiten DC, der in der Downtime die Aufgaben größtenteils übernehmen könnte?
Dann kannst Du das Verschieben ohne Kniffe durchführen.
Wie stellst Du Dir das vor? Du kannst doch nicht einfach einen Server an eine andere VM anhängen?
Gruss
Du hast doch sicher einen zweiten DC, der in der Downtime die Aufgaben größtenteils übernehmen könnte?
Dann kannst Du das Verschieben ohne Kniffe durchführen.
Meine Idee ist es nun die Disk (Laufwerk F auf dem Server) irgendwie offline zu schalten und temporär an eine andere virtuelle Maschine anzuhängen.
Wie stellst Du Dir das vor? Du kannst doch nicht einfach einen Server an eine andere VM anhängen?
Gruss
Zitat von @Bl0ckS1z3:
Also mir wäre wohler, wenn meine erste Idee umsetzbar wäre.
Der Datenspeicher kann ruhig mal 2 - 3 Tage fehlen. Der ganze Server ist eher schwierig.
Also mir wäre wohler, wenn meine erste Idee umsetzbar wäre.
Der Datenspeicher kann ruhig mal 2 - 3 Tage fehlen. Der ganze Server ist eher schwierig.
Einfach suf einer Testmaschine vorher ausprobiere.
Und Backup nicht vergessen.
lks
PS: Ich würde einfach auf dem neuen Store eine Virtuelle HDD erstellen, die in die VM einbinden und innerhalb der VM die Daten verschieben.
Danach kann man die "alte" Platte freigeben und entfernen.
Das könnte man z.B. einem Software-Raid1 innerhalb der VM sogar im laufenden Betrieb machen.
Also ganz platt gesagt:
Wenn der Chef keine Downtime haben will, muss er das Geld für EssentialsPlus oder Standard in die Hand nehmen. Dann ist das kein Problem.
Evtl. kannst du ja eine kurzzeitige Trialzeit dafür noch aktivieren?
Wäre das jetzt kein DC, würde ich sagen du machst ein Backup der Maschine und stellst das per Instant Recovery auf dem neuen Store wieder her. Alte VM stoppen und neue hochfahren. Warten bis Recovery durch ist und alte VM entfernen.
Aber: Du hast den üblen Fehler begangen einen DC auch noch mit anderen Diensten zu belegen. Das ist ein NoGo und dafür bekommst du jetzt die Quittung.
Also mein Vorschlag:
Neue VM machen, zum DC erheben, Bisherige VM den DC demoten.
Backup machen, INstantrecovery auf neuem Store usw
Wenn der Chef keine Downtime haben will, muss er das Geld für EssentialsPlus oder Standard in die Hand nehmen. Dann ist das kein Problem.
Evtl. kannst du ja eine kurzzeitige Trialzeit dafür noch aktivieren?
Wäre das jetzt kein DC, würde ich sagen du machst ein Backup der Maschine und stellst das per Instant Recovery auf dem neuen Store wieder her. Alte VM stoppen und neue hochfahren. Warten bis Recovery durch ist und alte VM entfernen.
Aber: Du hast den üblen Fehler begangen einen DC auch noch mit anderen Diensten zu belegen. Das ist ein NoGo und dafür bekommst du jetzt die Quittung.
Also mein Vorschlag:
Neue VM machen, zum DC erheben, Bisherige VM den DC demoten.
Backup machen, INstantrecovery auf neuem Store usw
Zitat von @Penny.Cilin:
Dann mittels Robocopy die Daten der 6 TB Platte auf die erstellte VMDK synchen, damit man die aktuellen Daten hat.
Dann mittels Robocopy die Daten der 6 TB Platte auf die erstellte VMDK synchen, damit man die aktuellen Daten hat.
Oder wie ich oben schon sagte, gleich die neue VMDK per RAID1 befüllen.
lks
Moin,
welche Daten liegen denn auf deiner 6TB großen vDisk?
Folgenden Aussage entnehme ich, dass es "lediglich" Daten eines Gruppenlaufwerkes sind, auf die du ggf. 2-3 Tage verzichten könntest:
Wenn dem so ist (also reiner Content eines File-Servers), hättest du zwei Möglichkeiten:
Variante 1 (Die Quick 'n' Dirty):
Die Disk (wie von dir vorgeschlagen) über den vSPhere Client entfernen (aber nicht vom DataStore löschen), die vDisk verschieben und wenn alles fertig, vom neuen Ort wieder einbinden.
Variante 2 (basierend auf bereits genannte Lösungen):
Beides klappt aber zunächst nur Fehlerfrei, wenn keine anderen lebenswichtigen Dienste auf der 6TB großen vDisk abgelegt sind.
Btw: Würde ich ggf. sogar mal schauen, ob man die 6TB nicht im Rahmen des Umzuges in 3-4 kleinere vDisks gesplittet bekommt. Ist aber meine persönliche Meinung. Denn kleinere DIensk lassen sich besser handhaben.
Gruß
em-pie
welche Daten liegen denn auf deiner 6TB großen vDisk?
Folgenden Aussage entnehme ich, dass es "lediglich" Daten eines Gruppenlaufwerkes sind, auf die du ggf. 2-3 Tage verzichten könntest:
Meine Idee ist es nun die Disk (Laufwerk F auf dem Server) irgendwie offline zu schalten und temporär an eine andere virtuelle Maschine anzuhängen.
Der Datenspeicher kann ruhig mal 2 - 3 Tage fehlen. Der ganze Server ist eher schwierig.
Der Datenspeicher kann ruhig mal 2 - 3 Tage fehlen. Der ganze Server ist eher schwierig.
Wenn dem so ist (also reiner Content eines File-Servers), hättest du zwei Möglichkeiten:
Variante 1 (Die Quick 'n' Dirty):
Die Disk (wie von dir vorgeschlagen) über den vSPhere Client entfernen (aber nicht vom DataStore löschen), die vDisk verschieben und wenn alles fertig, vom neuen Ort wieder einbinden.
Variante 2 (basierend auf bereits genannte Lösungen):
- Freigaben des alten Server exportieren: https://www.team-debold.de/2014/08/09/windows-freigaben-umziehen/
- Neue VM hochziehen, die Disk auf dem "alten" Server wieder entfernen und an den neuen Server anhängen.
- Die Freigaben anpassen:
- Die vDisk am neuen Server mit dem selben Laufwerksbuchstaben versehen.
- Freigaben am euen Server importieren (zuvor ggf. unnötiges aus der exportierten registry-Datei entfernen)
- LoginSkripte/ GPOs auf den neuen Servernamen anpassen
Beides klappt aber zunächst nur Fehlerfrei, wenn keine anderen lebenswichtigen Dienste auf der 6TB großen vDisk abgelegt sind.
Btw: Würde ich ggf. sogar mal schauen, ob man die 6TB nicht im Rahmen des Umzuges in 3-4 kleinere vDisks gesplittet bekommt. Ist aber meine persönliche Meinung. Denn kleinere DIensk lassen sich besser handhaben.
Gruß
em-pie
Servus,
Variante 3(VEEAM Vorrausgesetzt)
Du machst ein Replica auf ein ein anderen Storage, Initial dürfte das etwas dauern, aber ok. Der Abgleich der Daten sollte dann recht schnell innerhlab von 2-3 Stattfinden.
Danach ist einfach dein Replica die neue VM. Nicht die schönste Variante aber sie Funktioniert.
Grüße STITDK
PS: Steinigt mich nicht ;)
Variante 3(VEEAM Vorrausgesetzt)
Du machst ein Replica auf ein ein anderen Storage, Initial dürfte das etwas dauern, aber ok. Der Abgleich der Daten sollte dann recht schnell innerhlab von 2-3 Stattfinden.
Danach ist einfach dein Replica die neue VM. Nicht die schönste Variante aber sie Funktioniert.
Grüße STITDK
PS: Steinigt mich nicht ;)