[ovirt-devel] Question about emulating ARM using oVirt

[Michal Skrivanek]

On Dec 15, 2014, at 12:37 , Richard Chapman <richard.chapman at ipe-systems.co.uk> wrote:

> Thank for the pointers I'll try it over xmas :)

also, if it helps you may want to check out some of the patches done by Eldorado guys when they were adding Power7 support. There were quite a few patches directly adding the support, but while I would agree the custom properties and hooks are best at this point it still can help you to understand all the different places…

Look at our gerrit, master branch, 2013 onwards, and filter these guys:
owner:"Leonardo Bianconi <lbianc at gmail.com>"
owner:"Gustavo Frederico Temple Pedrosa <gustavo.pedrosa at eldorado.org.br>"
owner:"Vitor de Lima <vdelima at redhat.com>"

Thanks,
michal

> 
> Chapman....
> 
> -----Original Message-----
> From: Itamar Heim [mailto:iheim at redhat.com] 
> Sent: 12 December 2014 13:09
> To: Richard Chapman; Devel at ovirt.org
> Cc: Michal Skrivanek; Dan Kenigsberg; Scott Herold; Barak Azulay
> Subject: Re: [ovirt-devel] Question about emulating ARM using oVirt
> 
> On 12/11/2014 06:16 AM, Richard Chapman wrote:
>> Hi and just wanted to say love oVirt.
>> 
>> I'm using oVirt 3.5 on Fedora20 to help with are devel/testing needs.
>> Are software runs on top of Linux both in Intel and ARM platforms.
>> While oVirt can handle very well the intel side of things I still need 
>> to run everything on ARM on real hardware. What I'm wondering is there 
>> a plan to support at least ARM emulation using QEMU now libVirt has 
>> been fixed.
>> 
>> Thank
>> 
>> Chapman....
> 
> I can't say there is a real plan to do so at this point, but it shouldn't block you from writing a custom hook changing the xml we pass to libvirt to envoke qemu-kvm with arm instead of qemu-kvm.
> you can (ab)use maybe some existing behaviors/properties, as well as add more of your own via custom properties (and for fancy - custom ui plugins to show those custom properties in the proper dialogs)
> 
> I'd say that's a good start to adding such support as an add-on, before considering it in the main code base.
> that's actually how we sometime develop a new feature - first "try it for sanity" via a custom hook to understand its scope and the issues.