KVM on IBM POWER (PPC64) support in vdsm and ovirt

[Itamar Heim]

On 11/19/2012 03:25 PM, Paulo de Rezende Pinatti wrote:
> On 11/18/2012 09:47 AM, Itamar Heim wrote:
>> On 11/16/2012 07:34 PM, Fernando Granha Jeronimo wrote:
>>> On 11/13/2012 10:02 AM, Paulo de Rezende Pinatti wrote:
>>>> On 11/13/2012 05:05 AM, Itamar Heim wrote:
>>>>> On 11/09/2012 08:35 AM, Itamar Heim wrote:
>>>>>> On 11/07/2012 04:17 PM, Paulo de Rezende Pinatti wrote:
>>>>>>> Hello all,
>>>>>>>
>>>>>>> I have consolidated the ideas for enabling ppc64 in ovirt-engine
>>>>>>> in a
>>>>>>> feature page:
>>>>>>> http://wiki.ovirt.org/wiki/Features/Engine_support_for_PPC64
>>>>>>>
>>>>>>> Suggestions and comments are greatly appreciated.
>>>>>>
>>>>>> iiuc, the most obvious change to mention is addition of an 'arch'
>>>>>> field
>>>>>> to cluster, which would affect the list of supported cpu families,
>>>>>> etc.?
>>>>>> (and to later know to filter all other aspects of entities based on
>>>>>> this
>>>>>> arch field)?
>>>>>>
>>>>>> list of possible arch's would be per cluster compatibility level.
>>>>>> i'd expect default for API of this field to be x86_64 for backward
>>>>>> compatibility, so it is not mandatory.
>>>>>> I'd also prefer this field to be disabled or hidden if there is only
>>>>>> one
>>>>>> option available in it.
>>>>>>
>>>>>> it gets more complicated, as VMs can be moved around between
>>>>>> clusters,
>>>>>> exported/imported, etc.
>>>>>>
>>>>>> you would need to validate a VM isn't moved to a cluster with a
>>>>>> different arch, or imported into a cluster with a different arch as
>>>>>> well.
>>>>>> (probably more like that).
>>>>>>
>>>>>> i assume the config to filter device types per arch like the network
>>>>>> devices is also for console (spice), audio, etc.
>>>>>>
>>>>>> the system already has the concept of filtering per cluster level, so
>>>>>> filtering per cluster level and arch would mean reviewing all
>>>>>> places in
>>>>>> code for that.
>>>>>
>>>>> I'm adding roy/omer/michal as the work on libosinfo (patches in
>>>>> gerrit[1]) seems to make some of these changes not needed (if it is
>>>>> merged).
>>>>> rather just need to extend libosinfo with the information on ppc.
>>>>>
>>>>> for sure worth reviewing both approaches to make sure the chosen
>>>>> solution benefits both and we collaborate on same end goal.
>>>>
>>>> thanks, we will check these patches and possibly change the approach
>>>> to use libosinfo.
>>>>
>>> Hello,
>>>
>>> We have carefully analyzed the engine libosinfo patches and the
>>> libosinfo itself to devise
>>> our conclusion. During this process, we found the following key points:
>>>
>>>    * In order to have a clear notion of supported versions and devices,
>>> we would
>>>      need to populate libosinfo's xmls for qemu and for devices, as well
>>> as implement logic in
>>>      ovirt-engine to process the relationship between them. This would
>>> be basically partially
>>>      reimplement the lib itself. In addition, given that we are not
>>> using the lib but actually processing
>>>      the xmls directly there is no guarantee that their structure will
>>> be preserved in the future,
>>>      which in the mid/long term may lead to code changes in the engine
>>> to adapt to it.
>>
>> I thought that is what roy's patches are doing?
>> i agree about the concern if the xml is changing.
>>
>>>    * Even if libosinfo had all the information we needed in the xmls, we
>>> would still need to validate
>>>      or filter values according to ovirt-engine's rules. For instance,
>>> if the list of network devices
>>>      for PowerKVM in libosinfo had 5 elements and the engine only
>>> intended to support/expose 2 specific models,
>>>      (for a given version for example) it has to be aware of these two
>>> models, meaning that even using libosinfo
>>>      we still need something in engine to validate them (which
>>> reinforces Itamar's filter suggestion).
>>
>> good point - Roy, how would cluster level compatibility for features
>> would work in your libosinfo approach?
>>
>>
>>>
>>> The primary concern of libosinfo patches is focused on virtual machine
>>> parameters validation based on OS.
>>> With regard to Power KVM support it doesn't address other areas like
>>> hypervisor/cluster validation logic.
>>
>> well, this could just be since it wasn't populated for a non x86_64
>> arch. would it make sense for you to discuss ppc support for libosinfo
>> regardless?
>>
>
> Thanks for your comments Itamar. It's good to discuss to find the best
> ways to proceed.
>
> I think the point Fernando made was that the libosinfo integration with
> ovirt is just for vm parameter validation, and other areas needing to
> change to support powerkvm such the hypervisor/cluster validation are
> not addressed by libosinfo at all, even for x86.

true, it doesn't solve everything, but it removes the need for the new 
config approach, if libosinfo path is chosen (since libosinfo contains 
similar metadata to the one we have in the config.

>
> It means that if we choose this path it would first be necessary to
> change ovirt code to tighter integrate with libosinfo, and implement the
> processing of links between xmls as well as validation of values against
> ovirt rules (both mentioned in bullets above). Libosinfo in turn would
> need its xmls populated to provide things like cpu flags, devices,
> hypervisor and versions information. These would be needed just for the
> code we have today, with no PowerKVM support yet.

actually, something i don't remember id discussed in the libosinfo approach:
roy - how do we handle the fact we actually need a libosinfo per cluster 
level?

>
> This would be a longer road which would be interesting to take if we had
> as a result a stable and centralized point of platform related
> information. But rather ovirt would be possibly sitting on unstable
> ground as Fernando well pointed the xmls can change at any time due to
> libosinfo projects needs, which would force ovirt to re-adapt to new xml
> formats. As to centralization, the information would still be partially
> dispersed due to the need to determine what ovirt wants to support (this
> kind of information cannot go in libosinfo).
>

yes, that is a concern.
but considering we may need to maintain a libosinfo per cluster level 
per my question above, we may want to adopt libosinfo "partially". i.e., 
we'd be copying and versioning it, or we'd be generating our own config 
format from it.
so if it changes, we'll just need to change the process we used to 
copy/generate it, but we'll be keeping our format and just leverage 
libosinfo as a db, but not the authoritative one, as we'll want to limit 
it to things we know, allow to extend it, etc.

so i agree libosinfo may not be the magic bullet, but i do think we need 
to move away from enum based OSs and db based config to a file based 
config of list of OSs and options for them (maybe simply one file per 
cluster level).

this file format can be based on libosinfo format, or another format 
which we'd be using libosinfo to populate maintain.

michael/roy - thoughts?

Thanks,
    Itamar