EFI, TPM Partitionen
- Thread starter TErxleben
- Start date
Best Practice hab ich dafür ehrlich gesagt keine, weil die Position auf der Platte funktional egal ist. Die Firmware sucht die ESP über die Partitionstyp-GUID, nicht nach Reihenfolge. Nervig wird es eigentlich nur, wenn du hinterher C: vergrößern willst und ESP oder Recovery hinten im Weg liegen. Ist es das, worum es dir geht?
Falls ja: die Recovery-Partition kriegst du mit
Von was auf was hast du denn umgestellt, MBR nach GPT oder von einem anderen Hypervisor rübergeholt? Je nachdem sieht das Layout anders aus.
Falls ja: die Recovery-Partition kriegst du mit
reagentc /disable los, dann löschen und C: erweitern. reagentc /enable legt danach aber keine neue Partition an, sondern hängt WinRE als C:\Recovery\WindowsRE\Winre.wim direkt ins OS-Volume – funktioniert, kostet dich aber die separate Partition. Wer die zurück will, muss sie von Hand per diskpart anlegen und die WIM mit reagentc /setreimage dorthin zeigen lassen. Die ESP würde ich nicht verschieben, das ist Gefrickel mit offline gemounteter Disk und bcdboot danach, und da lässt sich nichts sinnvoll automatisieren. Wenn dir die Anordnung nicht passt, ist eine frisch partitionierte Zieldisk und rüberklonen meist schneller als jedes Verschiebe-Tool.Von was auf was hast du denn umgestellt, MBR nach GPT oder von einem anderen Hypervisor rübergeholt? Je nachdem sieht das Layout anders aus.
Es geht um das evtl. später nötige manuelle Gefrickel, beim Vergrößern von C:
Umstellung passiert i.d.R. beim Update von win10 auf 11 mit zwangsläufig einher gehender SeaBios/q35 Anpassung. Beides schon auf PVE-Basis.
Recovery-Partition sind eh platt und wurscht.
Last edited:
Nimm "Mini Partition Wizard" damit kommt jeder klar - und damit vor dem Klicken erkennbar ist, wohin der Link führt ist er etwas länger:
https://www.heise.de/download/product/minitool-partition-wizard-78907
https://www.heise.de/download/product/minitool-partition-wizard-78907
Wenn ich jede VM manuell anfassen muss, gibt es natürlich einen ganzen Sack mehr oder weniger gut funktionierender Win-Tools.
Genau das will ich ja vermeiden.
Last edited:
Automatisiert und ohne jede VM einzeln anzufassen geht das mMn nur, wenn du das Verschieben komplett sein lässt und die ESP stattdessen neu baust. Sprich: Disk hinten per
Die Reihenfolge ist danach nicht ideal, aber genau das Problem, das dich stört, wäre weg: C: ist wieder direkt erweiterbar. Vorher Snapshot, versteht sich, weil der Bootpfad anfangs nur auf der neuen ESP hängt.
Wo liegt die ESP bei dir nach der Umstellung eigentlich, direkt hinter C: oder ganz am Ende? Je nachdem lohnt sich das Resize gar nicht und du kannst die neue ESP gleich in dem Loch anlegen, das die gelöschte Recovery hinterlassen hat.
qm disk resize ein paar hundert MB größer machen, im Gast dann per diskpart-Skript create partition efi size=300 + format fs=fat32 quick in den neuen freien Platz, bcdboot C:\Windows /s <Laufwerksbuchstabe> /f UEFI drauf, alte ESP löschen und C: in die Lücke erweitern. Das sind zwei Textdateien, die du per qm guest exec über alle VMs drüberjagen kannst, ganz ohne Windows-Tool oder GUI.Die Reihenfolge ist danach nicht ideal, aber genau das Problem, das dich stört, wäre weg: C: ist wieder direkt erweiterbar. Vorher Snapshot, versteht sich, weil der Bootpfad anfangs nur auf der neuen ESP hängt.
Wo liegt die ESP bei dir nach der Umstellung eigentlich, direkt hinter C: oder ganz am Ende? Je nachdem lohnt sich das Resize gar nicht und du kannst die neue ESP gleich in dem Loch anlegen, das die gelöschte Recovery hinterlassen hat.
Prüf doch mal, ob du das mit clonezilla und einer zweiten Disk gelöst bekommst.
Habe das mal die Google ki gefragt :
https://www.google.com/search?q=clonezilla+partitionen+kopieren+und+vergössern+automatisch+script&client=safari&hs=Z80V&sca_esv=3ca1fbc8451fdfd6&hl=de-de&sxsrf=APpeQnv3veK-q8nBUonIlu8bRy2fDTkNwA:1790144073164&udm=50&fbs=ABfTbFUyxjQn9bne4DuflY2dNqqK7N177jWgWpM5fkywM1UejB7tg32RbLFEmja3tIVUafSzeSlOyNd5_GotMH_hNIgLxQAjnLJ9PYBDxLQ7GRJVybHbP4b-3FTzRFU0F6gj_Wj9jCGr3HQY_MEDNTsDlZuWvQsLtvHz3NgADqQI0VqFdLkO6OLhIoUooa9BG1gSYDAQK11M&vsint=&aep=1&ntc=1&cs=1&sa=X&ved=2ahUKEwiBo8-shoSXAxWSAtsEHW8PAxUQ2J8OegQIEBAD&biw=820&bih=1048&dpr=2&mstk=AUtExfDeqcyS5gLudcN4hquEfbcFL1IvnwLBgluxqfx1-fyKWsMyIZ2ggorwg87iInhUbj-LDF5jpa5Zh6Mmonv6Mnn6JRabt5Q9Dlyhz1iZG_Y-03Ngiu66-2rgGWBtfm1QdNsaRw72aWxyA4IRJsRspoSbg9vL07nmoOg&csuir=1
Ansonsten alternativ ein scriptbares partitionierungsprogramm.
Das setzt aber auch voraus, das die Partitionen gleich wären.
wieviele tausend VMs sind den evtl. betroffen?
Habe das mal die Google ki gefragt :
https://www.google.com/search?q=clonezilla+partitionen+kopieren+und+vergössern+automatisch+script&client=safari&hs=Z80V&sca_esv=3ca1fbc8451fdfd6&hl=de-de&sxsrf=APpeQnv3veK-q8nBUonIlu8bRy2fDTkNwA:1790144073164&udm=50&fbs=ABfTbFUyxjQn9bne4DuflY2dNqqK7N177jWgWpM5fkywM1UejB7tg32RbLFEmja3tIVUafSzeSlOyNd5_GotMH_hNIgLxQAjnLJ9PYBDxLQ7GRJVybHbP4b-3FTzRFU0F6gj_Wj9jCGr3HQY_MEDNTsDlZuWvQsLtvHz3NgADqQI0VqFdLkO6OLhIoUooa9BG1gSYDAQK11M&vsint=&aep=1&ntc=1&cs=1&sa=X&ved=2ahUKEwiBo8-shoSXAxWSAtsEHW8PAxUQ2J8OegQIEBAD&biw=820&bih=1048&dpr=2&mstk=AUtExfDeqcyS5gLudcN4hquEfbcFL1IvnwLBgluxqfx1-fyKWsMyIZ2ggorwg87iInhUbj-LDF5jpa5Zh6Mmonv6Mnn6JRabt5Q9Dlyhz1iZG_Y-03Ngiu66-2rgGWBtfm1QdNsaRw72aWxyA4IRJsRspoSbg9vL07nmoOg&csuir=1
Ansonsten alternativ ein scriptbares partitionierungsprogramm.
Das setzt aber auch voraus, das die Partitionen gleich wären.
wieviele tausend VMs sind den evtl. betroffen?
Last edited:
Clonezilla würde ich mir sparen, das heißt pro VM ein ISO booten, zweite Disk dranhängen, Bootreihenfolge umstellen und hinterher wieder aufräumen. Also genau das Anfassen jeder einzelnen VM, das du ja vermeiden willst, nur mit mehr Schritten als vorher. Und die Annahme "Partitionen sind gleich" hält bei in-place gewachsenen Win10-auf-11-Kisten erfahrungsgemäß nicht, da sieht jede Disk ein bisschen anders aus.
Automatisieren lässt sich da nur, was im laufenden Gast passiert. Deswegen der Weg über diskpart plus
Automatisieren lässt sich da nur, was im laufenden Gast passiert. Deswegen der Weg über diskpart plus
bcdboot via qm guest exec, ohne Reboot-Orgie und ohne Tool-Installation im Gast. Aber wo liegt die ESP bei dir nach der Umstellung, direkt hinter C: oder ganz hinten? Dann weiß ich nicht, ob du überhaupt resizen musst oder ob der Platz der gelöschten Recovery schon reicht.Nachdem ich nun gedanklich weiter rumgekaut habe und eine Automatisierung immer unrealistischer erscheint, ist folgendes Szenario der Favorit:
- Win10-VMs bekommen vor Upgrade auf 11 mindestens 128GB+ Speicher.
- Das eigentliche Upgrade auf 11 muss ja eh händisch durchgeführt werden.
- Beten, dass der zugewiesene Speicherplatz nach Upgrade die passende Größe hat
- tägliche, automatisierte Cleanups und sdelete sorgen für gut komprimierbare Backups.
- die VM-Platten für den Betrieb haben eh genügend Kapazität.
- Wenn später einer Win11-VM der Speicherplatz ausgeht, ist eben Gefummel nötig.
Was Du zu deinen Überlegungen auch noch hinzufügen kannst, wäre die Idee einer SWAP-Festplatte.
Zusätzliche Festplatte anlegen, vielleicht 30-50GB und dort das Pagefile hinziehen, aber auf dem Laufwerk C: muss eine kleine (512Mb ~ 1GB) Pagefile vorhanden sein, sonnst spinnt Windows auch wieder.
Wenn du manuell ran gehst kannst auch vorher noch mit einem Partition-Manager etwas anpassen, oder vor der Migration die Platte auf die richtige Größe klonen, dann kannst dir auch das Beten sparen (und hast eine Disk als Backup vor der Umstellung).
Das ist ja dann "nur noch" stumpfes Kochrezept abarbeiten.
Zusätzliche Festplatte anlegen, vielleicht 30-50GB und dort das Pagefile hinziehen, aber auf dem Laufwerk C: muss eine kleine (512Mb ~ 1GB) Pagefile vorhanden sein, sonnst spinnt Windows auch wieder.
Wenn du manuell ran gehst kannst auch vorher noch mit einem Partition-Manager etwas anpassen, oder vor der Migration die Platte auf die richtige Größe klonen, dann kannst dir auch das Beten sparen (und hast eine Disk als Backup vor der Umstellung).
Das ist ja dann "nur noch" stumpfes Kochrezept abarbeiten.
Last edited:
Hi, Windows legt doch nur die Recovery Partition hinter C:. Die kannst du auch getrost löschen und dann steht dir nix im Weg. Habe ich schon ganz oft so gemacht.
Gilt für die ursprüngliche Win10-Installation. Die wurden auch immer gelöscht und es war Ruhe im Karton. Bei upgrade auf Win11, werden aber die nötige EFI und TPM-Partition hinter die c: gepflastert.
Ist bei mir nie passiert, aber ich habe auch nur 2x Win10 nach 11 geupgraded. Wenn du beim PVE bereits eine TPM Disk und EFI Disk drin hast, macht er das trotzdem?
Die PVEs sind alle UEFI-Basis. Die VMs müssen ja vor upgrade eine UEFI und TPM-Partition in der Konfiguration erhalten. Diese werden VM-intern eben immer hinter c: gedonnert.
PS: Irgendwie ja logisch, da Win bis heute keine Partitionen verschieben kann.
Last edited:
Kleine Korrektur am Rande: EFI-Disk und TPM-State aus der PVE-Config landen gar nicht in der Gast-Platte.
Wenn es eh händisch passiert, wäre das der Ansatzpunkt: IIRC nimmt mbr2gpt die vorhandene System-Reserved-Partition vorne als ESP, wenn die groß genug ist. Dann schiebt es nichts hinter C:. Bin mir da aber nicht sicher, ein
efidisk0 und tpmstate0 sind eigene Volumes auf dem Storage, Windows sieht die nicht als Partition auf C:. Was dir hinter C: landet, ist die ESP, die mbr2gpt bei der Umstellung von SeaBIOS anlegt. Dafür schneidet es sich hinten Platz von C: ab, wenn sonst nichts frei ist. Im Gast gibt's keine eigene TPM-Partition, schau mal mit diskpart → list partition nach, was das zweite Ding wirklich ist. Das dürfte ESP plus irgendwas Recovery-artiges sein.Wenn es eh händisch passiert, wäre das der Ansatzpunkt: IIRC nimmt mbr2gpt die vorhandene System-Reserved-Partition vorne als ESP, wenn die groß genug ist. Dann schiebt es nichts hinter C:. Bin mir da aber nicht sicher, ein
mbr2gpt /validate /disk:0 /allowFullOS mit Blick ins Log (C:\Windows\setupact.log) an einer Test-VM vor der Umstellung würde es dir zeigen.Gewundert habe ich mich auch, warum nur eine "physische" Disk innerhalb der VM gesehen wird. Bisher aus Zeitmangel gepaart mit Faulheit. Nun werde ich mich der Thematik intensiv widmen. Habe nämlich Urlaub und Langeweile. Ich frage mich, wozu die hinzugefügten ESP/TPM-Platten zu einer VM dienen.
Last edited:
Die beiden sind keine Platten im eigentlichen Sinn, auch wenn sie in der Hardware-Liste so aussehen.
Das heißt praktisch, beide gehören zur VM wie die eigentliche Disk und müssen mit ins Backup. Vor allem sollte man den TPM-State nicht anfassen, wenn BitLocker oder Windows Hello mit PIN im Spiel ist. Sonst ist der Inhalt weg und du brauchst den Recovery-Key.
efidisk0 ist nur der NVRAM-Speicher der OVMF-Firmware, also das, was bei echter Hardware im Flash vom Mainboard liegt. Dort landen die Booteinträge, die Bootreihenfolge und mit pre-enrolled-keys=1 die Secure-Boot-Keys. Deshalb sind die auch nur ein paar hundert KB bis 4 MB groß. Die ESP mit dem Bootloader liegt ganz normal auf deiner Gast-Disk. tpmstate0 ist der Zustand vom swtpm, also das, was sonst im TPM-Chip steckt. Windows sieht davon nur das TPM-Gerät (tpm.msc), aber keinen Datenträger.Das heißt praktisch, beide gehören zur VM wie die eigentliche Disk und müssen mit ins Backup. Vor allem sollte man den TPM-State nicht anfassen, wenn BitLocker oder Windows Hello mit PIN im Spiel ist. Sonst ist der Inhalt weg und du brauchst den Recovery-Key.