Skip to main content

Using the Mele Quieter2 with Qemu and KVM Virtualisation

Mele Quieter2 mini PC

Tiny fanless PC provides a convenient personal virtualisation platform.

Kernel-based Virtual Machine (KVM) and Qemu together provide a powerful virtualisation solution which enables Linux to act as a Type 1 hypervisor and deliver near bare metal performance, while simultaneously providing a host of convenient features for managing virtual machines (VMs).

The Mele Quieter2 mini PC meanwhile sports a quad-core Celeron processor with the Intel VT-x feature that is required for KVM support. Coupled with 8GB RAM, 128GB on-board storage and M.2 NVMe expansion, this provides an eminently compact solution for virtualisation used as part of software development and test, where different operating system environments may be created, copied, booted, shut down and deleted etc. with ease, as and when required.

Of course, virtualisation platforms could be used with a developer laptop or desktop system and frequently is. However, using dedicated hardware has the benefit that such workloads do not impinge on their primary use and, conversely, web browsing and productivity tools etc. don’t impact performance and potentially invalidate results. A low-power, fanless system such as the Quieter2 is also more convenient to leave powered up for extended periods of testing.

In this article we will take a look at installing Ubuntu Linux, KVM and Qemu, following which carry out basic configuration, before installing and booting a guest operating system in a VM.


Hardware - a look inside of the Mele Quieter2 mini PC

Aside from the Quieter2, the only other hardware used was a 1TB NVMe SSD. This can be seen fitted above, with the provided thermal gap filler pad on top and ready for the base to be fitted.

In the Mele Mini PC FAQ there is an item regarding installing Ubuntu 20.04, which suggests that if experiencing problems booting, the BIOS should be entered using F7 at power on and:

  • The OS Selection should be changed from Windows to Linux
  • 8254 Clock Gating should be disabled

No changes were initially made and no issues were experienced with installing and booting Ubuntu. Upon checking the BIOS settings the OS Selection was changed from Windows to Linux for good measure, while it turned out that 8254 Clock Gating was disabled by default.

Ubuntu host

The latest Long Term Support (LTS) release of Ubuntu Server was installed for the host operating system, which at the time of writing is 22.04.2. The desktop variant would also work, but only really makes sense if you plan to attach a keyboard, monitor and mouse for local use. Whereas we much prefer to operate servers “headless”, with access over the network, as this uses less disk space and RAM, with a more lean software installation comprised of only what is necessary.

The default Ubuntu installer options were mostly taken and the choices are fairly self-explanatory. The O/S was installed to the Quieter2’s 128GB eMMC storage, as this should provide plenty of space and leaves the NVMe storage completely free for exclusive use with guest virtual machines. By default the installer configures Logical Volume Manager (LVM) and rather than allocate all free space to the root filesystem, it allocated 55G, leaving around half of the eMMC storage free for other filesystems — or alternatively for root to be expanded at some point in the future.

Once fully installed and booted, the system was updated and necessary software installed with:

$ sudo apt update && sudo apt dist-upgrade
$ sudo apt install avahi-daemon avahi-utils bridge-utils cpu-checker qemu qemu-kvm

This gives us Qemu with KVM support, plus some other useful software, such as Avahi mDNS, which makes it easier to connect to the system and particularly when configured to use DHCP.

As we had named our system ‘kvmhost’ we could then connect from another Linux system with:

$ ssh kvmhost.local

To find the device name for our SSD we used the lsblk command.

Using code lsblk to see SSD

Here we can see the 1TB drive appears as /dev/nvme0n1. We decided to create a mount point for this at /vm.

$ sudo mkdir /vm

Then used fdisk to partition the SSD.

$ sudo fdisk /dev/nvme0n1

fdidk to partition drive

The options selected in order to create a single partition which filled the disk can be seen above.

Next, the partition was formatted with the ext4 filesystem.

$ sudo mkfs.ext4 /dev/nvme0n1p1

To find out the partition UUID we then ran:

$ lsblk -f

Finding out the partition UUID

Following which we could update the /etc/fstab file so that this is mounted at boot time.

mounted at boot time

Instead of rebooting in order to mount the new filesystem, we simply entered:

$ sudo mount /vm

mount the new filesystem

And now we can see that we have 870G available for use with VMs.

In order to be able to create files as our user we had to change the ownership with:

$ sudo chown -R <user>:<group> /vm

Finally, we added our user to the kvm group in order to be able to access KVM acceleration.

$ sudo usermod -a -G kvm <user>


check that KVM acceleration is enabled

To check that KVM acceleration is enabled we can run the command:

$ kvm-ok

The output of which, if everything is as it should be, can be seen above.

KVM enables hardware-assisted virtualisation and it is this which requires a processor with the Intel VT-x feature, or alternatively the AMD-V feature with an AMD processor. Qemu can be used without KVM, but will be much slower and this provides near “bare metal” performance.

At this point it should be noted that Qemu can also be used to emulate many other hardware platforms, such as SPARC and RISC-V, for example. However, this will also run much slower, but still frequently fast enough to use for retro computing projects — e.g. booting a copy of Solaris, as used with vintage hardware in a previous project — or compiling software for another architecture.



Virtual machines will need storage and here Qemu provides a number of options. Most of the time disk image files are used, as these can easily be copied and moved from one VM to another. Another nice feature is that snapshot mode can be set with these, which causes the disk image to be accessed read-only and writes directed to a temporary file. This can be prove useful in testing.

Qemu also has a VM snapshots feature, which is something different altogether and where the entire virtual machine, including CPU state and RAM etc., is saved to disk.

There are different disk image formats available, such as raw (the simplest) and qcow2, with the latter features including allocating space on write and optional encryption. VirtualBox and VMware disk image formats are also supported. These formats all have their own benefits and limitations.

It is also possible to use iSCSI LUNs, where block storage is provided over the network. And to directly access local NVMe storage, whereby host kernel filesystem and block layers are bypassed, and the controller is used exclusively by Qemu. This typically provides higher I/O performance and is something we should be able to do with the Quieter2 configured to boot from its eMMC storage.

So let’s say we wanted to create a 64G raw disk image format file for a new Windows 10 VM, we might enter:

$ mkdir /vm/win10
$ qemu-img create /vm/win10/hd1.img 64G

For more information, see the Qemu disk image documentation.


There are an awful lot of system emulation options, for things such as the machine type and whether to use acceleration such as KVM. Along with things such as USB, network and storage emulation. Not to mention also the BIOS to use with the VM.

Rather than go through all these options in detail, let’s take a look at an example.

$ qemu-system-x86_64 -machine type=q35,accel=kvm -cpu host -smp 2 -m 6G -bios /usr/share/ovmf/OVMF.fd -cdrom /vm/win10/Win10_22H2_EnglishInternational_x64.iso -drive file=/vm/win10/hd1.img,index=0,media=disk,format=raw -device e1000,netdev=net0 -netdev user,id=net0

Here we are saying that we want to run the 64-bit PC emulator, emulating a Q35 type machine and to use KVM for acceleration. We’d like to configure the CPU model to be the same as the physical CPU provided by the host, albeit with the guest VM using just 2-cores, and 6GB RAM available. We’d like to use the OVMF BIOS, which is a port of Intel’s Tianocore open source UEFI BIOS.

The -cdrom argument is mounting an ISO file as a virtual CD-ROM, while the disk image file we created earlier is being mounted as the first emulated HDD. The E1000 device is an emulated 1G Intel Ethernet NIC and we’re configuring this to use the simplest type of networking, user.

But what is a Q35 machine? This is emulation of a reasonably modern PC and if we don’t specify a machine option and simply use the default instead, we get things such as PCI bus instead of PCIe and much slower IDE controller emulation instead of SATA. Remember that a computer is much more than just its CPU and the chipset and controllers etc. must be emulated also. There are options to set specific features, such as the emulated disk controller type, but Q35 is a convenient shortcut.

Networking is also a little more complicated and while it won’t give us the best performance and has some limitations, the easiest thing to configure is user networking. We can also emulate other NIC types and use a para-virtualised adapter with modern guests for the best performance. For more information on these and other networking options, see the Qemu Wiki.


Running Qemu with graphical output

Since we’re accessing the Quieter2 over the network and we’ll be using Qemu with graphical output, we need to enable X11 forwarding over our SSH connection, which we can do with:

$ ssh -Y kvmhost.local

And then the command to launch Qemu as previously described:

$ qemu-system-x86_64 -machine type=q35,accel=kvm -cpu host -smp 2 -m 6G -bios /usr/share/ovmf/OVMF.fd -cdrom /vm/win10/Win10_22H2_EnglishInternational_x64.iso -drive file=/vm/win10/hd1.img,index=0,media=disk,format=raw -device e1000,netdev=net0 -netdev user,id=net0

Note how we didn’t use sudo and shouldn’t have to since we’re a member of the kvm group and have configured for user type networking. And if we did try to use sudo this would in fact result in an error with X11 graphics forwarding.

Windows 10 installer loaded and installation

After responding to the BIOS prompt to boot from DVD the Windows 10 installer loaded and installation proceed.

Windows desktop looking at the DesignSpark Website

After responding to installation prompts and a few reboots later, we were then presented with the familiar Windows desktop and could start a browser and load up the DesignSpark website.

Windows 10

The Quieter2 came with Windows 10 pre-installed. A leaflet included in the box provided a link for a forum which should have had a download link for a DVD image for reinstalling Windows. Unfortunately, this forum link did not work, but a quick search turned up:

The ZIP file available from this page expands to a directory structure which is meant to be copied to a USB drive.

For the virtual machine, Windows 10 install an ISO file was downloaded via:

Wrapping up

The Quieter2 is a neat little PC that makes for a convenient dedicated virtualisation platform which can be used at work and home and is easily thrown into a bag — or a pocket! — to transport between the two. Qemu and KVM together provide a powerful solution for creating and managing virtual machines on the Quieter2 which run at close to bare metal speed.

This has been a very much basic introduction to Qemu and there are many more features and configuration options which have not been covered. Furthermore, the addition of libvirt and VNC would make it much more convenient to create new VMs, automatically start them upon boot and to connect at will over the network. This is something which we may cover in a future article.

  — Andrew Back

Open source (hardware and software!) advocate, Treasurer and Director of the Free and Open Source Silicon Foundation, organiser of Wuthering Bytes technology festival and founder of the Open Source Hardware User Group.
DesignSpark Electrical Logolinkedin