qemu kvm

Repeatedly copying an image on a Flash drive can quickly destroy it. It is therefore advised to test the generated image before performing any copy on a real drive. qemu is a convenient tool for this.

Simulating a copy of the image on a larger drive

In order to simulate a copy of the image on a larger drive, we copy the file and modify the size of this file copy.

$ cp img.dd img_on_drive; truncate -s 16G img_on_drive

Running qemu

You can then test the image with qemu.

$ kvm -drive file=img_on_drive,media=disk,format=raw -m 2048

Note: kvm is a shortcut for qemu-system-x86_64 -enable-kvm (i.e., qemu with the option leveraging the CPU instruction set for virtualization and related kernel module).

Using qemu serial terminal

When working on a minimal OS (no graphical system), it is often convenient to use the emulated serial line of the virtual machine. The added value of this is that you can test the OS without leaving your current terminal.

In order to achieve this, we can use the following option of qemu:

-serial mon:stdio

You also need to let your OS know it should use its serial console. With systemd-based OSes, adding the kernel bootarg "console=ttyS0" is enough. You can achieve this by editing the grub entry at bootup (select the entry and type 'e' when the grub screen appears).

Another option is to have this option in the generated image. You can achieve this by adding the following option to your debootstick command line:

--config-kernel-bootargs console=ttyS0

(In this case, you may want to regenerate the final image without this option when you are done with qemu/kvm tests.)

Here is a sample test:

$ kvm -m 2048 -drive file=img_on_drive,media=disk,format=raw -serial mon:stdio
[...grub menu...]
[...possibly kernel messages...]
[...]

Ubuntu 14.04.1 LTS localhost ttyS0

localhost login: root
Welcome to Ubuntu 14.04.1 LTS ([...])
[...]

root@localhost:~# echo "We are inside the VM!"
We are inside the VM!
root@localhost:~# init 0
[...]
$  # back to your initial terminal

Testing the installer mode

To test the installer mode, you should obviously generate the image with appropriate option:

$ debootstick --system-type installer [...]

qemu should be started with a secondary disk, larger than the generated image, in order to simulate the machine internal disk to migrate to. This blank disk can be created using:

$ touch /tmp/big-disk.dd
$ truncate -s 1T /tmp/big-disk.dd

Then, qemu should be started with two simulated disks:

$ kvm -m 2048 -serial mon:stdio -drive file=img_on_drive,media=disk,format=raw \
                                -drive file=/tmp/big-disk.dd,media=disk,format=raw

Testing the UEFI boot

It is possible to test the UEFI boot by adding the following qemu option:

-bios /path/to/OVMF.fd

Recent operating systems provide this file at path /usr/share/ovmf/OVMF.fd if you install the package ovmf.

Testing Secure-Boot

Note: Secure-Boot handling appeared in version 2.8.

It is possible to test Secure Boot by using the following steps (assuming debian bullseye host OS):

$ apt install ovmf
$ cp /usr/share/OVMF/OVMF_CODE.secboot.fd .
$ cp /usr/share/OVMF/OVMF_VARS.ms.fd .

Then, add the following options to your qemu command line:

-machine pc-q35-2.5,smm=on \
-global driver=cfi.pflash01,property=secure,value=on \
-drive if=pflash,format=raw,unit=0,file=OVMF_CODE.secboot.fd,readonly=on \
-drive if=pflash,format=raw,unit=1,file=OVMF_VARS.ms.fd \
-global ICH9-LPC.disable_s3=1

(note: the -bios option introduced in previous section for basic UEFI boot is no longer needed in this case.)

On first boot, the UEFI shell may be started, because this is the 1st entry in default boot order. You can type "exit", then the BIOS configuration interface will be printed. Select Boot Maintenance Manager, Boot Options, Change Boot Order and set the qemu disk first. Then reset the virtual machine.

When booted, you can check whether Secure Boot is enabled by using mokutil --sb-state:

root@vm-debian:~# mokutil --sb-state
SecureBoot enabled
root@vm-debian:~#

Simulating disks with non-default sector size

Note: handling of non-default sector size appeared in version 2.8.

This can be achieved by using qemu disk driver virtio-blk-pci and its options logical_block_size and physical_block_size. At the time of this writing, the default BIOS cannot boot such a device, but we can use UEFI and OVMF as described above.

For instance, the following command starts kvm with:

• our debootstick image as a first disk, using the default driver (IDE)
• a secondary disk and its virtio-blk-pci driver with options simulating 4K native format

$ kvm -bios /usr/share/ovmf/OVMF.fd -serial mon:stdio -m 4096 \
      -drive file=img_on_drive,media=disk,format=raw
      -drive file=/tmp/big-disk.dd,if=none,id=bigdisk,format=raw
      -device virtio-blk-pci,scsi=off,bus=pci.0,drive=bigdisk,logical_block_size=4096,physical_block_size=4096

Troubleshooting

Qemu-KVM proposes 128MB of RAM by default, which is very low for operating systems nowadays and will probably make the OS fail to boot with obscure error messages. You should increase this amount by using the -m option.

If the image boots properly with qemu-kvm but fails to boot on real hardware, then the image probably misses a specific driver for this hardware. Installing this missing driver in the chroot before running debootstick should solve the issue. See the FAQ for more info.