13
HyperV VM wiederherstellen anhand VHD Files
Hallo in die Runde!
Da das Thema etwas speziell ist und ich in der Suche leider nichts gefunden habe schildere ich nun die Problematik hier.
Sachstand:
Wir haben einen Server 2008 R2 mit HyperV Rolle. Auf diesem läuft eine VM von welcher bereits durch den Nutzer innerhalb der letzten 2 Jahre mehrere Snapshots erstellt wurden. Der gesamte HyperV Ordner auf dem Host wird mit ArcServe Backup auf Band gesichert.
Nun ist uns über das Wochenende der Host kaputt gegangen und wird hardwaretechnisch wohl nicht mehr herstellbar sein, da anscheinend das Mainboard kaputt ist.
Wiederherstellungsversuche:
Ich habe den gesamten HyperV Ordner vom Band auf einen neuen Server zurückgesichert und dort eine neue HyperV Maschine erstellt. Das xml File der HyperV VM kann man ja leider nicht direkt verwenden wenn die VM vorher nicht korrekt exportiert wurde. Deshalb habe ich eine neue VM erstellt, das eigentliche vhd File zugeordnet und gestartet. Leider sind dort die neuesten Daten nicht vorhanden.
Nach einer Anleitung im Internet habe ich dann, vom neuesten Snapshot beginnend, angefangen die Snapshots miteinander zu verknüpfen um am Ende ein vhd File zu bekommen. Leider schlug dies beim vorletzten .avhd File fehl, da hier wohl ein Fehler in der Wiederherstellungskette vorhanden ist, der nicht lösbar ist.
Ich hab dann ganz einfach der VM den jüngsten Snapshot als Festplatte zugewiesen. Dies hat funktioniert, ohne dass ich den Snapshot von der Dateiendung .avhd in .vhd umbennen musste. Das System fährt hoch, die Daten sind da und alles scheint gut.
Problem:
Sobald ich nun aus dem Ordner, in welchem die Festplatten und die Snapshotdateien liegen, die Snapshotdateien entferne, welche augenscheinlich nicht genutzt werden da sie in der VM Konfiguration nicht eingebunden sind, startet die VM nicht mehr und meldet fehlende Snapshotdateien. Ich habe mich grundsätzlich in das Wesen von HyperV und den Snapshots eingelesen, aber dieses Verhalten kann ich irgendwie nicht nachvollziehen.
1. Warum ist es überhaupt möglich ein .avhd File direkt als Festplatte zu verwenden?
2. Warum sind nun die anderen Snapshots nun im Zugriff bzw. werden benötigt?
3. Was ist hier jetzt eigentlich meine Festplatte?
Ich hätte das gerne verstanden bzw. den Festplattenordner auch mal ein wenig ausgemistet, da hier 2 .vhd Files und ca. 12 .avhd Files liegen und das ganze ca. 300GB groß ist obwohl innerhalb der VM nur ca. 160GB genutzt werden.
Vielleicht kann einer von euch hier etwas Licht ins Dunkel bringen. Vielen Dank euch bereits im Voraus!
Da das Thema etwas speziell ist und ich in der Suche leider nichts gefunden habe schildere ich nun die Problematik hier.
Sachstand:
Wir haben einen Server 2008 R2 mit HyperV Rolle. Auf diesem läuft eine VM von welcher bereits durch den Nutzer innerhalb der letzten 2 Jahre mehrere Snapshots erstellt wurden. Der gesamte HyperV Ordner auf dem Host wird mit ArcServe Backup auf Band gesichert.
Nun ist uns über das Wochenende der Host kaputt gegangen und wird hardwaretechnisch wohl nicht mehr herstellbar sein, da anscheinend das Mainboard kaputt ist.
Wiederherstellungsversuche:
Ich habe den gesamten HyperV Ordner vom Band auf einen neuen Server zurückgesichert und dort eine neue HyperV Maschine erstellt. Das xml File der HyperV VM kann man ja leider nicht direkt verwenden wenn die VM vorher nicht korrekt exportiert wurde. Deshalb habe ich eine neue VM erstellt, das eigentliche vhd File zugeordnet und gestartet. Leider sind dort die neuesten Daten nicht vorhanden.
Nach einer Anleitung im Internet habe ich dann, vom neuesten Snapshot beginnend, angefangen die Snapshots miteinander zu verknüpfen um am Ende ein vhd File zu bekommen. Leider schlug dies beim vorletzten .avhd File fehl, da hier wohl ein Fehler in der Wiederherstellungskette vorhanden ist, der nicht lösbar ist.
Ich hab dann ganz einfach der VM den jüngsten Snapshot als Festplatte zugewiesen. Dies hat funktioniert, ohne dass ich den Snapshot von der Dateiendung .avhd in .vhd umbennen musste. Das System fährt hoch, die Daten sind da und alles scheint gut.
Problem:
Sobald ich nun aus dem Ordner, in welchem die Festplatten und die Snapshotdateien liegen, die Snapshotdateien entferne, welche augenscheinlich nicht genutzt werden da sie in der VM Konfiguration nicht eingebunden sind, startet die VM nicht mehr und meldet fehlende Snapshotdateien. Ich habe mich grundsätzlich in das Wesen von HyperV und den Snapshots eingelesen, aber dieses Verhalten kann ich irgendwie nicht nachvollziehen.
1. Warum ist es überhaupt möglich ein .avhd File direkt als Festplatte zu verwenden?
2. Warum sind nun die anderen Snapshots nun im Zugriff bzw. werden benötigt?
3. Was ist hier jetzt eigentlich meine Festplatte?
Ich hätte das gerne verstanden bzw. den Festplattenordner auch mal ein wenig ausgemistet, da hier 2 .vhd Files und ca. 12 .avhd Files liegen und das ganze ca. 300GB groß ist obwohl innerhalb der VM nur ca. 160GB genutzt werden.
Vielleicht kann einer von euch hier etwas Licht ins Dunkel bringen. Vielen Dank euch bereits im Voraus!
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 253128
Url: https://administrator.de/contentid/253128
Printed on: April 16, 2024 at 15:04 o'clock
13 Comments
Latest comment
Hallo,
Snapshot = die normale vhd auf der installiert wurde wird vom HyperV nicht mehr beschrieben und alle Änderungne werden ab jetzt in die erzeugte Snapshotdatei geschrieben.
Ein neuer Snapshot nimmt dann Bezug auf die derzeitige Snapshotatei usw. es entsteht also eine Kette.
Wenn HyperV nicht in der Lage ist die Daten richtig zusammenzuführen, kannst Du immer noch von dem Snapshot bei dem alles da ist starten (wie du es gemacht hast) und dann ein Image ziehen vom system. (ImageBackup)
Dann eine Neue VHD erstllen und das Image dort einspielen. Dann hast Du eine neue VHD für die Keine Snapshots existieren und kannst den Rest sauber aus der VM entfernen (über HyperV).
Mag auch anders gehen aber so hast Du auf jeden Fall Erfolg.
Gruß
Chonta
Snapshot = die normale vhd auf der installiert wurde wird vom HyperV nicht mehr beschrieben und alle Änderungne werden ab jetzt in die erzeugte Snapshotdatei geschrieben.
Ein neuer Snapshot nimmt dann Bezug auf die derzeitige Snapshotatei usw. es entsteht also eine Kette.
Wenn HyperV nicht in der Lage ist die Daten richtig zusammenzuführen, kannst Du immer noch von dem Snapshot bei dem alles da ist starten (wie du es gemacht hast) und dann ein Image ziehen vom system. (ImageBackup)
Dann eine Neue VHD erstllen und das Image dort einspielen. Dann hast Du eine neue VHD für die Keine Snapshots existieren und kannst den Rest sauber aus der VM entfernen (über HyperV).
Mag auch anders gehen aber so hast Du auf jeden Fall Erfolg.
Gruß
Chonta
Hallo.
Deine 3 Fragen kann ich Dir auch nicht beantworten, doch wenn Du derzeit einen funktionierend laufenden Server hast, kann ich Dir, glaube ich, trotzdem helfen, die Kuh vom Eis zu kriegen.
Es ist eigentlich ganz simpel. Wenn der Server momentan fehlerfrei läuft, alles in Ordnung und aktuell ist, kannst Du Dich ja schonmal glücklich schätzen, egal aus welchen und wievielen Snapshots er derzeit gespeist wird.
Ich würde den Server herunterfahren, und ganz simpel einen Export (re. Maustaste auf virt. Maschine, Kontextmenübefehl "exportieren") durchführen! Durch den Export führst Du die verschiedenen Snapshots, aus denen die Maschine sich momentan irgendwie ganz blöde zusammensetzt, wieder in eine vollständige, einzelne *.vhd zusammen.
Das einzige, was Dir dann noch fehlt, der Export macht das glaube ich nicht mit, ist die Konfiguration der virtuellen Hardware, die solltest Du vorher notieren (Anzahl virt. CPUs, NICs, RAM usw.). Danach neue virtuelle Maschine anlegen (mit den notierten Konfigurationsdaten) und als HDD die beim Export entstandene *.vhd nehmen. Danach ausgiebig testen, und dann kannst die "alte" virt. Maschine mitsamt den Snapshots wegschmeißen ("ausmisten").
Und für die neue Maschine kannst Du dann natürlich auch wieder (neue) Snapshots konfigurieren. Wobei: Wofür überhaupt Snapshots? Sollen die ein Backup-Ersatz sein? Falls ja, ist das nicht unbedingt zu empfehlen, Snapshots dienen zwar ähnlich wie ein richtiges Backup dazu, einen älteren Stand einer VM wiederherzustellen, ein "richtiges" Backup halte ich aber trotzdem für unabdingbar, hier kann ich bspw. VEEAM empfehlen.
Grüße
von
departure
Deine 3 Fragen kann ich Dir auch nicht beantworten, doch wenn Du derzeit einen funktionierend laufenden Server hast, kann ich Dir, glaube ich, trotzdem helfen, die Kuh vom Eis zu kriegen.
Es ist eigentlich ganz simpel. Wenn der Server momentan fehlerfrei läuft, alles in Ordnung und aktuell ist, kannst Du Dich ja schonmal glücklich schätzen, egal aus welchen und wievielen Snapshots er derzeit gespeist wird.
Ich würde den Server herunterfahren, und ganz simpel einen Export (re. Maustaste auf virt. Maschine, Kontextmenübefehl "exportieren") durchführen! Durch den Export führst Du die verschiedenen Snapshots, aus denen die Maschine sich momentan irgendwie ganz blöde zusammensetzt, wieder in eine vollständige, einzelne *.vhd zusammen.
Das einzige, was Dir dann noch fehlt, der Export macht das glaube ich nicht mit, ist die Konfiguration der virtuellen Hardware, die solltest Du vorher notieren (Anzahl virt. CPUs, NICs, RAM usw.). Danach neue virtuelle Maschine anlegen (mit den notierten Konfigurationsdaten) und als HDD die beim Export entstandene *.vhd nehmen. Danach ausgiebig testen, und dann kannst die "alte" virt. Maschine mitsamt den Snapshots wegschmeißen ("ausmisten").
Und für die neue Maschine kannst Du dann natürlich auch wieder (neue) Snapshots konfigurieren. Wobei: Wofür überhaupt Snapshots? Sollen die ein Backup-Ersatz sein? Falls ja, ist das nicht unbedingt zu empfehlen, Snapshots dienen zwar ähnlich wie ein richtiges Backup dazu, einen älteren Stand einer VM wiederherzustellen, ein "richtiges" Backup halte ich aber trotzdem für unabdingbar, hier kann ich bspw. VEEAM empfehlen.
Grüße
von
departure
Das mit dem Export habe ich versucht. Leider ist das seitens Microsoft nicht wirklich gut gemacht, denn er nimmt einfach den Inhalt des HyperV Ordner s und kopiert ihn an den Exportspeichertort ohne etwas zusammenzuführen. Es ist alles 1 zu 1 genauso vorhanden wie vorher. Da verstehe ich echt nicht warum man einen per Dateizugriff gesicherten HyperV nicht wieder einbinden kann (z.B. indem vorher eine VM Analyse prüft ob Abhängigkeiten stimmen etc) sondern diesen sinnlosen Export benutzen muss.
Wie gesagt, hat damit leider nicht funkioniert es zusammen zu führen.
Wie gesagt, hat damit leider nicht funkioniert es zusammen zu führen.
Moin,
mache doch wie schon vorgeschlagen ein Systembackup und restore es in eine neue VM, dann sind die Snaphots auf jeden Fall konsolidiert.
VG,
Thomas
mache doch wie schon vorgeschlagen ein Systembackup und restore es in eine neue VM, dann sind die Snaphots auf jeden Fall konsolidiert.
VG,
Thomas
Zitat von @Alex20:
Nun ist uns über das Wochenende der Host kaputt gegangen und wird hardwaretechnisch wohl nicht mehr herstellbar sein, da
anscheinend das Mainboard kaputt ist.
Wiederherstellungsversuche:
Nun ist uns über das Wochenende der Host kaputt gegangen und wird hardwaretechnisch wohl nicht mehr herstellbar sein, da
anscheinend das Mainboard kaputt ist.
Wiederherstellungsversuche:
Und warum nimmst Du nicht einfach die Platten aus dem Host und transplantierst das ganze auf neue Hardware? Soltle i.d.R. ohen weiteres möglich sein, wenn die Platten bei dem Fehelr nciht gerade gelöscht wurden oder anderweitig schanden genommen haben.
lks
Ist ein "Systembackup" jetzt ein stehender Begriff oder meinst du damit einfach allgemein mit unserer Sicherungsoftware eine Sicherung erstellen? Habe das Feature " Windows Server-Sicherung" auf dem neuen Hyper V Host installiert. Damit kann man aber auch "nur" die HyperV Dateien irgendwohin wegsichern. Ich habe aber kein spezielles HyperV Plugin gefunden das irgendwelche anderen Optionen bietet.
Mit ArcServe Backup haben wir noch nie eine solche Art Disaster Recovery auf eine VM gemacht indem man ab Bios Ebene schon mit einer CD, ISO o.ä. bootet und auf die TapeLibrary zugreift. Hast du einen Tipp oder verstehe ich dich nur nicht?
Mit ArcServe Backup haben wir noch nie eine solche Art Disaster Recovery auf eine VM gemacht indem man ab Bios Ebene schon mit einer CD, ISO o.ä. bootet und auf die TapeLibrary zugreift. Hast du einen Tipp oder verstehe ich dich nur nicht?
Zitat von @Lochkartenstanzer:
> Zitat von @Alex20:
>
> Nun ist uns über das Wochenende der Host kaputt gegangen und wird hardwaretechnisch wohl nicht mehr herstellbar sein,
da
> anscheinend das Mainboard kaputt ist.
>
> Wiederherstellungsversuche:
>
Und warum nimmst Du nicht einfach die Platten aus dem Host und transplantierst das ganze auf neue Hardware? Soltle i.d.R. ohen
weiteres möglich sein, wenn die Platten bei dem Fehelr nciht gerade gelöscht wurden oder anderweitig schanden genommen
haben.
lks
> Zitat von @Alex20:
>
> Nun ist uns über das Wochenende der Host kaputt gegangen und wird hardwaretechnisch wohl nicht mehr herstellbar sein,
da
> anscheinend das Mainboard kaputt ist.
>
> Wiederherstellungsversuche:
>
Und warum nimmst Du nicht einfach die Platten aus dem Host und transplantierst das ganze auf neue Hardware? Soltle i.d.R. ohen
weiteres möglich sein, wenn die Platten bei dem Fehelr nciht gerade gelöscht wurden oder anderweitig schanden genommen
haben.
lks
Derzeit haben wir leider keine baugleiche Maschine frei. Des weiteren kamen Zweifel auf bzgl. des Umstandes ob es immer so ist, dass ein Raid Controller die Konfiguration der eingebauten Festplatten übernimmt oder einfach bei Nichterkennen bzw. fehlender Kompatibilität durch die eigene Konfiguration überschreibt.
Morgen kommend ein Techniker da es noch einen Servicevertrag für besagten Server gibt und wir hoffen, dass es durch einen Boardtausch gelöst werden kann.
Hallo,
so wie ich geschrieben habe.
Da es HyperV ist muss das backupprogram z.B. Clonezilla auf eine Netzwerkfreigabe zugreifen können oder du baust einfach eine zusätzliche vhd gleicher Größe ein, startest die VM bootest Clonezilla und clonst deinen aktuellen Zustand der VM auf die neu eingebaute VHD.
Wenn das durch ist, kannst Du die neue VHD in einer neuen VM einbinden und hast einen konsolidierten Zustand.
Eine VM kannst Du bezüglich DR genauso behandeln wie einen physikalischen Rechner, wenn die VM Sicherung nicht richtig greift.
Gruß
Chonta
so wie ich geschrieben habe.
Da es HyperV ist muss das backupprogram z.B. Clonezilla auf eine Netzwerkfreigabe zugreifen können oder du baust einfach eine zusätzliche vhd gleicher Größe ein, startest die VM bootest Clonezilla und clonst deinen aktuellen Zustand der VM auf die neu eingebaute VHD.
Wenn das durch ist, kannst Du die neue VHD in einer neuen VM einbinden und hast einen konsolidierten Zustand.
Eine VM kannst Du bezüglich DR genauso behandeln wie einen physikalischen Rechner, wenn die VM Sicherung nicht richtig greift.
Gruß
Chonta
Zitat von @Alex20:
> Zitat von @Lochkartenstanzer:
>
> > Zitat von @Alex20:
> >
> > Nun ist uns über das Wochenende der Host kaputt gegangen und wird hardwaretechnisch wohl nicht mehr herstellbar
sein,
> da
> > anscheinend das Mainboard kaputt ist.
> >
> > Wiederherstellungsversuche:
> >
>
> Und warum nimmst Du nicht einfach die Platten aus dem Host und transplantierst das ganze auf neue Hardware? Soltle i.d.R.
ohen
> weiteres möglich sein, wenn die Platten bei dem Fehelr nciht gerade gelöscht wurden oder anderweitig schanden
genommen
> haben.
>
> lks
Derzeit haben wir leider keine baugleiche Maschine frei.
> Zitat von @Lochkartenstanzer:
>
> > Zitat von @Alex20:
> >
> > Nun ist uns über das Wochenende der Host kaputt gegangen und wird hardwaretechnisch wohl nicht mehr herstellbar
sein,
> da
> > anscheinend das Mainboard kaputt ist.
> >
> > Wiederherstellungsversuche:
> >
>
> Und warum nimmst Du nicht einfach die Platten aus dem Host und transplantierst das ganze auf neue Hardware? Soltle i.d.R.
ohen
> weiteres möglich sein, wenn die Platten bei dem Fehelr nciht gerade gelöscht wurden oder anderweitig schanden
genommen
> haben.
>
> lks
Derzeit haben wir leider keine baugleiche Maschine frei.
Das ist kein Hinderungsgrund.
Des weiteren kamen Zweifel auf bzgl. des Umstandes ob es immer so ist,
dass ein Raid Controller die Konfiguration der eingebauten Festplatten übernimmt oder einfach bei Nichterkennen bzw.
fehlender Kompatibilität durch die eigene Konfiguration überschreibt.
dass ein Raid Controller die Konfiguration der eingebauten Festplatten übernimmt oder einfach bei Nichterkennen bzw.
fehlender Kompatibilität durch die eigene Konfiguration überschreibt.
Transplantiert RAID-Controller den doch gleich mit.
Morgen kommend ein Techniker da es noch einen Servicevertrag für besagten Server gibt und wir hoffen, dass es durch einen
Boardtausch gelöst werden kann.
Boardtausch gelöst werden kann.
Da würde ich mit dem restore der VM sowieso warten. oder ist die VM so wichtig, daß die sofort gebraucht wird? Wenn ja, ist an Eurem Konzept etwas falsch.
lks
Zitat von @Lochkartenstanzer:
> Zitat von @Alex20:
>
> > Zitat von @Lochkartenstanzer:
> >
> > > Zitat von @Alex20:
> > >
> > > Nun ist uns über das Wochenende der Host kaputt gegangen und wird hardwaretechnisch wohl nicht mehr
herstellbar
> sein,
> > da
> > > anscheinend das Mainboard kaputt ist.
> > >
> > > Wiederherstellungsversuche:
> > >
> >
> > Und warum nimmst Du nicht einfach die Platten aus dem Host und transplantierst das ganze auf neue Hardware? Soltle
i.d.R.
> ohen
> > weiteres möglich sein, wenn die Platten bei dem Fehelr nciht gerade gelöscht wurden oder anderweitig schanden
> genommen
> > haben.
> >
> > lks
>
> Derzeit haben wir leider keine baugleiche Maschine frei.
Das ist kein Hinderungsgrund.
> Des weiteren kamen Zweifel auf bzgl. des Umstandes ob es immer so ist,
> dass ein Raid Controller die Konfiguration der eingebauten Festplatten übernimmt oder einfach bei Nichterkennen bzw.
> fehlender Kompatibilität durch die eigene Konfiguration überschreibt.
Transplantiert RAID-Controller den doch gleich mit.
> Morgen kommend ein Techniker da es noch einen Servicevertrag für besagten Server gibt und wir hoffen, dass es durch
einen
> Boardtausch gelöst werden kann.
Da würde ich mit dem restore der VM sowieso warten. oder ist die VM so wichtig, daß die sofort gebraucht wird? Wenn
ja, ist an Eurem Konzept etwas falsch.
lks
> Zitat von @Alex20:
>
> > Zitat von @Lochkartenstanzer:
> >
> > > Zitat von @Alex20:
> > >
> > > Nun ist uns über das Wochenende der Host kaputt gegangen und wird hardwaretechnisch wohl nicht mehr
herstellbar
> sein,
> > da
> > > anscheinend das Mainboard kaputt ist.
> > >
> > > Wiederherstellungsversuche:
> > >
> >
> > Und warum nimmst Du nicht einfach die Platten aus dem Host und transplantierst das ganze auf neue Hardware? Soltle
i.d.R.
> ohen
> > weiteres möglich sein, wenn die Platten bei dem Fehelr nciht gerade gelöscht wurden oder anderweitig schanden
> genommen
> > haben.
> >
> > lks
>
> Derzeit haben wir leider keine baugleiche Maschine frei.
Das ist kein Hinderungsgrund.
> Des weiteren kamen Zweifel auf bzgl. des Umstandes ob es immer so ist,
> dass ein Raid Controller die Konfiguration der eingebauten Festplatten übernimmt oder einfach bei Nichterkennen bzw.
> fehlender Kompatibilität durch die eigene Konfiguration überschreibt.
Transplantiert RAID-Controller den doch gleich mit.
> Morgen kommend ein Techniker da es noch einen Servicevertrag für besagten Server gibt und wir hoffen, dass es durch
einen
> Boardtausch gelöst werden kann.
Da würde ich mit dem restore der VM sowieso warten. oder ist die VM so wichtig, daß die sofort gebraucht wird? Wenn
ja, ist an Eurem Konzept etwas falsch.
lks
An unserem Konzept ist auch was falsch. Ist leider ne seeeehr lange Geschichte, eine seeeehr heterogene Hardware- und Softwareumgebung sowie Einsparmaßnahmen an der falschen Ecke....hier Schulungen z.B. der Backupsoftware.
Die VM ist leider sehr wichtig. Aber zum Glück habe ich sie gestartet bekommen indem ich, wie geschrieben, das jüngste .avhd File als Festplatte angegeben habe. Ich wollte lediglich verstehen wie das alles ineinander greift und wie ihr sowas sichert bzw. wiederherstellt. Ich werde jetzt die Clonezillavariante nutzen um das ganze in ein neues VHD File zu imagen und diese dann als HDD einzuhängen.
Hi,
geht auch mit Hyper V Board mitteln.
http://social.technet.microsoft.com/wiki/contents/articles/6257.manuall ...
VG
Mirco
geht auch mit Hyper V Board mitteln.
http://social.technet.microsoft.com/wiki/contents/articles/6257.manuall ...
VG
Mirco
Zitat von @Alex20:
Ich wollte lediglich verstehen wie das alles ineinander greift und wie ihr sowas sichert
bzw. wiederherstellt. Ich werde jetzt die Clonezillavariante nutzen um das ganze in ein neues VHD File zu imagen und diese dann
als HDD einzuhängen.
Ich wollte lediglich verstehen wie das alles ineinander greift und wie ihr sowas sichert
bzw. wiederherstellt. Ich werde jetzt die Clonezillavariante nutzen um das ganze in ein neues VHD File zu imagen und diese dann
als HDD einzuhängen.
Wenn du es kostenlos haben möchtest, Windows Server Backup funktioniert dafür eigentlich ganz gut oder aber ein Powershell Export Script was per Aufgabenplanung abläuft.
Hier ist eins für 2008R2.
http://www.czerno.com/default.asp?inc=/html/windows/hyperv/cluster/Hype ...
Die Exportierten VMs kannst du dann wieder importieren und direkt loslegen.
Shutdown ist für Fileserver nicht unbedingt nötig, bei Datenbank Servern sollte man es machen um konsistente Exports zu bekommen.
Zitat von @Criemo:
Hi,
geht auch mit Hyper V Board mitteln.
http://social.technet.microsoft.com/wiki/contents/articles/6257.manuall ...
VG
Mirco
Hi,
geht auch mit Hyper V Board mitteln.
http://social.technet.microsoft.com/wiki/contents/articles/6257.manuall ...
VG
Mirco
Das habe ich versucht. Insgesamt sind es 10 oder 12 Snapshots bis zum originalen .vhd File. Das hat quasi eine Ewigkeit gedauert
Beim letzten oder vorletzten Snapshot war es dann plötzlich nicht mehr möglich zu verknüpfen da eine Fehlermeldung auftauchte welche so nicht lösbar war bzw. die Beziehung war zwischen diesen beiden .avhd Files nicht herstellbar. Das wars dann mit diesem Versuch leider gewesen 