Qemu notes

Notes related to (mostly whole-computer) virtualization, emulation and simulation. Virtualization, emulation, simulation · Docker notes · Qemu notes

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

Usage notes:

• VNC is handy (while installing and in general), since you get a view on the entire machine, including BIOS and bootup.

• If the mouse in your VNC window seems to be wrong (offset from the real mouse position), this is likely because of motion acceleration applied by the guest OS. An easy way to fix this is to get absolute positioning by making the mouse device report itself tablet-style: use -usbdevice tablet when running qemu.

• The easiest VM-to-host networking option is probably -net nic,vlan=1 -net user,vlan=1 (see networking notes below on what that actually means)

• -no-acpi may be useful for XP or anything else that tries to use ACPI a lot if prsent (but will run fine without it); it seems that emulating ACPI for the way XP and some other things use it uses unnecessarily much host CPU.

On networking

Qemu can emulate network cards in the guest (with NIC model and mac address configurable) and connects it its own VLAN - which is basically like a virtual router, giving you flexibility when interconnecting. You can, for example, connect each guest to other guests and/or to the host networking.

Of course, many of us just have a single guest and want to give it internet access. This means the default, which is equivalent to -net nic,vlan=1 -net user,vlan=1, is good. That means means "emulate a network card in the guest, connect it to VLAN1; connect qemu's usermode networking (to the host) to VLAN1 as well". In other words, this setup mkaes VLAN1 is a simple interconnect between the VM and the host.

You can get various possible interconnections. Some of the options:

• Qemu VLAN to host via usermode network stack
  • easy gateway to the outside (includes things like a basic in-qemu DHCP server), without needing any interface bother on the host side, nor much bother in the client
  • allows port redirects to the inside, which can be handy

• Qemu VLAN to host via tun/tap

• Qemu VLAN to host via VDE (usermode tool that manages tun/tap)

• Qemu VLAN to other Qemu VLAN

See also:

• http://en.wikibooks.org/wiki/QEMU/Networking
• http://en.opensuse.org/Qemu_networking

On images

http://en.wikibooks.org/wiki/QEMU/Images

Some older versions of Qemu have a few problems with qcow type images, and will report that they can't open the disk image (which would normally point to permission problems). Use another type, or use a different version of qemu. If you have such a problematic image, you can fix it by converting it to another type(verify) (using qemu-img).

Note that formats like qcow and qcow2 are sparse, but things like defragmenting and wiping in the guest OS will cause space not actually used by the guest filesystem data to be used on the host size. If you want to crimp it again, you can often shrink the image file by doing something like:

qemu-img convert -f qcow2 windows.img -O qcow2 windows-shrunken.img

(...and then swap them)

Growing or shrinking guest disk size

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

Possible, but some work as you're both resizing the filesystem and the disk that the guest OS sees.

Also, while most systems beside windows seem to deal with this well enough, windows copies part of the disk geometry into its boot code to identify the boot disk later, which causes problems in some cases, (possibly when you resize across certain sizes, seemingly two-power sizes?(verify)). The error you'll get is the rather uninformative "A disk read error occurred". You can fix this (by editing the MBR (probably easiest while it's still raw format, depending a little on how you do it), and there are probably some ways tools like fdisk might fix this too.

As to the actual resizing, the easiest option is probably to go via raw format. For example:

• (if shrinking:) shrink the partition within the VM so you know for sure that only the first so-many bytes of the (virtual) disk is being used. You'll need something which actually moves the data stored on the partition (gparted is an easy enough and free option).

• convert the image to a raw-type image

• truncate or extend the raw file (representing-a-disk) as you want. It's probably easiest to use dd, truncating and/or adding as necessary (look at dd's bs, count, and such)

• convert this new raw image to your favorite image format

• use gparted within the VM to resize the filesystem to the new disk size

For example, I started with a 6-gig image (initially created using qemu-img create windows.qcow2 -f qcow2 6G).

After installing windows, and stripping Windows down to take ~1.6GB I decided that a 3GB virtual disk would be enough, so:

• used gparted (within qemu, starting its liveCD using -boot d -cdrom gparted.iso) to resize the partition to ~2.7GB (under 3GB to avoid problems from rounded numbers - I could've worked exactly instead))}}.

• converted the image to raw:

qemu-img convert -f qcow2 windows.qcow2 -O raw windows.raw

• Copied the first ~3G to a new raw image. (Note that the following actually specifies 3000MB, ~2.9G, but this is still very comfortably more than what is actually used, since the gparted we did means that only the first ~2.7GB of that 6G raw image is used by the partition)

dd if=windows.raw of=win3g.raw bs=10M count=300

• converted this truncated raw to a qcow2 image again using qemu-img

qemu-img convert -f raw win3g.raw -O qcow2 win3g.qcow2

• started the VM with this new disk image, and booted the gparted liveCD again to grow the partition to the actual new disk size.

Experiment with XP

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

Choose the memory you'll need ahead of time. Windows can be picky about hardware changes, deciding it's now in a different computer. The below uses 384MB, which is comfortable enough for basic use.

• create drive image (max 5GB), here of type qcow2

qemu-img create windows.img -f qcow2 5G

• While installing windows:

qemu -no-acpi -localtime -usbdevice tablet -net nic,vlan=1 -net user,vlan=1 windows.img -m 384 -vnc :2 -boot d -cdrom winxpsetup.iso

Now you can connect a VNC client to :2 and watch it boot, install windows, and such.

Once windows is installed, the CDROM isn't really necessary (arguably it can't hurt as windows can always find any files needed for extra installation).

You may wish to configure XP to listen for Remote Desktop and use that instead of (or in addition to) VNC (note: you may wish to add a password to VNC access). To use remote desktop you'll also need to forward a port to the inside.

The command I use for regular runs of this VM:

qemu -no-acpi -localtime -usbdevice tablet -net nic,vlan=1 -net user,vlan=1 windows.img -m 384 -redir tcp:3389::3389