Fedora 25 is out, virt-builder images available

$ virt-builder -l | grep fedora-25
fedora-25                x86_64     Fedora® 25 Server
fedora-25                i686       Fedora® 25 Server (i686)
fedora-25                aarch64    Fedora® 25 Server (aarch64)
fedora-25                armv7l     Fedora® 25 Server (armv7l)
fedora-25                ppc64      Fedora® 25 Server (ppc64)
fedora-25                ppc64le    Fedora® 25 Server (ppc64le)

$ virt-builder fedora-25
$ qemu-system-x86_64 -machine accel=kvm:tcg \
      -cpu host -m 2048 \
      -drive file=fedora-25.img,format=raw,if=virtio

Or to try out Fedora on a different architecture:

$ virt-builder fedora-25 --arch ppc64le -o fedora-25-ppc64le.img
$ qemu-system-ppc64 -cpu POWER8 -m 2048 \
      -drive file=fedora-25-ppc64le.img,format=raw,if=virtio

OCaml 4.04, RISC-V, S/390, POWER and more …

I pushed OCaml 4.04.0 to Fedora Rawhide last week. There are loads of new features for OCaml users, but the ones that particularly affect Fedora are:

• New, upstream POWER (ppc64, ppc64le) backend, replacing the downstream one that we have maintained for a few years. I was quite apprehensive about this change because I had tried the new backend during the OCaml 4.03 release cycle and found it to be quite unstable. However the latest version looks rock solid and has no problem compiling the entire Fedora+OCaml software suite.
• New, upstream S/390x backend. I actually found and fixed a bug, go me!
• New, non-upstream RISC-V backend. I found a bug in this backend too, but it proved to be easy to fix. You can now install and run most of the OCaml packages on Fedora/RISC-V.

And talking about Fedora/RISC-V, it took a month, but the mass-rebuild of all Fedora packages completed, and now we’ve got about ⅔rds of all Fedora packages available for RISC-V. That’s quite a lot:

$ du -sh SRPMS/ RPMS/
31G	SRPMS/
27G	RPMS/

virt-builder: Fedora 21 ppc64 and ppc64le images

virt-builder now has Fedora 21 ppc64 and ppc64le images available, and you can run these under emulation on an x86-64 host. Here’s how to do it:

$ virt-builder --arch ppc64 fedora-21 \
    -o fedora-21-ppc64.img

or:

$ virt-builder --arch ppc64le fedora-21 \
    -o fedora-21-ppc64le.img

To boot them:

$ qemu-system-ppc64 -M pseries -cpu POWER8 -m 4096 \
    -drive file=fedora-21-ppc64[le].img \
    -serial stdio

Oddly the boot messages will appear on the GUI, but the login prompt will only appear on the serial console. (Fixed)

Libvirt also has support, so with a sufficiently new version of the toolchain you can also use:

$ virt-install --import --name=guestname \
    --ram=4096 --vcpus=1 \
    --os-type=linux --os-variant=fedora21 \
    --arch=ppc64[le] --machine pseries \
    --disk=fedora-21-ppc64[le].img,format=raw
$ virsh start guestname

It’s quite fun to play with Big Iron, even in an emulator that runs at about 1/1000th the speed of the real thing. I know a lot about this, because we have POWER8 machines at Red Hat, and they really are the fastest computers alive, by a significant multiple. Of course, they also cost a fortune and use huge amounts of power.

Some random observations:

1. The virt-builder --size parameter cannot resize the ppc64 guest filesystem correctly, because Anaconda uses an extended partition. Workaround is to either add a second disk or to create another extended partition in the extra space. (Fixed)
2. The disks are ibmvscsi model (not virtio or ide). This is the default, but something to think about if you edit or create the libvirt XML manually.
3. Somehow the same CPU/machine model works for both Big Endian and Little Endian guests. It must somehow auto-detect the guest type, but I couldn’t work out how that works. Anyway, it just works by magic. it’s done by the kernel
4. libguestfs inspection is broken for ppc64le
5. Because TCG (qemu software emulation) is single threaded, only use a single vCPU. If you use more, it’ll actually slow the thing down.

Thanks: Maros Zatko for working out the virt-install command line and implementing the virt-builder script to build the images.