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

[omalleys at msu.edu]

Quoting Gordan Bobic <gordan at bobich.net>:

> On 31/01/2011 21:03, Niels de Vos wrote:
>
>>>> 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
>>
>> Cool! I'm complete unaware what makes ARM a special architecture, so
>> this is quite interesting. I've added some notes/thoughts to the bug,
>> maybe it helps to get it included ;)
>
> Thanks. I won't hold my breath for it, though. :)
>
>>>> 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.
>>
>> Hmm, thats good to know. I was just hoping that there is something
>> like a general basic arm kernel with all the modules, which boots on
>> most boards, but would run sub-optimal.
>
> No such thing at the moment. If you look through the kernel
> configuration options, there is no "generic" option - you have to select
> pretty specifically what you want it to run on, and there's no
> multi-choice on CPU selection.

Im actually kind of wondering if the qemu/arm/virtio kernel should be  
the "default kernel".. Just to get people started who don't have the  
hardware..


>>> 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 )
>>
>> Well, my laptop runs libvirt and I m quite happy with that. I'll stick
>> with libvirt/qemu as that does not interfere with my 'production' VMs.
>>
>> Maybe you understood my question wrong... Gol i to do some
>> development/tests on my x86_64 laptop, and then run the resulting
>> packages on the hardware ARM.
>
> I get it, but ARM emulated on x86 will run at a tiny fraction of native
> speed. You may well find it completely unusable.

It is very slow compared to real hardware. However, some of the  
performance issue is the fact the default kernel and the default board  
only uses 128M of ram at least in F12.

Also, iirc we didn't find any alignment errors with the qemu-arm test.