[fedora-arm] Trying to run Fedora-ARM as a virtual machine

[Gordan Bobic]

On 29/01/2011 17:05, Niels de Vos wrote:
> Hi there!
>
> I'm looking into getting an ARM system as small home-server. Of course
> I'd like to run Fedora on it, but unfortunately it seems that current
> Fedora releases are not completely ready for this yet.

It's probably ready enough. F12 is the stable one, and F13 alpha rootfs 
is available. A few things are missing (a few important KDE parts, but 
they do build OK on F12), and a few things are broken and unstable 
(Firefox of the F12 vintage isn't of generically good enough quality to 
handle bug-free running on ARM), but overall it's more than usable 
enough. I run a F12/F13 hybrid (F12 rootfs yum updated to F13 alpha from 
the koji repository where packages update cleanly) on my Sheevaplug 
(Kirkwood ARMv5) and on my Toshiba AC100 (Tegra 2 ARMv7), and they work 
quite well - certainly well enough for any common server tasks.

You may want to check the archives and sign up to the redhat bugzilla 
where bugs are tracked. I submitted a patch recently to add a feature to 
rc.sysinit that changes the default kernel behaviour about alignment 
errors. I suggest you apply it and set the default to fix+warn and file 
bugzilla reports for all the apps that cause these warnings.

Here's a direct link to the bugzilla report:
https://bugzilla.redhat.com/show_bug.cgi?id=673691

> I'd like to help with this, and as a start I am trying to get a fully
> functioning VM up and running. Obviously there are issues to overcome
> with this too. Many thanks for documenting the issues in the wiki!
> Before I decide to buy myself a Pandaboard or similar, I'd like to get
> some more experience with Fedora on ARM. My first personal project
> will be getting libvirt work with ARM out of the box. I hope that this
> attracts some more interested parties and lowers the barrier for
> contributions.

I'd suggest starting with something self-contained and well supported, 
such as the Sheevaplug. It's quite speedy (not as fast as the 
Pandaboard, but fast enough and better for development because it's 
ARMv5, which means you'll get to see the alignment errors when they 
occur rather than them being silently fixed up. Better for testing, IMO. 
I have a Mk1 Sheevaplug and it's quite well supported by the community.

> While I am checking the details of qemu and libvirt, I am wondering if
> there is a kernel available that has virtio support. If not, I will
> need to compile my own kernel, which feels a little silly.
> https://arm.koji.fedoraproject.org does only seem to have one kernel
> package available, and that is kernel-headers which I hardly can use
> for booting. I am wondering if there are any scratch-builds available
> that have a functioning vmlinz.

You will almost certainly need to build your own kernel anyway, because 
kernels on ARM are pretty CPU specific. While it has recently been 
mentioned that there is a project underway to provide a small-ish set of 
kernels to try to cover a majority of popular ARM devices, right now you 
will almost certainly want to build your own kernel.

ARM emulation using qemu on x86 is OK for minor things to begin with, 
but performance is quite crippling.

As for development on ARM and virtualization - I suggest you look at 
Linux vserver. I have it pretty much working, but there are a couple of 
bugs in the tools stemming from the fact that dietlibc isn't quite bug 
free on ARM yet, but it's getting close (see this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=667852 )

That means that you'll have to create your /etc/vserver entries for the 
VMs manually, but it's not that hard, and I can provide you with some 
working examples if you decide to go that way. libvirt/qemu on ARM may 
be too slow for any sensible work - I am not sure what the status with 
KVM is on ARM, but I wouldn't bet on it working on most (if any) ARM 
hardware. Vserver, OTOH, comes with just about no overhead at all, if 
you want a jail for testing and developing things. Of course, this 
assumes you already have an ARM device already set up and working.

> Furthermore I'd like to know what the best way is to follow the status
> of the current ARM builds, and where to find out where help is most
> needed?

This list and the RedHat bugzilla are a good place to start. :)

Gordan