VirtualBox: Partitionen vergrößern
Seit Ende August 2010[1] habe ich einen eigenen, kleinen Mailserver in einer virtuellen Maschine am Laufen. Mit VirtualBox und Ubuntu als Linuxdistribution meiner Wahl läuft dieser Server nun schon seit über drei Jahren.
Daher ist es wenig verwunderlich wenn jetzt langsam der damals eher knapp Platz auf den Partitionen ausgeht. Auf / sind inzwischen nur noch 215 MB frei. Höchste Zeit also, die Partitionen etwas zu vergrößern.
amy@farnsworth:~$ df -h
Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
/dev/sda2 5,6G 5,1G 215M 96% /
udev 240M 4,0K 240M 1% /dev
tmpfs 100M 316K 99M 1% /run
none 5,0M 0 5,0M 0% /run/lock
none 248M 0 248M 0% /run/shm
/dev/sda5 9,8G 3,9G 5,4G 42% /home
Es gibt unterschiedliche Lösungen, wie man bei einer virtuellen Maschine die Partitionsgröße verändern kann. Wenn man es so lösen will, wie man es bei »echter Hardware« gewöhnt ist, würde man sich ein neues Laufwerk für VirtualBox anlegen und dann die bisherigen Daten spiegeln.
Bei einer virtuellen Maschine mit einem virtuellen Laufwerk kann man aber auch einfach nur die Größe des Laufwerks verändern. Dafür gibt es ein nettes, kleines Tool: CloneDVI[2]. Es ist eine Anwendung für Windows, lässt sich aber auch unter WINE unter Linux ausführen. Daher nicht von der eventuell ungewohnten Optik der Anwendung irritieren lassen. 
Das Schöne an CloneDVI: Es legt automatisch eine Kopie an. Daher ist es auch für den nicht ganz so sicherheitsbewussten Nutzer geeignet.
Man muss als Ziel eine .vdi-Datei auswählen, welches eine virtuelle Festplatte für VirtualBox darstellt. In meinem Fall die .vdi-Datei meines Mailservers mit (einstmals) Ubuntu 10.10 als Betriebssystem.
Als Ziel schlägt CloneDVI automatisch einen um den Suffix »Clone of« erweiterten Dateinamen für die neue, in der Größe veränderte .vdi-Datei vor.
Da die größe der virtuellen Festplatte verändert werden soll, muss natürlich auch die entsprechende Option ausgewählt werden. Von den ursprünglich 16 Gigabyte soll die virtuelle Festplatte nun gleich auf 32 Gigabyte vergrößert werden. Die zusätzlichen 8 Gigabyte an Speicherplatz sollten dann mindestens für die nächsten drei Jahre für den Betrieb als Mailserver genügen.
Ein wichtiger Hinweis an dieser Stelle: Zumindest bei meiner Ubuntu-Installation muss die UUID beibehalten werden. Standardmäßig gibt CloneVDI an, dass man den Haken bei »Generate new UUID« setzen soll beziehungsweise diese Option aktiviert werden soll.
Mein erster Clone-Versuch mit Vergrößerung der virtuellen Festplatte hatte dann folgendes Resultat:
Beim Versuch die virtuelle Maschine zu starten, führte die neue UUID zu einer Fehlermeldung. Der Mailserver konnte nicht mehr gestartet werden. Natürlich kann man über Umwege (Live CD/DVD einer Linux-Distribution und manuelles Verändern der Komnfigurationsdatei) auch die Variante mit neuer UUID zum Laufen bekommen, allerdings geht es auch weniger umständlich.
Daher einfach die Option »Keep old UUID« aktivieren. Dann funktionert auch später noch der Start der virtuellen Maschine.
Wie viel Zeit für den Klonvorgang samt Größenänderung der virtuellen Festplatte notwendig ist, hängt von der Hardware und natürlich auch von der Größe der virtuellen Festplatte ab.
Bei meinem Rechner (Intel I5 750 mit SATA II Festplatte) waren für das Klonen von 16 Gigabyte mit Vergrößerung auf 32 Gigabyte rund 13 Minuten fällig. Mit einer SSD und einem insgesamt flotteren Rechner würde die Fertigstellung sicherlich weniger Zeit in Anspruch nehmen.
Nachdem der Klonvorgang abgeschlossen wurde, darf man sich nicht über die neue Größe der Datei wundern. Es wurden weiterhin nur rund 13 Gigabyte angezeigt. Da der tatsächlich belegte Speicherplatz von der Größe der virtuellen Festplatte unterscheidet, ist die .vdi-Datei entsprechend kleiner.
Leider wurden die Partitionen nicht automatisch verändert. Zwar ist in einigen Beiträgen zu lesen, dass dies automatisch vorgenommen wird wenn die Option (siehe Screenshots weiter oben) aktiviert wurde, aber zumindest bei meiner Linux-Installation hat sich nichts verändert. Zumal es mir lieber ist, wenn ich selbst bestimmen kann welche Partition wie groß sein soll. Dies ist mir irgendwie deutlich sympathischer.
Damit die Partitionen doch noch größer werden und die 32 Gigabyte genutzt werden, müssen sie irgendwie bearbeitet werden. Im laufenden Betrieb ist dies nicht möglich. Aus diesem Grund habe ich einfach ein Live-Image in Form eines Linux Mint .iso für die virtuelle Maschine bei VirtualBox eingebunden und anschließend die virtuelle Maschine gestartet.
Linux Mint 10 startete wie nicht anders erwartet völlig problemlos. Im Startmenü habe ich einfach die standardmäßig gesetzte Option des Live-Systems genutzt und kurze Zeit später stand auch schon der Gnome-Desktop von Linux Mint 10 bereit.
Anschließend konnte ich gparted starten, denn bei Linux Mint ist es bereits beim Image enthalten und muss nicht einmal nachträglich aus dem Internet heruntergeladen werden.
Der bisherige Stand der Partitionierung sah in gparted wie auf dem folgenden Screenshot ersichtlich aus. »Hinten angehängt« waren die neuen, zusätzlichen 16 Gigabyte Speicherplatz.
Das Verschieben und Vergrößern der Partition kann also direkt beginnen. Ein wichtiger Hinweis: Damit die Partitionen in Größe und Position verändert werden können, dürfen sie nicht gemounted sein.
Weiterhin muss man leider ein wenig umständlich arbeiten, denn man kann nicht einfach die erweiterte Partition beziehungsweise das darin enthaltene logische Laufwerk verschieben. Die erweiterte Partition muss als erster Schritt vergrößert werden bis der gesamte (neue) freie Platz genutzt wird.
Anschließend kann das logische Laufwerk innerhalb der erweiterten Partition verschoben und vergrößert werden.
Ich wollte eine Größe von 18 Gigabyte (statt bisher 10 Gigabyte) für das logische Laufwerk haben. Die 18 Gigabyte sollten sich am Ende der virtuellen Festplatte befinden, damit im Anschluss an die Veränderung von /dev/sda5 auch noch /dev/sda2 vergrößert werden kann.
Nachdem das Verändern der Partitionen bestätigt wurde, beginnt gparted damit, die Änderungen durchzuführen. Die voraussichtliche Restzweit entpuppte sich alledings nur als sehr grobe Schätzung, denn insgesamt musste ich rund 5 Minuten warten bis die Änderung abgeschlossen war.
Nachdem das logische Laufwerk nun am richtigen Platz angekommen war, konnte die erweiterte Partition wieder verkleinert werden. Die 8,36 Gigabyte ungenutzer Speicherplatz sollten zu einem Teil zu /dev/sda2 hinzukommen. Gleichzeitig sollte die Swap-Partition von 512 auf 1024 Megabyte vergrößert werden.
Der nicht belegte Speicherplatz innerhalb der erweiterten Partition kann einfach freigegeben werden. Einfach mit der Maus den Schieber ganz nach rechts an den linken Rand des logischen Laufwerks ziehen.
Nun einfach noch die geplante Aktion »Move /dev/sda3 to the right and shrink it from 25.93 GiB to 17.58 GiB« bestätigen. Weil keine Daten verschoben werden müssen, ist die Aktion nach wenigen Sekunden abgeschlossen.
Die primäre Partitionen /dev/sda1 und /dev/sda2 können direkt verschoben und in der Größe verändert werden. Lediglich bei logischen Laufwerken innerhalb einer erweiterten Partition ist der Ablauf wie oben beschrieben.
Wieso bei der Planung der zu verändernden Größen und Positionen die Lücke von einem Megabyte zwischen den beiden ersten primären Partitionen entstanden ist, kann ich nicht erklären. Ich habe es einfach so belassen.
Weil nun mit dem Verschieben der Partition /dev/sda2 auch wieder viele Daten bewegt werden müssen, dauert diese Aktion wieder etwas länger. Das Vergrößern der Swap-Partition /dev/sda1 hingegen ist schnell abgeschlossen.
Nachdem alle Veränderungen durchgeführt wurden, konnte das vom .iso gestartete Linux Mint 10 beendet werden. Anschließend wurde der Mailserver wie gewohnt gestartet. Die Veränderung der Größe und dem zur Verfügung stehenden freien Speicherplatz ist offensichtlich gelungen:
amy@farnsworth:~$ df -h
Dateisystem 1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf
/dev/sda2 13904224 5257188 7940792 40% /
udev 245464 4 245460 1% /dev
tmpfs 101568 320 101248 1% /run
none 5120 0 5120 0% /run/lock
none 253920 0 253920 0% /run/shm
/dev/sda5 18143664 4082200 13139872 24% /home
Die nächsten Jahre sollte ich also erst einmal keine Probleme mehr haben. Der Mailserver läuft inzwischen auch schon wieder. E-Mails werden abgerufen, auf Spam überprüft und sortiert. Alles wie gehabt – nur mit mehr Speicherplatz.
X_FISH
