qemu, kvm, xen & libvirtHauptseite | Über | Hilfe | FAQ | Spezialseiten | Anmelden

Druckversion | Impressum | Datenschutz

Debug- und Experten-Optionen, Live-Migration, Kernel Debugger Software GDB, breakpoint, Logging, Tracing initrd vmlinuz boot, Userspace-Emulation, runas chroot

(Link zu dieser Seite als [[QEMU-KVM-Buch/ Spezielle QEMU-Optionen]])

<<<|###| >>> | English


qemu-arm.
qemu-arm.

Inhaltsverzeichnis

[bearbeiten] Spezielle Optionen

[bearbeiten] Live-Migration

Bei der Live-Migration werden virtuelle Maschinen im laufenden Betrieb von einem Host-System auf ein anderes übertragen. Die Gast-Systeme sind durchgehend verfügbar, auch wenn einer der Hosts für Wartungsarbeiten heruntergefahren werden muss. Es ist zu empfehlen, dass Quell- und Ziel-Host über die gleiche Hardware-Architektur verfügen. Es ist aber zum Beispiel möglich, Gast-Systeme zwischen Hosts mit AMD- und Intel-Architektur oder zwischen Linux- und Windows-Hosts zu migrieren. Wenn die verwendeten Images bei der Live-Migration nicht kopiert werden, müssen Quell- und Ziel-Host auf das bitgenau gleiche Image zugreifen können. Dies kann mit Netzwerkdatei-Systemen, wie zum Beispiel NFS, iSCSI oder NBD, sichergestellt werden. Günstiger ist der Zugriff auf ein hochverfügbares Storage-Area-Network (SAN) mit Lichtwellenleitern. Weiterhin müssen Quell- und Ziel-Host das gleiche Netzwerksegment nutzen. Günstig ist die Verwendung jeweils gleicher Pfade für die virtuelle Maschine auf Quell- und Ziel-Host. Die Option -snapshot ist nicht anzuwenden. Für die Live-Migration sind folgende Schritte notwendig:

  1. Die Instanz wird auf dem Quell-Host betrieben.
  2. Auf dem Ziel-Host wird die Instanz mit den gleichen Optionen wie auf Quell-Host gestartet, wobei zusätzlich die Option -incoming tcp:ip:port anzugeben ist. Der Parameter ip definiert die IP-Adresse zum Empfang der Migration. Wird eine 0 angegeben, wird auf allen Interfaces gelauscht. Der Parameter port definiert das Port. Die gestartete Instanz wartet in einem eingefrorenen Zustand.
  3. Auf dem Quell-Host ist im QEMU-Monitor der Instanz der Befehl migrate -d tcp:ip:port einzugeben. Mit der Option -d wird nicht das Ende der Migration abgewartet, um die Eingabeaufforderung wieder frei zu geben. Der Parameter ip stellt die IP-Adresse des Ziel-Hosts dar. Ist die Migration erfolgreich, wird die Quell-Instanz eingefroren und es kann mit der Instanz auf dem Ziel-Host gearbeitet werden.

[bearbeiten] Test auf einem Host-System

Die Live-Migration kann auch auf einem Host getestet werden. Dazu wird in einer Konsole eine Instanz gestartet.

Host $ qemu Platte.img

Auf einer zweiten Konsole wird eine zweite Instanz mit der zusätzlichen Option -incoming tcp:0:1234 aufgerufen. Dadurch wartet diese Instanz auf dem Port 1234 auf eine Migration.

Host $ qemu Platte.img -incoming tcp:0:1234 

Auf der ersten Instanz wechselt man zum QEMU-Monitor und gibt dort den folgenden Befehl ein. Die Option -d lässt die Migration im Hintergrund laufen und gibt den Prompt des QEMU-Monitors wieder frei.

(qemu) migrate -d tcp:localhost:1234

Nach einigen Sekunden hat die virtuelle Maschine die Instanzen gewechselt. Informationen über den Status der Migration zeigt der Befehl info migrate an.

(qemu) info migrate

Der Befehl migrate_cancel bricht die aktuelle Migration ab.

(qemu) migrate_cancel

Der Befehl migrate_set_speed value begrenzt die maximale Geschwindigkeit der Migration in Byte.

(qemu) migrate_set_speed 1g

Der Befehl migrate_set_downtime second definiert die maximal zu tolerierende Downtime bei der Migration in Sekunden. In diesem Beispiel darf die Instanz maximal 2 Sekunden nicht erreichbar sein.

(qemu) migrate_set_downtime 2

[bearbeiten] Beispiel Live-CD

Die Voraussetzung, dass Quell- und Ziel-Host Zugriff auf das bitgenau gleiche Image haben müssen, trifft bei Live-CD/DVDs zu. Dabei ist ein gemeinsames Storage nicht notwendig. Es muss jeweils eine Kopie der Live-CD/DVD auf dem Quell- und Ziel-Host vorhanden sein. Für bestimmte Anwendungen ist der Einsatz einer angepassten Live-CD/DVD als virtuelle Maschine sinnvoll. Dazu wird auf dem Quell-Host die Live-CD/DVD gestartet.

Quell-Host $ qemu -cdrom live-cd.iso -boot d 

Auf dem Ziel-Host wird die Instanz mit der zusätzlichen Option -incoming tcp:0:1234 aufgerufen.

Ziel-Host $ qemu -cdrom live-cd -boot d -incoming tcp:0:1234

Im QEMU-Monitor der Quell-Instanz ist der Befehl migrate mit der IP-Adresse oder dem Hostnamen des Ziel-Hosts und dem Port anzuwenden.

(qemu) migrate -d tcp:zielhost:1234

[bearbeiten] Beispiel NBD-Storage

Mit dem Tool qemu-nbd lässt sich ein Image als Network Block Device im Netzwerk zur Verfügung stellen. Auf dem Rechner mit dem Image ist qemu-nbd zu starten. Die Option --shared=num ermöglicht, dass mehrere Instanzen auf ein Network Block Device zugreifen können. Die maximale Anzahl definiert der Wert num (Default = 1).

Storage-Host ~$ qemu-nbd -t -p 1025 --share=2 Platte.img

Auf dem Quell-Host wird die Instanz mit dem Zugriff auf das Network Block Device gestartet.

Quell-Host ~$ qemu -hda nbd:storagehost:1025

Auf dem Ziel-Host wird beim Start der Instanz zusätzlich die Option -incoming angegeben.

Ziel-Host ~$ qemu -hda nbd:storagehost:1025 -incoming tcp:0:1234

Im QEMU-Monitor der Quell-Instanz ist der Befehl migrate mit der IP-Adresse oder dem Hostnamen des Ziel-Hosts und dem Port anzuwenden.

(qemu) migrate -d tcp:zielhost:1234

[bearbeiten] Kopieren der virtuellen Festplatten bei der Migration

Die Option -b aktiviert das Kopieren der virtuellen Festplatten zu dem Ziel-Host. Dies ist sinnvoll wenn das Image nicht auf einen gemeinsamen Storage (Shared Storage) liegt. Mit der Option -i erfolgt nur ein Kopieren der Overlay-Dateien. Dies ist sinnvoll wenn gleiche Basis-Images auf Quell- und Ziel-Host zur Verfügung stehen. Auf dem Ziel-Host wird ein leeres Image mit mindestens dem gleichen Fassungsvermögen wie das Image auf dem Quell-Host angelegt.

Ziel-Host ~$ qemu-img create Platte.img 1G

QEMU wird mit diesem leeren Image und der Option -incoming gestartet.

Ziel-Host ~$ qemu -hda Platte.img -incoming tcp:0:1234

Auf dem Quell-Host startet man QEMU mit dem zu kopierenden Image.

Quell-Host ~$ qemu Platte.img

Im QEMU-Monitor der Quell-Instanz startet man die Live-Migration und das Kopieren des Images.

(qemu) migrate -b tcp:zielhost:1234

[bearbeiten] Debug- und Experten-Optionen

[bearbeiten] Umleitung des QEMU-Monitors

Bei der Default-Einstellung wird der QEMU-Monitor auf der zweiten Konsole der Instanz betrieben. Die Tastenkombination [Strg]+[Alt]+[2] schaltet auf diese Konsole um. Diese Default-Einstellung entspricht der Startoption -monitor vc.

Host ~$ qemu-system-x86_64 Platte.img -monitor vc

Der QEMU-Monitor wird mit der Option -monitor und der nachfolgenden Angabe eines Ziel-Devices umgeleitet. Er erscheint dann nicht mehr auf der zweiten Konsole. In diesem Beispiel wird unter Linux der QEMU-Monitor auf stdio umgeleitet (stdio steht für die Standardein- und -ausgabe des Host-Systems). Das heißt, der QEMU-Monitor wird auf die Konsole des Host-Systems umgeleitet.

Host ~$ qemu-system-x86_64 Platte.img -monitor stdio
(qemu) 

Es ist möglich den QEMU-Monitor auf ein Port des Host-Systems umzuleiten. In diesem Beispiel wird der QEMU-Monitor auf Port 4444 des Host-Systems als Telnet-Protokoll angeboten. Der Parameter nowait bewirkt, dass die Instanz auch ohne eine Telnet-Verbindung startet.

Host ~$ qemu-system-x86_64 Platte.img -monitor tcp::4444,server,nowait 

Mit einem Telnet-Client verbindet man sich zu dem Port 4444 des Host-Systems.

Host ~$ telnet localhost 4444
Escape character is '^]'.
(qemu) 

Die Umleitung kann auch per Character-Device erfolgen.

Host ~$ qemu-system-x86_64 Platte.img -chardev stdio,id=meinmonitor -mon chardev=meinmonitor

[bearbeiten] Umleitung der seriellen Schnittstelle

Bei der Default-Einstellung wird die virtuelle serielle Schnittstelle auf der dritten Konsole betrieben. Die Tastenkombination [Strg]+[Alt]+[3] schaltet auf diese Konsole um. Die Default-Einstellung entspricht der QEMU-Startoption -serial vc.

Host ~$ qemu-system-x86_64 Platte.img -serial vc

Die Ausgabe der virtuellen seriellen Schnittstelle wird mit der Option -serial und der nachfolgenden Angabe eines Ziel-Devices umgeleitet. Sie erscheint dann nicht mehr auf der dritten Konsole. In diesem Beispiel wird unter Linux die serielle Schnittstelle des Gast-Systems auf die erste serielle Schnittstelle des Host-Systems umgeleitet.

Host ~$ qemu-system-x86_64 Platte.img -serial /dev/ttyS0

Unter Microsoft Windows als Host-System wird die erste serielle Schnittstelle mit COM1 bezeichnet.

Host C:\> qemu-system-x86_64 Platte.img -serial COM1

Zur Umleitung in eine Datei dient der Parameter file: gefolgt von einem Dateinamen.

Host ~$ qemu-system-x86_64 Platte.img -serial file:Seriell.log

Deaktiviert wird die virtuelle serielle Schnittstelle mit -serial none.

Host ~$ qemu-system-x86_64 Platte.img -serial none

Die Option -serial kann bis zu vier mal angegeben werden. Weitere Konfigurationsmöglichkeiten der serielle Schnittstelle werden im Anhang aufgelistet.

[bearbeiten] Umleitung der parallelen Schnittstelle

Bei der Default-Einstellung wird die virtuelle parallele Schnittstelle auf die vierte Konsole gelegt. Die Tastenkombination [Strg]+[Alt]+[4] schaltet auf diese Konsole um. Die Default-Einstellung entspricht der QEMU-Startoption -parallel vc.

Host ~$ qemu-system-x86_64 Platte.img -parallel vc

Die Ausgabe der virtuellen parallelen Schnittstelle wird mit der Option -parallel und der nachfolgenden Angabe eines Ziel-Devices umgeleitet. Sie erscheint dann nicht mehr auf der vierten Konsole. In diesem Beispiel wird unter Linux die parallele Schnittstelle des Gast-Systems auf die zweite serielle Schnittstelle des Host-Systems umgeleitet.

Host ~$ qemu-system-x86_64 Platte.img -parallel /dev/ttyS1

Unter Microsoft Windows wird die zweite serielle Schnittstelle mit COM2 bezeichnet.

Host C:\> qemu-system-x86_64 Platte.img -parallel COM2

Zur Umleitung in eine Datei dient der Parameter file: gefolgt von einem Dateinamen.

Host ~$ qemu-system-x86_64 Platte.img -parallel file:Parallel.log

Unter Linux als Host-System können die parallelen Schnittstellen /dev/parport0 bis /dev/parport2 direkt angesprochen werden. Ihnen müssen für den Account, unter dessen Rechten QEMU beziehungsweise die Kernel-based Virtual Machine läuft, Lese- und Schreibrechte zugewiesen werden. Hier das Beispiel für das Device /dev/parport0:

Host ~$ sudo chmod o+rw /dev/parport0

QEMU oder die Kernel-based Virtual Machine wird mit der Option -parallel /dev/parport0 gestartet.

Host ~$ qemu-system-x86_64 Platte.img -rtc base=localtime -parallel /dev/parport0

Im Gast-System kann damit ein am Parallelport des Hosts angeschlossener Drucker verwendet werden. Deaktiviert wird die virtuelle parallele Schnittstelle mit -parallel none.

Host ~$ qemu-system-x86_64 Platte.img -parallel none

Die Option -parallel kann bis zu drei mal angegeben werden.

[bearbeiten] Das QEMU Monitor Protocol (QMP)

Das QEMU Monitor Protocol (siehe http://wiki.qemu.org/QMP) ist ein auf JASON (http://www.json.org) basierendes Management Interface, welches Applikationen die Kommunikation mit der QEMU-Instanz ermöglicht. JASON (JavaScript Object Notation) ist ein Datenformat in einer für Maschinen einfach zu lesenden Textform. Das heißt, die Kommunikation mit dem QEMU-Monitor erfolgt über JavaScript-Dokumente. Mit der Option -qmp erfolgt die Umleitung auf ein Device. In diesem Beispiel wird QMP auf auf die Konsole des Host-Systems umgeleitet. Es erscheint der QMP-Begrüßungstext. Mit { "execute": "query-commands" } listet man die QMP-Befehle auf.

Host ~$ qemu-system-x86_64 Platte.img -qmp stdio
{"QMP": {"version": {"qemu": {"micro": 0, "minor": 15, "major": 0}, "package": ""}, "capabilities": []}}
{ "execute": "query-commands" }
{"return": [{"name": "quit"}, {"name": "eject"}, {"name": "change"}, {"name": "screendump"}, 
{"name": "stop"}, {"name": "cont"}, {"name": "system_reset"}, {"name": "system_powerdown"}, 
{"name": "device_add"}, {"name": "device_del"}, {"name": "cpu"}, {"name": "memsave"}, 
{"name": "pmemsave"}, {"name": "inject-nmi"}, {"name": "migrate"}, {"name": "migrate_cancel"}, 
{"name": "migrate_set_speed"}, {"name": "migrate_set_downtime"}, {"name": "client_migrate_info"}, 
{"name": "netdev_add"}, {"name": "netdev_del"}, {"name": "block_resize"}, 
{"name": "blockdev-snapshot-sync"}, {"name": "balloon"}, {"name": "set_link"}, {"name": "getfd"}, 
{"name": "closefd"}, {"name": "block_passwd"}, {"name": "set_password"}, {"name": "expire_password"}, 
{"name": "add_client"}, {"name": "qmp_capabilities"}, {"name": "human-monitor-command"}, 
{"name": "query-version"}, {"name": "query-commands"}, {"name": "query-chardev"}, {"name": "query-block"}, 
{"name": "query-blockstats"}, {"name": "query-cpus"}, {"name": "query-pci"}, {"name": "query-kvm"}, 
{"name": "query-status"}, {"name": "query-mice"}, {"name": "query-vnc"}, {"name": "query-name"}, 
{"name": "query-uuid"}, {"name": "query-migrate"}, {"name": "query-balloon"}]}

In diesem Beispiel wird QMP auf Port 4444 des Host-Systems als Telnet-Protokoll angeboten.

Host ~$ qemu-system-x86_64 Platte.img -qmp tcp:localhost:4444,server
QEMU waiting for connection on: tcp:127.0.0.1:4444,server

Mit einem Telnet-Client verbindet man sich zu dem Port 4444 des Host-Systems.

Host ~$ telnet 127.0.0.1 4444
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
{"QMP": {"version": {"qemu": {"micro": 0, "minor": 15, "major": 0}, "package": ""}, "capabilities": []}}

[bearbeiten] Logging

Die Option -d aktiviert das Schreiben von Log-Daten in die Datei /tmp/qemu.log. Diese Option verlangsamt QEMU. Die möglichen Log-Items listet -d ? auf.

Host ~$ qemu-system-x86_64 -d ?
Log items (comma separated):
out_asm   show generated host assembly code for each compiled TB
in_asm    show target assembly code for each compiled TB
op        show micro ops for each compiled TB
op_opt    show micro ops 
int       show interrupts/exceptions in short format
exec      show trace before each executed TB (lots of logs)
cpu       show CPU state before block translation
pcall     show protected mode far calls/returns/exceptions
cpu_reset show CPU state before CPU resets
     out_asm
Zeigt den generierten Host-Assemler-Code für jeden kompilierten Translation-Block (TB) an.
     in_asm
Zeigt den Ziel-Assemler-Code für jeden kompilierten Translation-Block an.
     op
Zeigt Micro-OPs für jeden kompilierten Translation-Block an.
     op_opt
Zeigt die Mikro-Operationen (micro operations) vor der EFLAGS-Optimierung und nach der Liveness Analysis an.
     int
Zeigt Interrupts/Exceptions in einem kurzen Format an.
     exec
Zeigt das Trace vor jedem ausgeführten Translation-Block an. Die Ausgaben sind sehr umfangreich.
     cpu
Zeigt den CPU-Status vor jeder Block-Translation an.
     pcall
Zeigt Protected-Mode-Far-Calls/-Returns/-Exceptions an.
     cpu_reset
Zeigt den CPU-Status vor den CPU-Resets an.

Mehrere Einträge werden mit Kommas getrennt.

Host ~$ qemu-system-x86_64 -d int,cpu

Mit dem Befehl tail lassen sich die Log-Daten anzeigen.

Host ~$ tail -f /tmp/qemu.log

Mit der Option -D ist es möglich eine Log-Datei vorzugeben.

Host ~$ qemu-system-x86_64 -D ./qemu.log -d int,cpu 

[bearbeiten] Tracing

Beim Tracing (Ablaufvervolgung) wird die Ausführung von Programmen protokolliert, um sie zu debuggen. QEMU unterstützt das Tracing, wenn es mit der entsprechenden Option --trace-backend kompiliert wurde (siehe Abschnitt Installation). Mit der Default-Einstellung --trace-backend=nop ist das Tracing deaktiviert. Bei --trace-backend=stderr werden die Trace-Events direkt auf die Standard-Fehlerausgabe (standard error) ausgegeben. Das Dynamic Tracing (DTrace) wird mit --trace-backend=dtrace aktiviert. Wird QEMU mit der Option --trace-backend=ust kompiliert, steht der LTTng Userspace Tracer (UST) zur Verfügung. Für die nachfolgenden Beispiele wurde QEMU mit der Option --trace-backend=simple kompiliert. Dieses einfache Tracing reicht für viele Anforderungen. Für das Tracing sind bestimmte Trace-Events auswählbar. Im Quellcode von QEMU werden die Trace-Events in der Datei trace-events deklariert. Die folgenden Beispiele verwenden den Quell-Code von QEMU 1.0 im Verzeichnis ~/source/qemu-1.0.

Host ~$ less ~/source/qemu-1.0/trace-events

Im QEMU-Monitor informiert der Befehl info trace-events über die deklarierten Trace-Events.

(qemu) info trace-events

Zum Aufzeichnen bestimmter Trac-Events, müssen diese in einer Text-Datei aufgelistet werden.

Host ~$ echo cpu_out > /tmp/events.txt
Host ~$ echo cpu_in >> /tmp/events.txt

Mit der QEMU-Option -trace wird das Tracing aktiviert. Dabei ist mit events auf die Text-Datei mit den Trace-Events zu verweisen. Die Trace-Datei wird mit file angegeben.

Host ~$ qemu-system-x86_64 Platte.img \
-trace events=/tmp/events.txt,file=/tmp/trace.log

Mit dem QEMU-Monitor-Befehl info trace wird der Inhalt des Trace-Puffers angezeigt.

(qemu) info trace

Es lassen sich nachträglich Trace-Events (de-)aktivieren.

(qemu) trace-event cpu_in off

Es sind Wildcards anwendbar.

(qemu) trace-event cpu_* on

Im QEMU-Monitor wird mit dem Befehl trace-file das Schreiben der Trace-Datei gesteuert. Ohne Argumente wird angezeigt, ob in die Trace-Datei geschrieben wird. Mit trace-file off wird das Schreiben unterbunden.

(qemu) trace-file off
(qemu) trace-file
Trace file "/tmp/trace.log" off.
(qemu) trace-file on
(qemu) trace-file
Trace file "/tmp/trace.log" on.

Mit trace-file set wird eine andere Trace-Datei vorgegeben.

(qemu) trace-file set /tmp/trace2.log
(qemu) trace-file
Trace file "/tmp/trace2.log" on.

Zum Anzeigen der Tracing-Datei dient das Script simpletrace.py aus dem Quell-Code von QEMU.

Host ~$ ~/source/qemu-1.0/scripts/simpletrace.py      \
        ~/source/qemu-1.0/trace-events /tmp/trace.log  
cpu_out 14934.160 addr=0x20 val=0x60
cpu_out 15012.523 addr=0x20 val=0x60
...

[bearbeiten] Kommunikation mit dem Debugger GDB

Der gebräuchlichste Debugger in der Open Source-Welt ist der GDB (GNU Debugger). Mit ihm lassen sich Programme, die mit den unterschiedlichsten Programmiersprachen geschrieben wurden, testen. Der Aufruf erfolgt mit dem zu testenden Programm und weiteren Argumenten. GDB ist in der Lage remote auf Programme und Prozesse zuzugreifen. Neben den historisch gern dafür genutzten seriellen Schnittstellen kann dies über eine TCP/IP-Verbindung geschehen. Dazu ist auf dem Remote-System das Programm gdbserver zu starten. In QEMU ist der dazu nötige gdbserver integriert. Aktiviert wird er mit der Option -gdb tcp::1234.

Host ~$ qemu-system-x86_64 Platte.img -gdb tcp::1234

Wurde die Option -s nicht angegeben, wird der gdbserver im QEMU-Monitor aktiviert.

(qemu) gdbserver

Optional kann ein anderer Port definiert werden.

(qemu) gdbserver 4321

Den Debugger GDB ruft man wie gewohnt auf dem Host-Rechner auf.

Host ~$ gdb
(gdb)

Im GDB erfolgt anschließend die Verbindung zum Remote-System. Der Standard-Port für Remote-Debugging ist 1234. In diesem Beispiel befinden sich GDB und QEMU auf der gleichen Maschine.

(gdb) target remote localhost:1234
Remote debugging using localhost:1234
0x0000f858 in ?? ()

Wurde der gdbserver aktiviert, wird das Gast-System angehalten und die Steuerung erfolgt vom Debugger aus. Der Befehl c (continue) weckt das Gast-System.

(gdb) c
Continuing.
^C
Program received signal SIGINT, Interrupt.
0x8060985d in ?? ()

Es lässt sich eine QEMU-Instanz im Debugger GDB starten und steuern. Mit der Option -gdb dev erwartet die Instanz auf eine GDB-Verbindung auf dem Device dev. Typische Verbindungen basieren dabei auf TCP. Möglich sind aber auch UDP, Pseudo-TCP und stdio. Im folgenden Beispiel wird eine QEMU-Instanz im GDB gestartet und gesteuert.

Host ~$ gdb
(gdb) target remote | exec qemu Platte.img -gdb stdio
Remote debugging using | exec qemu Platte.img -gdb stdio
[New Thread 1]
0x0000fff0 in ?? ()
(gdb) help
...
(gdb) c
Continuing.
^C
Program received signal SIGINT, Interrupt.
0x800c7058 in ?? ()
(gdb) stop
(gdb) quit
The program is running.  Exit anyway? (y or n) y

Systeme, die ohne Debug-Informationen kompiliert sind, lassen sich nur schwer testen. Es stehen keine Informationen zum Programm-Status zur Verfügung. Man sieht zwar den Inhalt der Prozessorregister, ohne Informationen über das Programm nützt das nicht viel. Liegen allerdings speziell fürs Debuggen vorbereitete Systeme nebst Quelltexten vor, hat man ein mächtiges Werkzeug zur Hand.

[bearbeiten] Pause, Singlestep

Die Option -S friert die CPU(s) beim Start der Instanz ein.

Host ~$ qemu-system-x86_64 Platte.img -S

Im QEMU-Monitor informiert der Befehl info status über den Status.

(qemu) info status
VM status: paused

Geweckt wird die Instanz mit den Befehlen c oder cont.

(qemu) cont
(qemu) info status
VM status: running

Der Befehl stop lässt die Instanz wieder pausieren.

(qemu) stop

Mit der Option -singlestep wird die Instanz zum Debuggen im Singlestep-Modus gestartet.

Host ~$ qemu-system-x86_64 Platte.img -singlestep

Im QEMU-Monitor informiert der Befehl info status ob der Singlestep-Modus aktiviert ist oder nicht.

(qemu) info status
VM status: running (single step mode)

Im QEMU-Monitor wird mit dem Befehl singlestep [on|off] der Singlestep-Modus während der Laufzeit der Instanz (de-)aktiviert. In diesem Beispiel wird der Singlestep-Modus deaktiviert.

(qemu) singlestep off

[bearbeiten] Watchdog

Ein Watchdog (Wachhund) dient zur Überwachung eines Systems. Bei erkannten Fehlfunktionen wird eine bestimmte Aktion ausgelöst. Meist kommt ein Hardware-Watchdog zum Einsatz. Wird im Gast-System ein Agent für den Watchdog aktiviert, muss der Agent periodisch Anfragen an den Watchdog stellen. Bleiben diese Anfragen aus, so führt der Watchdog eine vorgegebene Aktion aus. Mit der Option -watchdog model wird ein virtueller Hardware-Watchdog aktiviert. Mit dem Parameter model wählt man das zu emulierende Model. Die verfügbaren Modelle listet -watchdog ? auf. Die Auswahl richtet sich nach der Unterstützung des Modells durch das Gast-System.

Host ~$ qemu-system-x86_64 -watchdog ?
        i6300esb    Intel 6300ESB
        ib700       iBASE 700

Im folgenden Beispiel wird die Watchdog-Hardware iBASE 700 emuliert.

Host ~$ qemu-system-x86_64 Platte -watchdog ib700

Wenn der Watchdog-Timer Alarm schlägt, wird per Default ein Reset ausgelöst. Mit der Option -watchdog-action passt man die Aktion an. Mögliche Aktionen sind reset (Default), shutdown (ordnungsgemäßes Herunterfahren), poweroff, pause, debug (Ausgabe einer Debug-Meldung) oder none (keine Aktion). Im folgenden Beispiel wird die Aktion debug vorgegeben.

Host ~$ qemu-system-x86_64 Platte -watchdog ib700 -watchdog-action debug

Die Aktion wird im QEMU-Monitor mit dem Befehl watchdog_action geändert.

(qemu) watchdog_action none

[bearbeiten] Fehlerinjektion

QEMU unterstützt das Simulieren von Hardware-Fehlern. Im QEMU-Monitor injiziert der Befehl nmi einen Non-Maskable Interrupt (NMI) für alle CPUs. Ein NMI ist ein Interrupt, der vom System nicht ignoriert werden kann. NMI arbeiten meist sehr fundamentale und kritische Routinen ab.

(qemu) nmi

Im QEMU-Monitor injiziert der Befehl mce eine Machine Check Exception (MCE). Eine Machine Check Exception ist ein Report von neueren CPU(s) von Intel und AMD bei Hardware-Problemen. Für das Beispiel emuliert man zwei 64-Bit-CPUs vom Typ AMD Phenom.

Host ~$ qemu-system-x86_64 Platte.img -snapshot \
-cpu phenom -smp 2 -monitor stdio 

Ist das Gast-System Linux, so lässt sich mit folgenden Befehlen die Unterstützung von MCE testen.

Gast ~$ grep -i mce /proc/kallsyms
Gast ~$ ls -l /dev/mcelog

Ist das Device /dev/mcelog nicht vorhanden, legt man es mit mknod an.

Gast ~$ mknod /dev/mcelog c 10 227

Im QEMU-Monitor wird eine MCE injiziert.

(qemu) mce 0 4 0xbe0000001008081f 0x00 0x00 0x00

Die Syntax von mce ist:

(qemu) mce cpu bank status mcgstatus addr misc

Die MCE wird für die angegebene CPU (cpu) injiziert. Wird nur eine CPU emuliert ist hier 0 anzugeben. Jeder CPU sind vier oder fünf Bänke (bank) zugeordnet. Eine Bank ist eine Gruppe von Fehler-Registern. Diese Fehler-Register können jeweils aktiviert oder deaktiviert sein. Normalerweise sind alle Fehler-Register aller Bänke aktiviert. Die Anzahl und Inhalte der Bänke sind abhängig von der CPU. Jede Bank hat vier Register. Bei einer AMD-CPU haben die Bänke folgende Bedeutung:
Bank 0: Date Cache,
Bank 1: Instruction Cache,
Bank 2: Bus Unit,
Bank 3: Load Store Unit,
Bank 4: Northbridge und DRAM.

Mit status wird das Bank-Status-Register (64-Bit) gesetzt.

Das globale Status-Register (mcgstatus) enthält Informationen ob ein MCE gemeldet wurde.
Bit 0: RIPV – Restart IP valid flag,
Bit 1: EIPV – Error IP valid flag,
Bit 2: MCIP – Machine check in progress,
Bit 3 bis 63: Reserviert.

Mit addr wird die Speicheraddresse der Exception definiert. Zur zusätzlichen Beschreibung der MCE dient misc.

Mit dem Befehl pcie_aer_inject_error wird ein PCI AER-Fehler (PCI Express Advanced Error Reporting) injiziert.

(qemu) pcie_aer_inject_error 0:0:4.0 0x10
msi_notify:295 pcie-root-port:20 notify vector 0x0

[bearbeiten] Spezielle Linux-Bootoptionen

Mit Hilfe spezieller Linux-Bootoptionen wird ein Kernel geladen, ohne dass er auf einer virtuellen Festplatte installiert sein muss. Der Kernel kann entweder ein Linux-Kernel oder ein Multiboot-Kernel sein. Nützlich ist dies zum Beispiel für den Test eines kompilierten Kernels. Auch sind diese Optionen bei der Emulation fremder Prozessor-Architekturen notwendig, da diese andere Boot-Methoden nutzen.

Host ~$ qemu-system-x86_64 -kernel vmlinuz -initrd initrd.gz -append "..."

Die Startoption -kernel gibt den zu bootenden Kernel an, -initrd erlaubt das Einbeziehen einer initialen RAM-Disk. Eine Initial Ramdisk (initrd) ist ein temporäres Dateisystem, dass vom Kernel während des Bootvorgangs verwendet wird. Es enthält das Abbild eines Dateisystems mit den zum Start des Systems benötigten Dateien und wird vom Linuxkernel oder anderen, mit Unix verwandten Betriebssystemen, beim Booten als Stammverzeichnis eingehängt. Bei eingebetteten Systemen kann die ganze Funktionalität des Systems in der initrd enthalten sein. Bei einem Multiboot-Kernel werden hinter -initrd Kernel-Module und deren Parameter übergeben. Kernel-Bootoptionen definiert man mit -append. Als Beispiel dient hier das Booten eines Systems von einer virtuellen Festplatte, die mit dem Skript qemu-make-debian-root erzeugt wurde. Dieses Skript legt eine virtuelle Festplatte an und installiert die Pakete für ein auf Debian basierendes System. Ein Kernel wird aber nicht generiert. Das Skript qemu-make-debian-root gehört bei Debian-Distributionen, wie zum Beispiel Ubuntu, zum Paket qemu. Es benötigt die Pakete debootstrap und sharutils.

Host ~$ sudo apt-get install debootstrap sharutils qemu 

Beim Aufruf des Skripts qemu-make-debian-root gibt man die Größe der virtuellen Festplatte in MByte, die zu installierende Debian- beziehungsweise Ubuntu-Version, die Download-URL und den Namen der anzulegenden virtuellen Festplatte an. Zur Ausführung dieses Skripts werden root-Rechte benötigt. Um zu vermeiden, dass das Image dem Benutzer root gehört, legt man die virtuelle Festplatte bereits vorher mit dem Befehl touch als normaler Benutzer an.

Host ~$ touch Platte.img
Host ~$ sudo qemu-make-debian-root 500 sid  \
        http://ftp.debian.org/debian Platte.img

Wie schon beschrieben, fehlt ein Kernel auf dieser virtuellen Festplatte. Man lädt einen passenden Kernel und die entsprechende Initial Ramdisk herunter, zum Beispiel von ftp://ftp.debian.org/debian/dists/sid/main/installer-i386/current/images/hd-media/. Mit folgenden Optionen wird die Instanz gestartet.

Host ~$ qemu-system-x86_64 Platte.img -kernel vmlinuz \
        -initrd initrd.gz -append "root=/dev/ram"

[bearbeiten] Userspace-Emulation

Im Gegensatz zum Kernelspace, der nur für die Ausführung des Kernels, dessen Erweiterungen und für Treiber reserviert ist, laufen im Userspace alle User-Anwendungen. Mit der Userspace-Emulation lässt sich im Userspace Software starten, die eigentlich im Kernelspace läuft. Dies ist nützlich für die Entwicklung derartiger Software. Wenn diese Software direkt im Kernelspace getestet wird, ist die Stabilität des Systems gefährdet. Bei der Userspace-Emulation, die für Linux, Mac OS X/Darwin und BSD zur Verfügung steht, wird kein vollständiger PC emuliert, sondern es wird die Verwendung von anderen dynamischen Bibliotheken unterstützt. Dadurch können Programme gestartet werden, die eigentlich für Bibliotheken anderer Architekturen kompiliert wurden. So können Entwickler Software für andere Architekturen programmieren und testen. Da die Userspace-Emulation von QEMU die gestarteten Prozesse nicht abschottet ist, ist diese Emulation keine Virtualisierung. Im Userspace können x86, PowerPC, ARM, 32-bit MIPS, Sparc32/64, ColdFire(m68k), CRISv32 und MicroBlaze CPUs emuliert werden.

[bearbeiten] Unter Linux

Zum besseren Verständnis der Userspace-Emulation ist ein Programm hilfreich, das Informationen über das verwendete System ausgibt. Unter Unix/Linux dient dazu der Befehl uname. Gibt man den Befehl uname -a in der Kommandozeile ein, so erhält man in diesem Beispiel den Kernelnamen (Linux), den Hostnamen (knut), die Kernelversion (2.6), das Erstellungsdatum des Kernels (#1 SMP Thu Oct 30 04:57:35 UTC 2008), die Architektur (i686) und das Betriebssystem (GNU/Linux).

Host ~$ uname -a
Linux knut 2.6 #1 SMP Thu Oct 30 04:57:35 UTC 2008 i686 GNU/Linux

Im QEMU-Paket enthalten ist der Userspace-Emulator qemu-i386 für die x86-Architektur. Mit der Option -L wird der Suchpfad zu den dynamischen Bibliotheken definiert. Wird zum Beispiel als Suchpfad das Wurzelverzeichnis angegeben, werden die nativen Bibliotheken des Host-Betriebssystems verwendet. Die zweite Option definiert den Pfad zu dem auszuführenden Programm. In dem folgenden Beispiel wird der Befehl uname des Host-Systems im Userspace-Emulator mit den nativen Bibliotheken des Host-Betriebssystems aufgerufen.

Host ~$ qemu-i386 -L / /bin/uname -a
Linux knut 2.6 #1 SMP Thu Oct 30 04:57:35 UTC 2008 i686 GNU/Linux

Da sowohl die Bibliotheken als auch das Binary vom Host-System verwendet werden, gibt hier uname die gleichen Informationen aus, als wenn es direkt aufgerufen wird. Zur anschaulichen Demonstration der Userspace-Emulation benötigt man Beispiele von Bibliotheken und Binaries für diverse Architekturen. Diese können von der QEMU-Website http://wiki.qemu.org/Download unter dem Punkt QEMU Linux user mode emulation tests heruntergeladen werden. Man entpackt dieses tar-Archiv und wechselt in das angelegte Verzeichnis.

Host ~$ wget http://wiki.qemu.org/download/linux-user-test-0.3.tar.gz
Host ~$ tar xzvf linux-user-test-0.3.tar.gz
Host ~$ cd linux-user-test-0.3

Im Unterverzeichnis gnemul befinden sich die Bibliotheken unterschiedlicher Architekturen. Die Binärdateien dieser Architekturen befinden sich in weiteren Unterverzeichnissen. So stehen Versionen des Befehls uname für mehrere Architekturen zur Verfügung.

Host ~$ ls */uname
alpha/uname  arm/uname  hppa/uname   m68k/uname   mipsel/uname  
mips/uname   ppc/uname  sh4eb/uname  sparc/uname  x86_64/uname

Mit dem Befehl file überprüft man, ob es sich wirklich um die Binaries für andere Architekturen handelt. In diesem Beispiel wird der Befehl uname der ARM-Architektur untersucht.

Host ~$ file arm/uname
arm/uname: ELF 32-bit LSB executable, ARM, version 1 (ARM), 
for GNU/Linux 2.2.0, dynamically linked (uses shared libs), 
for GNU/Linux 2.2.0, stripped

Dieses Binary der ARM-Architektur lässt sich nicht in einer x86-Architektur ausführen.

Host ~$ arm/uname -a
bash: arm/uname: cannot execute binary file

Zur Ausführung dieser Binaries benötigt man den entsprechenden Userspace-Emulator und die Bibliotheken für die jeweilige Architektur. Interessant ist dabei welche Informationen bei den unterschiedlichen Architekturen jeweils der Befehl uname anzeigt. Für die Userspace-Emulation der ARM-Architektur wird das Programm qemu-arm benötigt. Mit der Option -L wird der Pfad zu den Bibliotheken der ARM-Architektur konfiguriert. Anschließend wird das gewünschte Binary im Unterverzeichnis arm aufgerufen.

Host ~$ qemu-arm -L gnemul/qemu-arm/ arm/uname -a
Linux knut 2.6 #1 SMP Thu Oct 30 04:57:35 UTC 2008 armv5tel unknown

Betrachtet man die Informationen, die der Befehl uname anzeigt, so fällt folgendes auf:

Es wird bei gleichem Kernel eine andere Architektur emuliert. Der Userspace-Emulator qemu-arm ermöglicht es, unter Verwendung der angegebenen Bibliotheken, die Ausführung des Befehls arm/uname, obwohl dieses für die ARM-Prozessorarchitektur kompiliert wurde. Die Userspace-Emulation ist keine Virtualisierung, da die gestarteten Prozesse nicht vom Host-System isoliert werden. Zum Beispiel ist es möglich, mit dem Befehl dd der ARM-Architektur im Userspace-Emulator eine CD zu importieren.

Host ~$ qemu-arm -L gnemul/qemu-arm/ arm/dd if=/dev/cdrom of=cd.iso

Für die Userspace-Emulation der x86-Architektur sind die Programme qemu-i386 (32-Bit) oder qemu-x86_64 (64-Bit) notwendig. Es sind die jeweiligen x86-Bibliotheken und die x86-Binaries anzugeben.

Host ~$ qemu-i386   -L gnemul/qemu-i386/   i386/ls
Host ~$ qemu-x86_64 -L gnemul/qemu-x86_64/ x86_64/uname -a
Linux knut 2.6 #1 SMP Thu Oct 30 04:57:35 UTC 2008 x86_64 unknown

Für die Userspace-Emulation der SPARC-Architektur sind die Programme qemu-sparc (32-Bit), qemu-sparc32plus oder qemu-sparc64 (64-Bit) notwendig.

Host ~$ qemu-sparc       -L gnemul/qemu-sparc/ sparc/uname -a
Linux knut 2.6 #1 SMP Thu Oct 30 04:57:35 UTC 2008 sun4 unknown
Host ~$ qemu-sparc32plus -L gnemul/qemu-sparc/ sparc/uname -a
Linux knut 2.6 #1 SMP Thu Oct 30 04:57:35 UTC 2008 sun4 unknown
Host ~$ qemu-sparc64     -L gnemul/qemu-sparc/ sparc64/ls

Für die Userspace-Emulation der ARM-Architektur sind die Programme qemu-arm oder qemu-armeb anzuwenden.

Host ~$ qemu-arm   -L gnemul/qemu-arm/   arm/uname -a
Linux knut 2.6 #1 SMP Thu Oct 30 04:57:35 UTC 2008 armv5tel unknown
Host ~$ qemu-armeb -L gnemul/qemu-armeb/ armeb/ls

Für die Userspace-Emulation der MIPS-Architektur sind die Programme qemu-mips und qemu-mipsel zuständig.

Host ~$ qemu-mips   -L gnemul/qemu-mips     mips/uname -a
Linux knut 2.6 #1 SMP Thu Oct 30 04:57:35 UTC 2008 mips unknown
Host ~$ qemu-mipsel -L gnemul/qemu-mipsel/  mipsel/uname -a
Linux knut 2.6 #1 SMP Thu Oct 30 04:57:35 UTC 2008 mips unknown

Für die Userspace-Emulation der Coldfire-Prozessorarchitektur wird das Programm qemu-m68k benötigt.

Host ~$ qemu-m68k -L gnemul/qemu-m68k/ m68k/uname -a

Für die Userspace-Emulation der PPC-Architektur sind die Programme qemu-ppc, qemu-ppc64abi32 oder qemu-ppc64 zu verwenden.

Host ~$ qemu-ppc        -L gnemul/qemu-ppc/   ppc/uname -a
Linux knut 2.6 #1 SMP Thu Oct 30 04:57:35 UTC 2008 ppc unknown
Host ~$ qemu-ppc64abi32 -L gnemul/qemu-ppc/   ppc/uname -a
Linux knut 2.6 #1 SMP Thu Oct 30 04:57:35 UTC 2008 ppc unknown
Host ~$ qemu-ppc64      -L gnemul/qemu-ppc64/ ppc64/ls

Für die Userspace-Emulation der Alpha-Prozessorarchitektur ist das Programm qemu-alpha zuständig.

Host ~$ qemu-alpha -L gnemul/qemu-alpha/ alpha/ls

Für die Userspace-Emulation der SH4-Architektur sind die Programme qemu-sh4 oder qemu-sh4eb anzuwenden.

Host ~$ qemu-sh4   -L gnemul/qemu-sh4/   sh4/ls
Host ~$ qemu-sh4eb -L gnemul/qemu-sh4eb/ sh4eb/uname -a
Linux knut 2.6 #1 SMP Thu Oct 30 04:57:35 UTC 2008 sh4 unknown

Weitere Userspace-Emulatoren sind qemu-cris (ETRAX CRIS-Prozessorarchitektur),qemu-microblaze, qemu-microblazeel (MicroBlaze-Prozessorarchitektur), qemu-s390x und qemu-unicore32 (Unicore32).

[bearbeiten] Unter Mac OS X/Darwin

Die Userspace-Emulation unter Mac OS X/Darwin erfolgt in gleicher Weise wie unter Linux. Zusätzlich werden die FAT-Bibliotheken benötigt. Diese müssen gegebenenfalls von der Mac OS X-CD installiert oder kompiliert werden. Das folgende Beispiel startet die PPC-Version des Binaries:

Host ~$ qemu-ppc /bin/ls

In einer PPC-Architektur ist QEMU der Pfad zu den x86-Bibliotheken vorzugeben.

Host ~$ qemu-i386 -L /opt/x86_root/ /bin/ls

[bearbeiten] Unter BSD-Unix

Noch in der Entwicklung ist die Userspace-Emulation für BSD-Unix. Unter QEMU ab Version 0.10.0 können auf einen Sparc64-Hosts-System die Libraries von Sparc64 für Binaries verwendet werden.

Host ~$ qemu-sparc64 /bin/ls

Die Userspace-Emulation unter BSD-Unix verfügt zusätzlich über die Option -bsd type mit den möglichen Parametern FreeBSD, NetBSD and OpenBSD (Default). Damit wird das zu emulierende BSD festgelegt.

[bearbeiten] Analyse bei Verdacht auf Systemeinbruch

Neben den Vorteilen für die Software-Entwicklung ist eine andere Anwendung der Userspace-Emulation interessant. Bei einem Einbruch in ein System wird als erstes versucht diesen zu tarnen. Dazu werden sowohl Binaries als auch Bibliotheken des Opfer-Systems manipuliert. Das heißt, dass zum Beispiel der Befehl ls falsche Informationen anzeigt. Das System herunterzufahren und zu untersuchen ist nicht immer möglich. Liegt nur ein Verdacht vor, würde das Herunterfahren eines wichtigen Servers zu Ausfallzeiten führen. Auch könnten dabei wichtige Indizien verschwinden, da der Inhalt des Arbeitsspeichers verloren geht. Günstiger wäre die Analyse mit vom System unabhängigen Tools.

Mit der Userspace-Emulation können solche Tools mit ihren Bibliotheken von einer CD/DVD gestartet werden. Dabei muss das zu untersuchende System nicht heruntergefahren werden. Die folgenden Schritte demonstrieren vereinfacht, wie man eine solche CD/DVD für Linux anlegen kann. Zuerst ist QEMU aus den Quellen zu kompilieren, wobei der letzte Schritt (make install) nicht durchgeführt wird. Weiterhin sind die Dateien für die User-Space-Emulation von der QEMU-Website herunterzuladen und zu entpacken. Die QEMU-Binaries und die Dateien für die User-Space-Emulation werden auf eine CD gebrannt. Auf dem verdächtigen Rechner wird diese CD gemountet und in den Mountpoint gewechselt. Die Option -o exec ermöglicht es Programme von der CD zu starten.

~ # mount /dev/cdrom /mnt -o exec
~ # cd /mnt

Es wird der Userspace-Emulator von der CD gestartet. In diesem Beispiel wird unter der i386-Architektur der Befehl ls mit seinen Bibliotheken von der CD verwendet. Eventuell auf der Festplatte manipulierte Befehle und Bibliotheken werden dabei nicht benötigt. Dieser Befehl ist nicht manipulierbar, da er auf einer schreibgeschützten CD gespeichert ist. Damit wird IT-Forensik am laufenden System ermöglicht.

~ # ./qemu-0.11.0/i386-softmmu/qemul \
    -L usr/local/gnemul/qemu-i386 i386/ls -l

[bearbeiten] Weitere Optionen

Mit der Option -name definiert man einen Namen für die Instanz. Dieser Name wird in der Titelzeile des SDL-Fensters angezeigt. Im folgenden Beispiel erhält die Instanz den Namen Testuslongus.

Host ~$ qemu-system-x86_64 Platte.img -name Testuslongus

Im QEMU-Monitor kann dieser Name abgefragt werden.

(qemu) info name
Testuslongus

Weiterhin kann unter Linux der Prozess-Name für die Instanz vorgegeben werden. Diesen Prozess-Namen zeigt zum Beispiel das Programm top an.

Host ~$ qemu-system-x86_64 Platte.img -name Testuslongus,process=Hamster
Host ~$ top
...
7257 ich  20   0  215m 177m 6252 R   98  8.8   0:39.75 Hamster 
...

Die Instanz erhält mit der Option -uuid eine UUID (Universally Unique Identifier).

Host ~$ qemu-system-x86_64 Platte.img -uuid 571bba42-083e-45a4-abc6-f15821718453

Im QEMU-Monitor kann diese UUID abgefragt werden.

(qemu) info uuid
571bba42-083e-45a4-abc6-f15821718453

Ein Reboot des Gast-System verhindert man mit der Option -no-reboot. Stattdessen wird die Instanz beendet.

Host ~$ qemu-system-x86_64 Platte.img -no-reboot

Ein Beenden der Instanz nach dem Herunterfahren das Gast-Systems wird mit der Option -no-shutdown verhindert.

Host ~$ qemu-system-x86_64 Platte.img -no-shutdown

Die Option -pidfile file aktiviert das Schreiben einer PID-Datei. Eine PID-Datei enthält die Process Identification Number (PID) des Prozesses.

Host ~$ qemu-system-x86_64 Platte.img -pidfile /tmp/qemu.pid

Mit Hilfe der Process Identification Number lässt sich der Prozess eindeutig ermitteln.

Host ~$ ps a | grep `cat /tmp/qemu.pid`
15342 pts/1    R+     1:14 qemu Platte.img -pidfile /tmp/qemu.pid

Mit der PID lässt sich zum Beispiel ermitteln ob der Prozess noch läuft und man kann diesen Prozess mit dem Unix-Befehl kill beenden.

Host ~$ kill -9 `cat /tmp/qemu.pid`

Mit der Option -daemonize wird die Instanz als Daemon-Prozess gestartet. Die Trennung von der Standardein-/ausgabe erfolgt erst, bis die Devices von QEMU in der Lage sind Verbindungen anzunehmen. Diese Option ist nützlich zur Vermeidung von Race-Conditions während der Initialisierung von QEMU. Diese Option sollte zusammen mit -pidfile angewendet werden.

Host ~$ qemu-system-x86_64 Platte.img -pidfile /tmp/qemu.pid -daemonize 

Die Option -runas user übereignet den QEMU-Prozess dem angegebenen Benutzer. Dies ist sinnvoll, wenn zum Beispiel eine Instanz unter dem Benutzer root gestartet werden muss, dann aber ohne Root-Privilegien betrieben werden soll. Mit der Option -chroot dir wird beim Start von QEMU mit chroot in das angegebene Verzeichnis gewechselt.

Host ~# qemu Platte.img -k de -vnc localhost:1 \
        -runas ich -chroot /VMs/qemu/

Mit der Option -writeconfig werden Konfigurationseinstellungen der Instanz in eine Text-Datei geschrieben.

Host ~$ qemu-system-x86_64 Platte.img -writeconfig Konfiguration.txt

Die Text-Datei hat in diesem Beispiel diesen Inhalt:

# qemu config file
[drive]
  index = "0"
  media = "disk"
  file = "Platte.img"

Mit der Option -readconfig wird die Instanz mit den Optionen aus der Konfigurationsdatei gestartet.

Host ~$ qemu-system-x86_64 -readconfig Konfiguration.txt

Soll QEMU immer mit bestimmten Optionen gestartet werden, so sind diese in den Konfigurationsdateien sysconfdir/qemu.conf und sysconfdir/target-ARCH.conf zu definieren. Das Verzeichnis sysconfdir wird beim Kompilieren mit der Option config directory vorgegeben. Wurde QEMU mit der Option --prefix=/usr kompiliert, werden diese Konfigurationsdateien unter /usr/etc/qemu/ gesucht. Im folgenden Beispiel wird per Default die KVM hardware-unterstützte Virtualisierung aktiviert.

# /usr/etc/qemu/qemu.conf
[machine]
  accel = "kvm"

Zur Aktivierung der KVM hardware-unterstützte Virtualisierung braucht man keine Option mehr angeben.

Host ~$ qemu-system-x86_64 -monitor stdio
(qemu) info kvm
kvm support: enabled

Das Einlesen der Standard-Konfigurationsdateien wird mit der Option -nodefconfig unterdrückt.

Host ~$ qemu-system-x86_64 -monitor stdio -nodefconfig
(qemu) info kvm
kvm support: disabled


<<<|###| >>>

Von „http://qemu-buch.de/de/index.php?title=QEMU-KVM-Buch/_Spezielle_QEMU-Optionen

Diese Seite wurde bisher 65.730 mal abgerufen. Diese Seite wurde zuletzt am 29. März 2012 um 17:34 Uhr geändert. Inhalt ist verfügbar unter der GNU Free Documentation License 1.2.


Finden

Blättern

News

Deutsch
Weitersagen
Tipps für Autoren
Autoren
Impressum


English
Recommendation
The Authors
Contact



Letzte Änderungen


Ändern
Seite bearbeiten
Bearbeitungshilfe
Seitenoptionen
Diskussion
Kommentar hinzufügen
Druckversion
Seitendaten
Versionen
Links auf diese Seite
Änderungen an verlinkten Seiten
Meine Seiten
Anmelden
Spezialseiten
Neue Seiten
Dateiliste
Statistik
Kontakt
Mehr …