Quote: http://www.no-fw.com/index.php?q=aHR0cDovL2ZhYnJpY2UuYmVsbGFyZC5mcmVlLmZyL3FlbXUvcWVtdS1kb2MuaHRtbA%3D%3D
Since version 0.6.1, QEMU supports many disk image formats, including growable disk images (their size increase as non empty sectors are written), compressed and encrypted disk images. Version 0.8.3 added the new qcow2 disk image format which is essential to support VM snapshots.
You can create a disk image with the command:
qemu-img create myimage.img mysize
where myimage.img is the disk image filename and mysize is its size in kilobytes. You can add an M suffix to give the size in megabytes and a G suffix for gigabytes.
See section 3.6.4 qemu-img Invocation for more information.
If you use the option `-snapshot', all disk images are considered as read only. When sectors in written, they are written in a temporary file created in `/tmp'. You can however force the write back to the raw disk images by using the commit monitor command (or C-a s in the serial console).
VM snapshots are snapshots of the complete virtual machine including CPU state, RAM, device state and the content of all the writable disks. In order to use VM snapshots, you must have at least one non removable and writable block device using the qcow2 disk image format. Normally this device is the first virtual hard drive.
Use the monitor command savevm to create a new VM snapshot or replace an existing one. A human readable name can be assigned to each snapshot in addition to its numerical ID.
Use loadvm to restore a VM snapshot and delvm to remove a VM snapshot. info snapshots lists the available snapshots with their associated information:
(qemu) info snapshots
Snapshot devices: hda
Snapshot list (from hda):
ID TAG VM SIZE DATE VM CLOCK
1 start 41M 2006-08-06 12:38:02 00:00:14.954
2 40M 2006-08-06 12:43:29 00:00:18.633
3 msys 40M 2006-08-06 12:44:04 00:00:23.514
A VM snapshot is made of a VM state info (its size is shown in info snapshots) and a snapshot of every writable disk image. The VM state info is stored in the first qcow2 non removable and writable block device. The disk image snapshots are stored in every disk image. The size of a snapshot in a disk image is difficult to evaluate and is not shown by info snapshots because the associated disk sectors are shared among all the snapshots to save disk space (otherwise each snapshot would need a full copy of all the disk images).
When using the (unrelated) -snapshot option (section 3.6.2 Snapshot mode), you can always make VM snapshots, but they are deleted as soon as you exit QEMU.
VM snapshots currently have the following known limitations:
- They cannot cope with removable devices if they are removed or inserted after a snapshot is done.
- A few device drivers still have incomplete snapshot support so their state is not saved or restored properly (in particular USB).
usage: qemu-img command [command options]
The following commands are supported:
- `create [-e] [-6] [-b base_image] [-f fmt] filename [size]'
- `commit [-f fmt] filename'
- `convert [-c] [-e] [-6] [-f fmt] filename [-O output_fmt] output_filename'
- `info [-f fmt] filename'
Command parameters:
- filename
- is a disk image filename
- base_image
- is the read-only disk image which is used as base for a copy on write image; the copy on write image only stores the modified data
- fmt
- is the disk image format. It is guessed automatically in most cases. The following formats are supported:
raw - Raw disk image format (default). This format has the advantage of being simple and easily exportable to all other emulators. If your file system supports holes (for example in ext2 or ext3 on Linux or NTFS on Windows), then only the written sectors will reserve space. Use
qemu-img info to know the real size used by the image or ls -ls on Unix/Linux. qcow2 - QEMU image format, the most versatile format. Use it to have smaller images (useful if your filesystem does not supports holes, for example on Windows), optional AES encryption, zlib based compression and support of multiple VM snapshots.
qcow - Old QEMU image format. Left for compatibility.
cow - User Mode Linux Copy On Write image format. Used to be the only growable image format in QEMU. It is supported only for compatibility with previous versions. It does not work on win32.
vmdk - VMware 3 and 4 compatible image format.
cloop - Linux Compressed Loop image, useful only to reuse directly compressed CD-ROM images present for example in the Knoppix CD-ROMs.
- size
- is the disk image size in kilobytes. Optional suffixes
M (megabyte) and G (gigabyte) are supported - output_filename
- is the destination disk image filename
- output_fmt
- is the destination format
- -c
- indicates that target image must be compressed (qcow format only)
- -e
- indicates that the target image must be encrypted (qcow format only)
- -6
- indicates that the target image must use compatibility level 6 (vmdk format only)
Command description:
- `create [-6] [-e] [-b base_image] [-f fmt] filename [size]'
- Create the new disk image filename of size size and format fmt. If base_image is specified, then the image will record only the differences from base_image. No size needs to be specified in this case. base_image will never be modified unless you use the
commit monitor command. - `commit [-f fmt] filename'
- Commit the changes recorded in filename in its base image.
- `convert [-c] [-e] [-f fmt] filename [-O output_fmt] output_filename'
- Convert the disk image filename to disk image output_filename using format output_fmt. It can be optionally encrypted (
-e option) or compressed (-c option). Only the format qcow supports encryption or compression. The compression is read-only. It means that if a compressed sector is rewritten, then it is rewritten as uncompressed data. Encryption uses the AES format which is very secure (128 bit keys). Use a long password (16 characters) to get maximum protection. Image conversion is also useful to get smaller image when using a growable format such as qcow or cow: the empty sectors are detected and suppressed from the destination image. - `info [-f fmt] filename'
- Give information about the disk image filename. Use it in particular to know the size reserved on disk which can be different from the displayed size. If VM snapshots are stored in the disk image, they are displayed too.
In addition to disk image files, QEMU can directly access host devices. We describe here the usage for QEMU version >= 0.8.3.
On Linux, you can directly use the host device filename instead of a disk image filename provided you have enough privileges to access it. For example, use `/dev/cdrom' to access to the CDROM or `/dev/fd0' for the floppy.
CD - You can specify a CDROM device even if no CDROM is loaded. QEMU has specific code to detect CDROM insertion or removal. CDROM ejection by the guest OS is supported. Currently only data CDs are supported.
Floppy - You can specify a floppy device even if no floppy is loaded. Floppy removal is currently not detected accurately (if you change floppy without doing floppy access while the floppy is not loaded, the guest OS will think that the same floppy is loaded).
Hard disks - Hard disks can be used. Normally you must specify the whole disk (`/dev/hdb' instead of `/dev/hdb1') so that the guest OS can see it as a partitioned disk. WARNING: unless you know what you do, it is better to only make READ-ONLY accesses to the hard disk otherwise you may corrupt your host data (use the `-snapshot' command line option or modify the device permissions accordingly).
CD - The preferred syntax is the drive letter (e.g. `d:'). The alternate syntax `\\.\d:' is supported. `/dev/cdrom' is supported as an alias to the first CDROM drive. Currently there is no specific code to handle removable media, so it is better to use the
change or eject monitor commands to change or eject media. Hard disks - Hard disks can be used with the syntax: `\\.\PhysicalDriveN' where N is the drive number (0 is the first hard disk). WARNING: unless you know what you do, it is better to only make READ-ONLY accesses to the hard disk otherwise you may corrupt your host data (use the `-snapshot' command line so that the modifications are written in a temporary file).
`/dev/cdrom' is an alias to the first CDROM.
Currently there is no specific code to handle removable media, so it is better to use the change or eject monitor commands to change or eject media.
QEMU can automatically create a virtual FAT disk image from a directory tree. In order to use it, just type:
qemu linux.img -hdb fat:/my_directory
Then you access access to all the files in the `/my_directory' directory without having to copy them in a disk image or to export them via SAMBA or NFS. The default access is read-only.
Floppies can be emulated with the :floppy: option:
qemu linux.img -fda fat:floppy:/my_directory
A read/write support is available for testing (beta stage) with the :rw: option:
qemu linux.img -fda fat:floppy:rw:/my_directory
What you should never do:
- use non-ASCII filenames ;
- use "-snapshot" together with ":rw:" ;
- expect it to work when loadvm'ing ;
- write to the FAT directory on the host system while accessing it with the guest system.
QEMU can simulate several network cards (PCI or ISA cards on the PC target) and can connect them to an arbitrary number of Virtual Local Area Networks (VLANs). Host TAP devices can be connected to any QEMU VLAN. VLAN can be connected between separate instances of QEMU to simulate large networks. For simpler usage, a non privileged user mode network stack can replace the TAP device to have a basic network connection.
QEMU simulates several VLANs. A VLAN can be symbolised as a virtual connection between several network devices. These devices can be for example QEMU virtual Ethernet cards or virtual Host ethernet devices (TAP devices).
This is the standard way to connect QEMU to a real network. QEMU adds a virtual network device on your host (called tapN), and you can then configure it as if it was a real ethernet card.
As an example, you can download the `linux-test-xxx.tar.gz' archive and copy the script `qemu-ifup' in `/etc' and configure properly sudo so that the command ifconfig contained in `qemu-ifup' can be executed as root. You must verify that your host kernel supports the TAP network interfaces: the device `/dev/net/tun' must be present.
See section 3.3 Invocation to have examples of command lines using the TAP network interfaces.
There is a virtual ethernet driver for Windows 2000/XP systems, called TAP-Win32. But it is not included in standard QEMU for Windows, so you will need to get it separately. It is part of OpenVPN package, so download OpenVPN from : http://openvpn.net/.
By using the option `-net user' (default configuration if no `-net' option is specified), QEMU uses a completely user mode network stack (you don't need root privilege to use the virtual network). The virtual network configuration is the following:
QEMU VLAN <------> Firewall/DHCP server <-----> Internet
| (10.0.2.2)
|
----> DNS server (10.0.2.3)
|
----> SMB server (10.0.2.4)
The QEMU VM behaves as if it was behind a firewall which blocks all incoming connections. You can use a DHCP client to automatically configure the network in the QEMU VM. The DHCP server assign addresses to the hosts starting from 10.0.2.15.
In order to check that the user mode network is working, you can ping the address 10.0.2.2 and verify that you got an address in the range 10.0.2.x from the QEMU virtual DHCP server.
Note that ping is not supported reliably to the internet as it would require root privileges. It means you can only ping the local router (10.0.2.2).
When using the built-in TFTP server, the router is also the TFTP server.
When using the `-redir' option, TCP or UDP connections can be redirected from the host to the guest. It allows for example to redirect X11, telnet or SSH connections.
Using the `-net socket' option, it is possible to make VLANs that span several QEMU instances. See section 3.3 Invocation to have a basic example.
This section explains how to launch a Linux kernel inside QEMU without having to make a full bootable image. It is very useful for fast Linux kernel testing.
The syntax is:
qemu -kernel arch/i386/boot/bzImage -hda root-2.4.20.img -append "root=/dev/hda"
Use `-kernel' to provide the Linux kernel image and `-append' to give the kernel command line arguments. The `-initrd' option can be used to provide an INITRD image.
When using the direct Linux boot, a disk image for the first hard disk `hda' is required because its boot sector is used to launch the Linux kernel.
If you do not need graphical output, you can disable it and redirect the virtual serial port and the QEMU monitor to the console with the `-nographic' option. The typical command line is:
qemu -kernel arch/i386/boot/bzImage -hda root-2.4.20.img \
-append "root=/dev/hda console=ttyS0" -nographic
Use Ctrl-a c to switch between the serial console and the monitor (see section 3.4 Keys).
QEMU emulates a PCI UHCI USB controller. You can virtually plug virtual USB devices or real host USB devices (experimental, works only on Linux hosts). Qemu will automatically create and connect virtual USB hubs as necessary to connect multiple USB devices.
USB devices can be connected with the `-usbdevice' commandline option or the usb_add monitor command. Available devices are:
mouse - Virtual Mouse. This will override the PS/2 mouse emulation when activated.
tablet - Pointer device that uses absolute coordinates (like a touchscreen). This means qemu is able to report the mouse position without having to grab the mouse. Also overrides the PS/2 mouse emulation when activated.
disk:file - Mass storage device based on file (see section 3.6 Disk Images)
host:bus.addr - Pass through the host device identified by bus.addr (Linux only)
host:vendor_id:product_id - Pass through the host device identified by vendor_id:product_id (Linux only)
wacom-tablet - Virtual Wacom PenPartner tablet. This device is similar to the
tablet above but it can be used with the tslib library because in addition to touch coordinates it reports touch pressure. keyboard - Standard USB keyboard. Will override the PS/2 keyboard (if present).
WARNING: this is an experimental feature. QEMU will slow down when using it. USB devices requiring real time streaming (i.e. USB Video Cameras) are not supported yet.
- If you use an early Linux 2.4 kernel, verify that no Linux driver is actually using the USB device. A simple way to do that is simply to disable the corresponding kernel module by renaming it from `mydriver.o' to `mydriver.o.disabled'.
- Verify that `/proc/bus/usb' is working (most Linux distributions should enable it by default). You should see something like that:
ls /proc/bus/usb
001 devices drivers
- Since only root can access to the USB devices directly, you can either launch QEMU as root or change the permissions of the USB devices you want to use. For testing, the following suffices:
chown -R myuid /proc/bus/usb
- Launch QEMU and do in the monitor:
info usbhost
Device 1.2, speed 480 Mb/s
Class 00: USB device 1234:5678, USB DISK
You should see the list of the devices you can use (Never try to use hubs, it won't work).
- Add the device in QEMU by using:
usb_add host:1234:5678
Normally the guest OS should report that a new USB device is plugged. You can use the option `-usbdevice' to do the same.
- Now you can try to use the host USB device in QEMU.
When relaunching QEMU, you may have to unplug and plug again the USB device to make it work again (this is a bug).
The VNC server capability provides access to the graphical console of the guest VM across the network. This has a number of security considerations depending on the deployment scenarios.
The simplest VNC server setup does not include any form of authentication. For this setup it is recommended to restrict it to listen on a UNIX domain socket only. For example
qemu [...OPTIONS...] -vnc unix:/home/joebloggs/.qemu-myvm-vnc
This ensures that only users on local box with read/write access to that path can access the VNC server. To securely access the VNC server from a remote machine, a combination of netcat+ssh can be used to provide a secure tunnel.
The VNC protocol has limited support for password based authentication. Since the protocol limits passwords to 8 characters it should not be considered to provide high security. The password can be fairly easily brute-forced by a client making repeat connections. For this reason, a VNC server using password authentication should be restricted to only listen on the loopback interface or UNIX domain sockets. Password ayuthentication is requested with the password option, and then once QEMU is running the password is set with the monitor. Until the monitor is used to set the password all clients will be rejected.
qemu [...OPTIONS...] -vnc :1,password -monitor stdio
(qemu) change vnc password
Password: ********
(qemu)
The QEMU VNC server also implements the VeNCrypt extension allowing use of TLS for encryption of the session, and x509 certificates for authentication. The use of x509 certificates is strongly recommended, because TLS on its own is susceptible to man-in-the-middle attacks. Basic x509 certificate support provides a secure session, but no authentication. This allows any client to connect, and provides an encrypted session.
qemu [...OPTIONS...] -vnc :1,tls,x509=/etc/pki/qemu -monitor stdio
In the above example /etc/pki/qemu should contain at least three files, ca-cert.pem, server-cert.pem and server-key.pem. Unprivileged users will want to use a private directory, for example $HOME/.pki/qemu. NB the server-key.pem file should be protected with file mode 0600 to only be readable by the user owning it.
Certificates can also provide a means to authenticate the client connecting. The server will request that the client provide a certificate, which it will then validate against the CA certificate. This is a good choice if deploying in an environment with a private internal certificate authority.
qemu [...OPTIONS...] -vnc :1,tls,x509verify=/etc/pki/qemu -monitor stdio
Finally, the previous method can be combined with VNC password authentication to provide two layers of authentication for clients.
qemu [...OPTIONS...] -vnc :1,password,tls,x509verify=/etc/pki/qemu -monitor stdio
(qemu) change vnc password
Password: ********
(qemu)
The GNU TLS packages provides a command called certtool which can be used to generate certificates and keys in PEM format. At a minimum it is neccessary to setup a certificate authority, and issue certificates to each server. If using certificates for authentication, then each client will also need to be issued a certificate. The recommendation is for the server to keep its certificates in either /etc/pki/qemu or for unprivileged users in $HOME/.pki/qemu.
This step only needs to be performed once per organization / organizational unit. First the CA needs a private key. This key must be kept VERY secret and secure. If this key is compromised the entire trust chain of the certificates issued with it is lost.
# certtool --generate-privkey > ca-key.pem
A CA needs to have a public certificate. For simplicity it can be a self-signed certificate, or one issue by a commercial certificate issuing authority. To generate a self-signed certificate requires one core piece of information, the name of the organization.
# cat > ca.info <<EOF
cn = Name of your organization
ca
cert_signing_key
EOF
# certtool --generate-self-signed \
--load-privkey ca-key.pem
--template ca.info \
--outfile ca-cert.pem
The ca-cert.pem file should be copied to all servers and clients wishing to utilize TLS support in the VNC server. The ca-key.pem must not be disclosed/copied at all.
Each server (or host) needs to be issued with a key and certificate. When connecting the certificate is sent to the client which validates it against the CA certificate. The core piece of information for a server certificate is the hostname. This should be the fully qualified hostname that the client will connect with, since the client will typically also verify the hostname in the certificate. On the host holding the secure CA private key:
# cat > server.info <<EOF
organization = Name of your organization
cn = server.foo.example.com
tls_www_server
encryption_key
signing_key
EOF
# certtool --generate-privkey > server-key.pem
# certtool --generate-certificate \
--load-ca-certificate ca-cert.pem \
--load-ca-privkey ca-key.pem \
--load-privkey server server-key.pem \
--template server.info \
--outfile server-cert.pem
The server-key.pem and server-cert.pem files should now be securely copied to the server for which they were generated. The server-key.pem is security sensitive and should be kept protected with file mode 0600 to prevent disclosure.
If the QEMU VNC server is to use the x509verify option to validate client certificates as its authentication mechanism, each client also needs to be issued a certificate. The client certificate contains enough metadata to uniquely identify the client, typically organization, state, city, building, etc. On the host holding the secure CA private key:
# cat > client.info <<EOF
country = GB
state = London
locality = London
organiazation = Name of your organization
cn = client.foo.example.com
tls_www_client
encryption_key
signing_key
EOF
# certtool --generate-privkey > client-key.pem
# certtool --generate-certificate \
--load-ca-certificate ca-cert.pem \
--load-ca-privkey ca-key.pem \
--load-privkey client-key.pem \
--template client.info \
--outfile client-cert.pem
The client-key.pem and client-cert.pem files should now be securely copied to the client for which they were generated.
QEMU has a primitive support to work with gdb, so that you can do 'Ctrl-C' while the virtual machine is running and inspect its state.
In order to use gdb, launch qemu with the '-s' option. It will wait for a gdb connection:
> qemu -s -kernel arch/i386/boot/bzImage -hda root-2.4.20.img \
-append "root=/dev/hda"
Connected to host network interface: tun0
Waiting gdb connection on port 1234
Then launch gdb on the 'vmlinux' executable:
> gdb vmlinux
In gdb, connect to QEMU:
(gdb) target remote localhost:1234
Then you can use gdb normally. For example, type 'c' to launch the kernel:
(gdb) c
Here are some useful tips in order to use gdb on system code:
- Use
info reg to display all the CPU registers.
- Use
x/10i $eip to display the code at the PC position.
- Use
set architecture i8086 to dump 16 bit code. Then use x/10i $cs*16+$eip to dump the code at the PC position.
