Rickmer
Fleet Admiral
- Registriert
- Sep. 2009
- Beiträge
- 22.144
Moin,
Ich habe hier angefangen zu schreiben um um Hilfe zu fragen.
Mittlerweile habe ich mein Problem selbst gelöst, aber hatte bis dahin schon einiges geschrieben. Da ich mir meine Lösung über mehrere alte Foren-Threads zusammengoogeln und dann mit einer Prise trial&error zusammenwürfeln durfte dachte ich mir, ich schreib den Rest noch nieder, damit irgendwer, irgendwann, weniger suchen muss als ich.
Ich habe einen Windows Server 2019 Hyper-V Host, auf dem eine VM läuft. (Okay, es laufen mehrere VMs drauf, aber nur eine die jetzt relevant ist.) Da waren ein paar Prüfpunkte offen, aber ich wollte trotzdem 'kurz mal' die vhdx für die sekudäre Datenplatte vergrößern.
Neugierig wie ich bin habe ich einfach mal per 'Datenträger bearbeiten' die neuste avhdx von 100GB auf 250GB vergrößert. Zweifelsohne eine schelchte Idee, aber ich wollte es wissen. Hat Hyper-V auch kommentarlos gemacht. Interessant.
In der VM ist nichts größer geworden, also mal shutdown und Prüfpukt-Merge. Da kam dann eine Fehlermeldung und es ist noch eine avhdx übrig geblieben.
Die Fehlermeldungen in der Ereignisanzeige in der Reihenfolge wie sie aufgetreten sind:
Danach hatte ich dann noch einen manuellen Merge per Diskpart versucht:
und dasselbe nochmal versucht nachdem ich die avhdx wieder auf 100GB reduziert hatte. Kein Erfolg. Da sind wieder dieselben Fehlermeldungen gekommen.
Dasselbe mit Powershell:
Ein Merge in eine neue vhdx war dann möglich, aber lässt sich nicht als neue Festplatte übernehmen, weil der Hyper-V-Manager noch die durchzuführende Zusammenführung sieht:
"Fehler beim Übernehmen von Festplatte Änderungen. Der Datenträger kann nicht geändert werden, da eine Datenträgerzusammenführung aussteht."
(Text der Fehlermeldung abgeschrieben damit Suchmaschinen den finden können)
Also stattdessen den Datenträger gelöscht und die aus dem Merge entstandene vhdx als neue Festplatte angehängt. Die VM gebootet - kein Problem. Nice.
Einen neuen Prüfpunkt erstellen und dann wieder mergen hat auch fehlerfrei geklappt. Doppelt nice.
Datenverlust scheint auch keiner vorhanden zu sein und die VHDX lässt sich jetzt problemlos erweitern. Ich habe jetzt auch mit Schrecken gelernt, dass es unter Ubuntu 20.04 nicht möglich ist, eine HDD 'on the fly' zu erweitern - der zusätzliche freie Platz wird bei gebooteter VM einfach nicht erkannt. WTF?
Bei Windows geht das schon seit Ewigkeiten und war mehrmals schon extrem hilfreich bei Systemen die sofort mehr Platz brauchten aber Downtime unmöglich war.
Vielleicht hilft das ja irgendwann mal jemandem
PS @ die Mods: Es gibt Server 2000-2016 Präfixes, aber kein 2019. Könnte mal ergänzt werden.
Ich habe hier angefangen zu schreiben um um Hilfe zu fragen.
Mittlerweile habe ich mein Problem selbst gelöst, aber hatte bis dahin schon einiges geschrieben. Da ich mir meine Lösung über mehrere alte Foren-Threads zusammengoogeln und dann mit einer Prise trial&error zusammenwürfeln durfte dachte ich mir, ich schreib den Rest noch nieder, damit irgendwer, irgendwann, weniger suchen muss als ich.
Ich habe einen Windows Server 2019 Hyper-V Host, auf dem eine VM läuft. (Okay, es laufen mehrere VMs drauf, aber nur eine die jetzt relevant ist.) Da waren ein paar Prüfpunkte offen, aber ich wollte trotzdem 'kurz mal' die vhdx für die sekudäre Datenplatte vergrößern.
Neugierig wie ich bin habe ich einfach mal per 'Datenträger bearbeiten' die neuste avhdx von 100GB auf 250GB vergrößert. Zweifelsohne eine schelchte Idee, aber ich wollte es wissen. Hat Hyper-V auch kommentarlos gemacht. Interessant.
In der VM ist nichts größer geworden, also mal shutdown und Prüfpukt-Merge. Da kam dann eine Fehlermeldung und es ist noch eine avhdx übrig geblieben.
Die Fehlermeldungen in der Ereignisanzeige in der Reihenfolge wie sie aufgetreten sind:
- ID 27256 - Auch bei erfolgreicher Zusammenführung kann "D:\Virtual Disks\RIG-Nextcloud\RIG-Nextcloud-Data_EF03C952-5F46-45E6-84EC-6C519283360A.avhdx" aufgrund interner Fehler nicht gelöscht werden: Die Anforderung wird nicht unterstützt. (0x80070032).
- ID 27000 - Fehler beim Öffnen der Anlage "D:\Virtual Disks\RIG-Nextcloud\RIG-Nextcloud-Data_EF03C952-5F46-45E6-84EC-6C519283360A.avhdx": Die Anforderung wird nicht unterstützt..
- ID 27260 - Fehler beim Zusammenführen von "D:\Virtual Disks\RIG-Nextcloud\RIG-Nextcloud-Data_EF03C952-5F46-45E6-84EC-6C519283360A.avhdx": Die Anforderung wird nicht unterstützt. (0x80070032).
- ID 15272 - Fehler beim Zusammenführen des virtuellen Laufwerks.
Danach hatte ich dann noch einen manuellen Merge per Diskpart versucht:
Code:
diskpart
select vdisk file="D:\Virtual Disks\RIG-Nextcloud\RIG-Nextcloud-Data_EF03C952-5F46-45E6-84EC-6C519283360A.avhdx"
merge vdisk depth=1
Dasselbe mit Powershell:
Code:
$Merge = @{
Path = 'D:\Virtual Disks\RIG-Nextcloud\RIG-Nextcloud-Data_EF03C952-5F46-45E6-84EC-6C519283360A.avhdx'
DestinationPath = 'D:\Virtual Disks\RIG-Nextcloud\RIG-Nextcloud-Data.vhdx'
}
Merge-VHD @Merge
Ein Merge in eine neue vhdx war dann möglich, aber lässt sich nicht als neue Festplatte übernehmen, weil der Hyper-V-Manager noch die durchzuführende Zusammenführung sieht:
"Fehler beim Übernehmen von Festplatte Änderungen. Der Datenträger kann nicht geändert werden, da eine Datenträgerzusammenführung aussteht."
(Text der Fehlermeldung abgeschrieben damit Suchmaschinen den finden können)
Also stattdessen den Datenträger gelöscht und die aus dem Merge entstandene vhdx als neue Festplatte angehängt. Die VM gebootet - kein Problem. Nice.
Einen neuen Prüfpunkt erstellen und dann wieder mergen hat auch fehlerfrei geklappt. Doppelt nice.
Datenverlust scheint auch keiner vorhanden zu sein und die VHDX lässt sich jetzt problemlos erweitern. Ich habe jetzt auch mit Schrecken gelernt, dass es unter Ubuntu 20.04 nicht möglich ist, eine HDD 'on the fly' zu erweitern - der zusätzliche freie Platz wird bei gebooteter VM einfach nicht erkannt. WTF?
Bei Windows geht das schon seit Ewigkeiten und war mehrmals schon extrem hilfreich bei Systemen die sofort mehr Platz brauchten aber Downtime unmöglich war.
Vielleicht hilft das ja irgendwann mal jemandem
PS @ die Mods: Es gibt Server 2000-2016 Präfixes, aber kein 2019. Könnte mal ergänzt werden.