Qemu ist Freie Software, ein Emulator für verschiedene Prozessorarchitekturen und auch ein Virtualisierer und dabei in der Lage die komplette Hardware eines Computers zu emulieren. Insbesondere nützlich um Live-CDs und Betriebssysteme in dieser virtuellen Maschine auszuführen, die Installationen in eine Imagedatei zu schreiben und danach mit dd auf eine externe Festplatte zu übertragen.
Qemu löst für mich damit eine Menge Probleme. Ich kann verschiedene Software und Betriebssysteme spielend leicht testen, ohne dafür jedes mal ein neues Installationsmedium zu brennen oder gar jede Linux-Neuentdeckung auf einem separaten Computer installieren zu müssen.
Es gibt eine neue RC-Version des Debian-Installers und man möchte ihn sofort testen? Man wollte immer schon die neueste Anwendung für das Mobiltelefon mit ARM-Prozessorarchitektur ausprobieren, hat aber das entsprechende Gerät nicht parat. Mit Qemu auf jedem i386 PC möglich.
Welches Betriebssystem ist nun wirklich leichtgewichtig und ab wann beginnen die Probleme? Mit Qemu und der Option -m lässt sich bequem festlegen wie viel Arbeitsspeicher der virtuellen Maschine zugewiesen werden soll. Womit ich der Antwort auf meine Frage, wie viel RAM der Debian-Installer nun tatsächlich benötigt, etwas näher gekommen bin.
Nur um zu zeigen mit wie wenig Aufwand das geht, hier zwei Zeilen.
qemu-img create test.img 1G
qemu -hda test.img -cdrom debian-testing-i386-netinst.iso -boot d -m 32
Der erste Befehl erschafft ein Image namens test.img im Raw-Format mit der Größe 1 Gigabyte. Der zweite Befehl führt Qemu aus und definiert das Image als virtuelle Festplatte und das mit Rtorrent heruntergeladene Debian-Netinstall-ISO als CD-ROM-Laufwerk, von dem beim Start gebootet wird. Mit nur 32 MB Arbeitsspeicher gibt der Debian-Installer folgende Antwort.
Ich wusste das 64 MB RAM ausreichen um Debian Squeeze auf meinem Toshiba Portégé 3110 CT zu installieren und das 16 MB für den anderen Oldie zu wenig waren. Mit 32 MB RAM kommt man zumindest schon einmal in den "low memory"-Modus, die erste Hardwareerkennung und das Mounten der virtuellen CD-ROM funktioniert, doch dann gibt es eine Kernel Panic bei der Einrichtung der Netzwerkkarte, womit hier vorerst Schluss ist.
Interessanterweise ist die Warnung des Debian-Installers bitte mindestens 43 MB RAM zu installieren wirklich nur als absolutes Minimum zu verstehen. Denn auch mit soviel Arbeitsspeicher wird die virtuelle Netzwerkkarte in Qemu nicht automatisch erkannt und nach einer externen Treiber CD gefragt 🙄
Bei 64 MB RAM funktioniert alles einwandfrei und bei 16 MB RAM....
qemu: fatal: Trying to execute code outside RAM or ROM at 0x01449f40
beendet sich Qemu mit einer Fehlermeldung. Immerhin bestätigt das die Erfahrungen mit den anderen beiden Laptops. Was nun den Bereich zwischen 32 MB und 64 MB mit dem Debian-Installer angeht. Hier scheint zumindest etwas Glück gefragt zu sein, vielleicht sieht das ja bei "echter" Hardware wieder anders aus. 😛 Zumindest behauptet K.Mandla in seinem Blog eine Debian-Installation mit 32 MB RAM erfolgreich geschafft zu haben 😉
Hallo,
hoffe ich habe es nicht übersehen aber in der Rubrik Virtualisierung fehlt ein nützlicher Tipp. Wer viel mit virtuellen Filesystemen arbeitet, merkt dass die Komprimierung derselben bald nicht mehr effizient greift. Gezippte Iso’s und HD’s werden immer größer und größer. Abhilfe:
su
dd if=/dev/zero of=nullfile
sync
rm -f nullfile
So werden alle „Löcher“ im Filesystem bis zum Anschlag mit Nullen gefüllt. Je nach Ausgangslage danken es gzip und Co. dann mit teilweise extrem geschumpften Dateigrößen.
Hallo,
extrem nützlich kann das oben beschrieben Nullfile-Procedere bei XP sein. Dank qemu-kvm läuft mein XPSP3+Office schneller als auf meinem alten Original-Rechner. Promblem: Laufwer C: hat 12GB und wird auch als gezipptes qcow2 trotz Qemu-Sparse-Files nicht viel kleiner. Das ließe sich zwar mit Windows-Tools beheben, die Festplatte rattert dann aber ~4 Stunden lang. Innerhalb von Linux gehts in ~2 Minuten! Der Weg:
– Zuerst XP aufräumen. Vor allem wiederholt defragmentieren, bis nichts mehr geht. Evtl. VORHER die ganzen unnötigen System/Backup-Files löschen, was Gigabytes bringen kann (Anleitungen im Netz)
– Dann das Qemu-Image bearbeiten. Falls nötig qcow2 zuerst in raw konvertieren: qemu-img convert -f qcow2 -O raw xp.qcow2 xp.raw
su
mkdir loop
mount -o loop,offset=32256 -t ntfs xp.raw loop
cd loop
dd if=/dev/zero of=nullfile bs=256K
sync
rm -f nullfile
cd ..
umount loop
exit
– Das raw-Image in qcow2 zurück konvertieren: qemu-img convert -f raw -O qcow2 xp.raw xp.qcow2
Ergebnis: statt vorher ~11GB hat mein gezipptes xp.qcow2.gz jetzt nur mehr ~1,3GB. Trotz SP3, ganzer Office-Pro Suite und ein paar Adobe-Speicherfressern und sonstwas. Viel schlanker gehts nicht.
Wichtig: bei mir funktionierts und auch der Filesystem-Check von XP ist mit dem Resultat zufrieden. Trotzdem: die Operation immer nur auf einem Backup machen und dann prüfen!
Anm: qemu-kvm aus dem meinem OpenSuse-Repository (bei anderen vielleicht auch?) hat bei Samba/Internet und XP offensichtlich Probleme. Kein Malheur. Einfach jüngstes Qemu 0.15 selber aus den Sourcen kompilieren und schon geht es.
Den Trick mit den Nullen habe ich irgendwo schon einmal gelesen, nur noch nie ausprobiert. Aber heute ist es ja fast einfacher eine neue 2 TB Festplatte zu ordern. 😉
Wieso beginnt denn das offset bei 32256?
Ohne Offset steigt – zumindest bei meinem OpenSuse – mount mit einer Fehlermeldung aus. Warum gerade 32256?
su
fdisk -lu ntfsimage.raw
Das wirft Startsektor + Sektorgröße aus. Beide multipliziert ergeben die „magische“ Zahl für den Offset. VFAT oder ext2/3/4 brauchen das scheinbar nicht, NTFS aber schon. Sonst ist mount verwirrt …
Ich hatte mal ein ähnliches Problem mit offset. Ich wollte ein mit dd erstelltes image in einem anderen System mounten. Erst nachdem ich den offset richtig eingestellt hatte, konnte ich dann auch tatsächlich auf die Daten zugreifen. Ich wußte, ich hätte es dokumentieren sollen! Naja, wird sich schon wieder hinkriegen lassen. 🙂
Ja, 2 TB Platten wären schon günstig zu haben. Aber wenn ich die in meine alten Server stopfe, dann „explodieren“ dort wahrscheinlich die Bios’e 🙂 Drum hab ich es gerne auch auf meinem Hauptsystem schlank. Dann kommen selbst meine alten Server-Kisten mit einem Voll-Backup des aktuellen Systems zurecht.