.. _qemu-en: ==== 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 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 `` 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 cols 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 -append `` 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::`` Allows you to connect to qemu via gdb (the gdb command is ``target remote localhost:``) 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 `` software installation. ``apt-cache search `` 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 : 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. .. _enable password authentication: https://askubuntu.com/a/1498640