supervacuo.com

c v t

Virtualising Pidora (Fedora) 2014 with QEMU

16 November 2014

Having a virtual version of your Pi around can be very handy, for instance for compiling software without worrying about the Pi's slow CPU, limited RAM or occasional crash-tastic execution of gcc (on Pidora, at least).

There are several posts on the subject (see below) but enough annoying little details were different (due to having Fedora 20 instead of Ubuntu as the host and Pidora instead of Rasbpian as the guest) to want to write this down.

First, install the qemu-system-arm binary:

$ sudo yum install qemu-system-arm

Now, download the latest release image from the Pidora site and grab XEC Design's qemu kernel image:

$ wget http://xecdesign.com/downloads/linux-qemu/kernel-qemu

You may run into SELinux problems: a combination of moving these files to the libvirt storage pool directory and running restorecon will probably get there, but I lazily just ran setenforce 0 (which, if you follow my bad example, you should reverse with setenforce 1 after you're done playing with your VM).

Finally, to launch the system run:

$ qemu-system-arm -kernel /PATH/TO/kernel-qemu \
    -cpu arm1176 -smp cpus=1,threads=4 -m 256 \
    -M versatilepb -no-reboot -nographic \
    -append "root=/dev/sda2 panic=0 console=ttyAMA0" \
    -hda /PATH/TO/Pidora-2014-R3.img \
    -redir tcp:5022::22

Replace /PATH/TO with the paths to your kernel image and Pidora filesystem image, respectively.

I had a vague impression that the -smp option helped with performance but I didn't benchmark. The versatilepb board only supports 1 CPU, so a simple -smp 2 definitely doesn't work.

A text console will appear in STDOUT (i.e. in the console where you run this command); the -redir tcp:5022::22 option will forward port 22 to port 5022 on the host so you can also run ssh -p 5022 root@localhost once the machine is up.

QEMU's default network interface seems to work fine for me.

libvirt

My eventual goal was to set this up as a libvirt domain to make management easier, but it seems that the stack isn't quite there yet for non-x86 guests. The main issue is that the versatilepb device doesn't have a PCI bus, which makes it incompatible with the domain definition from the Fedora Wiki "Architectures/ARM/HowToQemu" page as libvirt currently seems to add PCI devices at the drop of a hat.

Bored of seeing (related bug report?):

error: XML error: No PCI buses available

A new domain definition (which manually disables USB and sets the hard drive to use drive instead of ide access) gets most of the way:

$ wget https://supervacuo.com/fedora/pidora_2014.xml
$ $EDITOR pidora_2014.xml # change file paths
$ sudo virsh define pidora_2014.xml
error: Failed to start domain pidora_2014
error: internal error: process exited while connecting to monitor: 2014-11-16T15:28:14.557686Z qemu-system-arm: -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1: Bus 'ide.0' not found

Luckily, this error message comes up in search results: superstar Harsh Jain saw this message last month and diagnosed the problem as libvirt adding an additional parameter vs. the original QEMU command. My let's-just-get-this-done temporary workaround was to repurpose Chris Taylor's qemu-system-arm wrapper script for Fedora 13:

$ wget https://supervacuo.com/fedora/qemu-system-arm
$ sudo mv /usr/bin/qemu-system-arm{,.bin} # move qemu-system-arm to qemu-system-arm.bin
$ sudo mv qemu-system-arm /usr/bin/qemu-system-arm
$ sudo chown root:root !$ && sudo chmod +x !$ # set file ownership and permissions

(NB that you should use qemu-system-arm.bin when running QEMU manually from now on)

$ sudo virsh define pidora_2014.xml
$ sudo virsh start pidora_2014.xml

Oh, happy day. Once you access the VM, though, you'll notice that there's no network… and if you peek in /var/log/libvirt/qemu/pidora_2014.log you'll see that the QEMU command line has a -nodefaults option which I believe suppresses the default network interface (among other things). I think patching out -nodefaults in the wrapper is too much hackery for today, and adding any kind of network device in the XML or with virt-manager brings back our beloved PCI buses error.

So this networkless-but-convenient VM is as far as I've got. Any hints?

References