QEMU

Work in class will take place in a virtual environment using qemu.

Before starting work, create your own disk image based on the base image prepared for classes, using the following command:

qemu-img create -f qcow2 -o backing_file=/home/students/inf/PUBLIC/ZSO/zso2025.qcow2 zso2025_cow.qcow2

Students working on their own computers can download the base image (compressed with xz) at:

http://students.mimuw.edu.pl/ZSO/PUBLIC-SO/zso2025.qcow2.xz

The image thus created is a copy-on-write image: it only stores changes from the base image, saving disk space if multiple copies exist. Although the use of COW will not reduce disk usage when working on your own computer, it is still recommended due to the ability to easily restore the original state in case of problems with the file system.

To be able to use file sharing between a virtual machine and a host (recommended), you must also create the hshare directory.

Tu start qemu, run the following command:

qemu-system-x86_64 <options>

The following qemu options can be useful for classes:

-device virtio-scsi-pci,id=scsi0 -drive file=zso2025_cow.qcow2,if=none,id=drive0 -device scsi-hd,bus=scsi0.0,drive=drive0

Connects the hard disk image through a virtual block device. Required.

-enable-kvm

Enables hardware virtualization using KVM, significantly accelerating operation. Requires support from the host operating system: the driver kvm-intel or kvm-amd must be loaded, and qemu must have access to the /dev/kvm device.

-smp <number of processors>

Sets the number of processors in the virtual machine. It is recommended to set this option on the number of host processors, if we are the only user and use hardware virtualization.

-cpu qemu64,smap,smep or -cpu host or -cpu max

Sets up the emulated processor model with useful CPUID flags. -cpu host enables all host features and -cpu max all features supported by the accelerator.

-net nic,model=virtio -net user

Creates a virtual Ethernet network, connects it to a virtual machine using a virtual network device, and connects to the host TCP/IP stack by masquerading. Recommended.

-net user,hostfwd=tcp::2222-:22

Use this, instead of the -net user part above to set up a port forwarding from 2222 on the host to 22 on the guest. You could use this to ssh to the guest with ssh -p 2222 127.0.0.1: just remember to either enable password authentication or add your key to $HOME/.ssh/authorized_keys.

-m 1G -device virtio-balloon

Allows for dynamic memory allocation by the guest, up to the 1GB limit. Recommended.

-fsdev local,id=hshare,path=hshare/,security_model=none -device virtio-9p-pci,fsdev=hshare,mount_tag=hshare

Connects the hshare/ directory on the host over the 9p protocol to the virtual machine, allowing it to be easily mounted. Using the image prepared for classes, the exported catalog will be automatically visible in the guest system as /host. Recommended.

-chardev stdio,id=cons,signal=off -device virtio-serial-pci -device virtconsole,chardev=cons

Connects the terminal on which qemu works to the guest. Unfortunately, due to limitations of the virtio protocol, the terminal size information is not automatically passed on to the guest. To use full-screen programs in this way, you must manually correct this by executing the command within the guest OS:

stty rows <number of rows> cols <number of columns>

The right number of rows and columns for the terminal can be determined by entering the following command on the host system:

stty size

Recommended.

-display none

Disables the graphical qemu interface. Recommended when working over a network. It is then necessary to use the virtconsole option (or any other option that allows you to log in to the machine).

-kernel <file> -append <options>

Runs the linux kernel directly from the given file with the given options instead of going ahead of the standard boot process. Sometimes useful.

-gdb tcp::<port>

Allows you to connect to qemu via gdb (the gdb command is target remote localhost:<port>) and debug the kernel in this way. Sometimes useful.

-S

In combination with the -gdb option, it causes qemu to start in a suspended state, allowing you to set breakpoints etc. by gdb before the system is started.

If you use qemu with a graphical interface, you can access the qemu monitor console by Ctrl+Alt+2 (return via Ctrl+Alt+1). This console allows, among others, for connecting new virtual devices while qemu is running and forcing off / resetting the system (system_reset and quit commands).

Using virtual machines other than qemu is not possible -- one of the tasks will require writing a device driver for a simulated device provided in the form of a modified version of qemu.

Environment inside the image

The system installed in the image is debian 12, with minor modifications. You can log in using the login root and the password root. If you need to use an unprivileged account (e.g., for testing), you can use the account zso (password zso).

The image contains one ext4 partition with a grub2 bootloader installed, and the kernel in a version fixed for the labs.

Useful commands:

apt-get install <package name>

software installation.

apt-cache search <character string>

searching the software database

screen

a terminal multiplexer, useful when working with virtconsole, useful key combinations:

  • Ctrl-A Ctrl-C: creates a new sub-term

  • Ctrl-A Ctrl-W: sub-terminal list

  • Ctrl-A <number>: goes to sub-term number 0-9, respectively

  • Ctrl-A Ctrl-N: goes to the next sub-terminal

  • Ctrl-A Ctrl-P: goes to the previous sub-terminal

  • Ctrl-A ?: list of key bindings

poweroff

shuts down the system and turns off qemu

If qemu was run with the appropriate -net option, the system will have access to the external network. The host system is available at IP 10.0.2.2. However, access from the external network to the guest network is not possible (to enable this, you would use -net tap instead of -net user, which requires root privileges and is much more complicated). Instead, it is recommended to use the option virtio-9p-pci (for file sharing) and virtconsole (for copy/paste support and a meaningful terminal).

If the virtio-9p-pci option was used, the shared directory (hshare/ on the host system) is available as /hshare. Note, however, that the 9p protocol does not properly support the full UNIX file system semantics, which can cause problems for some applications. It is impossible to compile of the kernel inside the mounted directory, due to faulty handling of the rename() call.

When using virtconsole, remember to set the correct size of the terminal. If we use the same size of the terminal all the time, it is worth adding the appropriate stty calls to, for example, the .bash_profile file.

If it is not possible to use qemu with KVM support, it is worth performing tasks that require more computing power (e.g., kernel compilation) on the host computer.

Warnings

qemu without KVM is slow. The system can take 1-2 minutes to start (compared to a few seconds with KVM). What's more, the system used does not write anything on virtconsole until it is fully operational -- no output for a long time when using -display none therefore does not mean that the system has crashed.

Using qemu on students, and especially doing time-consuming activities on it, is a very bad idea - it is very slow, and what's more, it will be interrupted after an hour by the processor time limit. It's better to use one of the computers in labs or your own machine.

Using ssh to log in to a virtual machine is possible, using port forwarding with port 22, but remember to change the password on the root and zso accounts first.

When using a copy-on-write image, be careful never to modify the base image -- any change will make the copy-on-write image useless. It's best to set 444 permissions on it as soon as it's downloaded and decompressed.