2026: Warum hat eine Proxmox VE 9.2-VM nach der Erweiterung keinen zusätzlichen Speicherplatz?

Erweitern Sie eine virtuelle Festplatte in Proxmox VE nicht erneut, bevor Sie den freien Platz im Host-Speicher geprüft haben: Die Vergrößerung der virtuellen Platte erweitert weder automatisch die Partition noch LVM oder das Dateisystem im Gast. Gehen Sie danach Schicht für Schicht vor und halten Sie an, sobald Sie die betreffende Ebene nicht eindeutig identifizieren können. Das ist besonders wichtig, wenn der Speicherpool knapp ist oder eine produktive VM betroffen ist.

Dieser Leitfaden richtet sich an Administratoren, die Proxmox VE 9.2 auf einem einzelnen Host oder als VM-Ressourcenpool betreiben, an MSP-Teams mit mehreren Kunden-VMs und an kleine IT-Teams mit Entwicklungs- oder internen Dienstsystemen. Er hilft Ihnen, eine unveränderte Kapazitätsanzeige einzuordnen, statt vorschnell dieselbe Festplatte mehrfach zu vergrößern.

Die Kapazität besteht aus mehreren getrennten Ebenen

Die Proxmox-VE-9.2-Veröffentlichung nennt den Versionsstand, belegt aber nicht, dass sich eine Änderung an der virtuellen Festplatte automatisch bis zum Dateisystem im Gast fortsetzt. Prüfen Sie das Verhalten für Ihren konkreten Aufbau anhand der offiziellen Proxmox-VE-9.2-Veröffentlichung und der Proxmox-Verwaltungsdokumentation zu Speicher und virtuellen Festplatten.

Für die Fehlersuche ist entscheidend, dass Sie vier Ebenen auseinanderhalten:

Eine erfolgreich ausgeführte Änderung kann deshalb in Proxmox sichtbar sein, während df im Linux-Gast weiterhin die alte Dateisystemgröße anzeigt. Umgekehrt kann ein Problem schon auf dem Host liegen: Bei einem knappen oder erschöpften Pool ist die Frage nicht zuerst, wie der Gast seine Partition erweitert, sondern ob der Speicher-Backend die geplante Änderung zuverlässig aufnehmen kann.

Die Tabellenwerte sind keine Fehlerdiagnose. Ordnen Sie Ihre Beobachtung einer Ebene zu und prüfen Sie erst danach den nächsten Schritt. Das reduziert das Risiko, am falschen Datenträger zu arbeiten oder eine bereits ausreichend große virtuelle Festplatte weiter zu vergrößern.

Was Sie vor jeder Änderung abgleichen sollten

Beginnen Sie mit dem VM-Inventar und einer Sicherung, deren Wiederherstellbarkeit Sie nachvollziehen können. Notieren Sie die VM-ID, den zugehörigen Datenträger-Slot, den konfigurierten Speicher und den Zeitpunkt der letzten Sicherung. Gleichen Sie diese Angaben mit dem Ticket oder Änderungsauftrag ab. Wenn Sie mehrere ähnliche VMs betreuen, verlassen Sie sich nicht allein auf einen frei gewählten Anzeigenamen.

Prüfen Sie anschließend den Host-Speicher, auf dem der VM-Datenträger tatsächlich liegt. Ein Speicher kann als Verzeichnis, LVM-Thin-Pool oder mit einem anderen unterstützten Backend eingerichtet sein; Freiraum und Belegung werden je nach Backend unterschiedlich interpretiert. Die Proxmox-Verwaltungsanleitung beschreibt die Speicherarten und deren Verwaltung. Verwechseln Sie nicht freien Platz im Gast mit freiem Platz im Host-Pool: Der Gast kann wenig freien Speicher melden, während der Pool ausreichend Platz hat – oder umgekehrt.

Ein typischer Fall: Eine Entwicklungs-VM meldet, dass ihr Stammdateisystem fast voll ist. In Proxmox scheint die virtuelle Platte bereits vergrößert. Das ist zunächst kein Beweis, dass die Änderung fehlgeschlagen ist: Die Vergrößerung kann auf Datenträgerebene angekommen sein, während Partition, logischer Datenträger oder Dateisystem noch die ursprüngliche Grenze verwenden. Wenn jedoch der Host-Pool kaum Reserven hat, kann eine weitere Vergrößerung die Host-Seite verschärfen, ohne das Problem im Gast zu beheben.

Achtung: Vor einer Änderung an Partitionen, logischen Volumes oder Dateisystemen benötigen Sie eine gültige Sicherung und einen realistischen Wiederherstellungsweg. Planen Sie für produktive Systeme ein Wartungsfenster. Wenn Backend, Datenträgerzuordnung oder Gast-Layout unklar sind, stoppen Sie die Änderung, statt auf Verdacht fortzufahren.

Beziehen Sie auch Snapshots, Backups und andere VM-Datenträger in Ihre Kapazitätsprüfung ein. Ein angezeigter freier Wert allein beantwortet nicht zwingend, ob die geplante Änderung für Ihr Backend sinnvoll ist. Entscheidend sind der tatsächliche Speicherort, die aktuelle Belegung und die geplante Änderung.

Wann vergrößert qm resize nur die virtuelle Platte?

Prüfen Sie zuerst die VM-Konfiguration auf dem Proxmox-Host und vergleichen Sie den dort aufgeführten Festplatten-Slot mit dem Datenträger, den Sie ändern wollten. Die offizielle Referenz zum qm-Befehl dokumentiert die Syntax von qm disk resize. Ein Aufruf mit Platzhaltern sieht grundsätzlich so aus:

qm config <VMID>
qm disk resize <VMID> <Festplatten-Slot> +<Größe>

Ersetzen Sie die Platzhalter durch die Werte Ihrer Umgebung; führen Sie die Änderung nicht aus, bevor Sie VM-ID und Slot verifiziert haben. Der Befehl bezieht sich auf die virtuelle Festplatte. Er ist kein allgemeiner Befehl, der anschließend eigenständig Linux-Partitionen, LVM-Strukturen, Windows-Volumes oder Dateisysteme im Gast erweitert.

Prüfen Sie nach der Änderung getrennt, ob Proxmox die gewünschte Kapazität für genau diesen Datenträger anzeigt und ob das Gastbetriebssystem das Blockgerät mit der erwarteten Größe erkennt. Zeigt Proxmox weiterhin die alte Größe, kontrollieren Sie zuerst den Slot, das Ziel-Backend und den Änderungsstatus. Zeigt Proxmox die neue Größe, aber der Gast nicht, konzentrieren Sie sich auf die Erkennung innerhalb des Gasts. Ein Neustart kann in bestimmten Konstellationen Teil der Diagnose sein, ist aber kein Ersatz für die Überprüfung der Datenträgerzuordnung und sollte nicht ohne Berücksichtigung der Dienstverfügbarkeit angesetzt werden.

Warum bleibt df nach einer Proxmox-Erweiterung unverändert?

df zeigt die Belegung und verfügbare Kapazität eingehängter Dateisysteme an – nicht die konfigurierte Größe der virtuellen Festplatte auf dem Proxmox-Host. Lesen Sie die Ausgabe daher zusammen mit Informationen zu Blockgeräten und Einhängepunkten. Unter Linux können beispielsweise lsblk -f, findmnt und df -hT helfen, Datenträger, Dateisysteme und Mountpoints zueinander in Beziehung zu setzen. Falls LVM verwendet wird, prüfen Sie zusätzlich die physischen Volumes, Volume-Gruppen und logischen Volumes.

Wenn das Blockgerät im Gast bereits größer ist, die Partition aber nicht, liegt der nächste Prüfschritt auf der Partitionsebene. Wenn auch die Partition die neue Grenze erreicht, aber die Anwendung weiterhin eine alte Dateisystemgröße sieht, prüfen Sie, ob ein LVM-Schritt fehlt oder das Dateisystem noch nicht erweitert wurde. Arbeiten Sie diese Kette in Reihenfolge ab. So beantworten Sie auch die häufige Frage, weshalb eine Proxmox-VM trotz vergrößerter Festplatte in Linux weiterhin den bisherigen Platz meldet: Die Anzeige kann korrekt sein, weil sie eine andere Ebene abbildet.

Partition, LVM und Dateisystem getrennt behandeln

Sobald der Gast das größere Blockgerät erkennt, lesen Sie zunächst die Partitionstabelle und die Zuordnung der Geräte aus. Achten Sie darauf, wo nicht zugeordneter Platz liegt und zu welcher Partition oder welchem logischen Volume das eingehängte Dateisystem gehört. Verwechseln Sie nicht freien Platz innerhalb einer Volume-Gruppe mit freiem Platz am Ende der Partition: Das sind unterschiedliche Voraussetzungen für den nächsten Schritt.

Bei einer normalen Partition müssen Sie feststellen, ob der freie Bereich an die Partition anschließt, die Sie erweitern möchten. Erst wenn die Lage eindeutig ist und die Wiederherstellung vorbereitet wurde, wählen Sie ein für Partitionsschema und Gastbetriebssystem geeignetes Verfahren. Eine Änderung der Partitionstabelle und das Vergrößern des Dateisystems sind getrennte Vorgänge. Überspringen Sie diese Unterscheidung nicht, auch wenn ein Werkzeug mehrere Änderungen in einem Ablauf anbieten kann.

Bei LVM prüfen Sie, ob zunächst die zugrunde liegende Partition erweitert werden muss oder ob die Volume-Gruppe bereits freien Platz enthält. Danach folgen – je nach tatsächlichem Zustand – die Anpassung des physischen Volumes, die Erweiterung des logischen Volumes und schließlich die Dateisystemerweiterung. Die Dokumentation zur Verwaltung logischer Volumes erläutert die LVM-Ebenen und ihre Abhängigkeiten. Leiten Sie daraus nicht ab, dass jeder Gast dieselbe Reihenfolge oder dieselben Voraussetzungen hat: Prüfen Sie zuerst, welche Schicht bereits freien Platz enthält.

Für ein Linux-Dateisystem gelten ebenfalls unterschiedliche Verfahren. resize2fs ist für ext-Dateisysteme vorgesehen; lesen Sie vor dem Einsatz die Handbuchseite zu resize2fs und prüfen Sie den Dateisystemtyp sowie das zugrunde liegende Gerät. XFS wird mit einem anderen Werkzeug erweitert; die Dokumentation zu xfs_growfs beschreibt die dafür geltenden Voraussetzungen. Wenden Sie nicht den Befehl für ext auf XFS an oder umgekehrt. Selbst wenn ein Dateisystem online erweitert werden kann, ist das keine pauschale Garantie, dass die gesamte Änderung ohne Unterbrechung oder Risiko für jede konkrete VM sicher ist.

Was ist bei einem Windows-Gast anders?

Trennen Sie auch unter Windows zwischen der Größe des virtuellen Datenträgers, dem erkannten Datenträger und dem Volume, dessen Kapazität Anwendungen nutzen. Vergewissern Sie sich zunächst, dass Windows den betreffenden Datenträger und den nicht zugeordneten Bereich korrekt anzeigt. Achten Sie darauf, ob der freie Bereich für das gewünschte Volume nutzbar angeordnet ist. Die Microsoft-Anleitung zum Erweitern eines einfachen Volumes beschreibt die unterstützten Schritte und Bedingungen. Prüfen Sie diese Bedingungen, bevor Sie im Datenträgermanagement Änderungen vornehmen.

Der sichere Prüfpfad für die nächsten Schritte

Gehen Sie bei der Diagnose in dieser Reihenfolge vor. Wenn ein Prüfschritt nicht eindeutig ist, lassen Sie die Änderung aus und klären Sie zuerst den Zustand.

1. VM und Datenträger identifizieren: Gleichen Sie VM-ID, Festplatten-Slot und betroffenen Gast-Mountpoint mit Ihrem Änderungsauftrag ab. Prüfen Sie, ob Sie wirklich den Datenträger der betroffenen Anwendung untersuchen.
2. Host-Speicher prüfen: Stellen Sie fest, welches Proxmox-Backend den Datenträger enthält und ob der Speicherpool die geplante Änderung tragen kann. Bei knappem oder unklarem Host-Speicher erweitern Sie nicht auf Verdacht.
3. Sicherung und Wiederherstellung bestätigen: Vergewissern Sie sich, dass die Sicherung den betroffenen Zustand abdeckt und dass ein Rückweg im Störungsfall bekannt ist. Für produktive Systeme legen Sie einen Wartungszeitraum fest.
4. Kapazität auf Proxmox-Ebene prüfen: Kontrollieren Sie die VM-Konfiguration und den richtigen Slot. Verwenden Sie qm resize nur, wenn die Host-Seite die Erweiterung zulässt und die beabsichtigte Änderung bestätigt ist.
5. Erkennung im Gast prüfen: Vergleichen Sie die Größe des Blockgeräts mit der Proxmox-Anzeige. Ist sie noch unverändert, untersuchen Sie Erkennung, Zuordnung und Systemstatus, bevor Sie Partition oder Dateisystem verändern.
6. Partition und LVM zuordnen: Lesen Sie Partitionsschema, freie Bereiche und gegebenenfalls LVM-Strukturen aus. Wählen Sie die nächste Maßnahme nur, wenn klar ist, wo die zusätzliche Kapazität liegt.
7. Dateisystem anpassen und abnehmen: Verwenden Sie ein für den tatsächlich erkannten Dateisystemtyp geeignetes Verfahren. Prüfen Sie anschließend getrennt Blockgerät, Partition, logisches Volume und gemeldete Dateisystemkapazität.

Die Schritte sind Diagnose- und Kontrollpunkte, kein universelles Rezept für eine bestimmte Gastkonfiguration. Wenn etwa der Datenträger als virtuelles Gerät größer ist, im Gast jedoch ein anderer Slot geprüft wird, führt jeder nachfolgende Dateisystembefehl in die falsche Richtung.

Welche Entscheidung passt zu Ihrem Prüfergebnis?

• Wenn der Proxmox-Speicherpool ausreichend Platz hat und der richtige virtuelle Datenträger noch nicht vergrößert wurde, prüfen Sie Slot und Änderungsauftrag und bewerten Sie erst dann eine Erweiterung mit qm resize.
• Wenn Proxmox die vergrößerte Festplatte zeigt, der Gast aber eine kleinere Blockgerätekapazität erkennt, stoppen Sie Dateisystemänderungen und klären Sie zuerst die Erkennung und Datenträgerzuordnung im Gast.
• Wenn das Blockgerät größer ist, die Partition aber nicht, prüfen Sie Lage und Aufbau des nicht zugeordneten Bereichs, bevor Sie die Partition anpassen.
• Wenn Partition oder Volume bereits groß genug sind, das Dateisystem aber nicht, wählen Sie das passende Verfahren für Dateisystem und LVM-Aufbau; führen Sie nicht erneut qm resize aus.
• Wenn der Host-Pool knapp, die Sicherung nicht wiederherstellbar oder das Layout unklar ist, verschieben Sie die Änderung und klären Sie erst Speicherplanung, Backup oder Wiederherstellungsweg.

Abnahme: jede Ebene erneut kontrollieren

Nach der Änderung prüfen Sie nicht nur die Anzeige, die ursprünglich das Problem gemeldet hat. Kontrollieren Sie, ob Proxmox für den richtigen Datenträger die erwartete Größe ausweist, ob der Gast das größere Blockgerät erkennt und ob Partition oder LVM den verfügbaren Bereich tatsächlich einbeziehen. Zum Schluss prüfen Sie die Kapazität des eingehängten Dateisystems. Diese getrennte Abnahme zeigt, ob die Änderung an der vorgesehenen Stelle angekommen ist.

Vergleichen Sie vor und nach der Änderung außerdem, ob der erwartete Mountpoint weiterhin korrekt eingebunden ist und Anwendungen auf den vorgesehenen Pfad schreiben. Eine neue Gesamtkapazität hilft einer Anwendung nicht, wenn sie ein anderes Dateisystem nutzt. Dokumentieren Sie VM, Datenträgerslot, Backend, Sicherung, durchgeführte Änderungen und Prüfergebnis. Das ist insbesondere bei MSP-Umgebungen hilfreich, in denen mehrere Kunden-VMs ähnlich benannt oder nach ähnlichen Mustern aufgebaut sind.

Wenn die Werte zwischen Ebenen weiterhin widersprüchlich sind, wiederholen Sie keine verändernden Befehle, um „zu sehen, ob es dann klappt“. Sichern Sie die Diagnoseausgaben, überprüfen Sie die Zuordnung erneut und ziehen Sie die Dokumentation für genau das verwendete Backend und Gast-Dateisystem heran. Fehlt Ihnen eine belastbare Aussage zum Layout, ist eine Pause die sicherere Betriebsentscheidung als eine nicht nachvollziehbare Speicheränderung.

Einzelne VM erweitern oder Host-Speicher neu planen?

Eine volle VM und ein fast erschöpfter Host-Speicher sind unterschiedliche Probleme. Ist nur ein Gast-Dateisystem knapp und verfügt der Host-Pool über nachvollziehbare Reserven, kann eine gezielte Erweiterung des virtuellen Datenträgers sinnvoll sein. Ist dagegen der Pool selbst nahe an seiner Kapazitätsgrenze, verschiebt eine größere VM-Platte das Problem nicht: Sie kann die verfügbare Reserve weiter reduzieren. In diesem Fall sollten Sie zuerst Belegung, Aufbewahrung von Backups und Snapshots, Speicherbackend sowie die geplante Zahl weiterer VMs neu bewerten.

Entscheiden Sie nach diesen Bedingungen:

• Ein einzelnes Dateisystem ist knapp, der Host-Pool hat ausreichend geprüften Spielraum: Bewerten Sie eine Erweiterung dieses VM-Datenträgers und passen Sie anschließend die notwendigen Gast-Schichten an.
• Mehrere Gäste wachsen gleichzeitig oder der Pool wird knapp: Planen Sie zuerst die Host-Speicherkapazität und deren Nutzung neu; behandeln Sie nicht jede VM isoliert.
• Die Datenlage zu freiem Platz, Backup oder Wiederherstellung ist unvollständig: Verschieben Sie die Änderung, bis diese Punkte geklärt sind.
• Sie benötigen dauerhaft mehrere eigenständig verwaltete VMs und kontrollierbare Speicherzuordnung: Vergleichen Sie eine dedizierte physische Maschine mit Ihrem aktuellen Angebot, statt eine knappe gemeinsame Ressource immer weiter zu belasten.

Wenn Sie einen Server auswählen, prüfen Sie die tatsächlich angebotenen Laufwerke, Optionen, installierbaren Systeme und Abrechnungsbedingungen in der AmdMetal-Produktübersicht. Falls Sie zunächst klären möchten, wie der Serverzugang nach der Bereitstellung erfolgt, finden Sie dazu Informationen im Zugangsleitfaden. Übernehmen Sie keine Speicherkonfiguration aus einem Beispiel als zugesicherte Ausstattung: Maßgeblich sind die Optionen, die für das konkrete Angebot ausgewiesen sind.

Für eine kurzlebige Test-VM, eine geringe und schwankende Last oder ein Vorhaben, das nur für wenige Stunden zusätzlichen Platz braucht, ist ein geteilter Cloud- oder VPS-Tarif häufig die passendere Wahl. Prüfen Sie dabei aber, wie sich gemeinsam genutzte Ressourcen, Speicherlimits und zusätzliche Kosten auf Ihren Betrieb auswirken. Wenn Sie dagegen einen dauerhaft betriebenen VM-Pool mit eigener Speicherplanung brauchen, können geteilte CPU- und Speicherressourcen, begrenzte Kontrolle über das Laufwerkslayout und schwer vergleichbare Zusatzkosten den Betrieb erschweren. Dann kann ein von Ihnen selbst verwalteter AMD-Server von AmdMetal die passendere Grundlage sein – sofern die im Angebot ausgewiesenen Speicheroptionen zu Ihrem Bedarf passen. Beginnen Sie mit dem Produktvergleich und entscheiden Sie erst, wenn der Host-Speicherbedarf Ihrer geplanten VMs nachvollziehbar ist.