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

[Itamar Heim]

On 12/14/2012 02:18 AM, Roy Golan wrote:
> On 11/18/2012 01:47 PM, 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.
> all of your concerns have been brought up. please have a look at the
> discussion around how to integrate with libosinfo
> http://lists.ovirt.org/pipermail/arch/2012-September/000924.html
> any comments about it would be appreciated.

I didn't see there anything on using a different config file/options per 
cluster level?

>>
>>>    * 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?
> I'd have to keep a set of devices per arch as libosinfo doesn't cover that.

or add it to libosinfo?

>>
>>
>>>
>>> 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?
>>
>>> Based on that and the exposed in the previous items, an approach that
>>> seems to make sense if the libosinfo patches
>>> are merged is to keep the focus of libosinfo usage as it is and for the
>>> other areas to use the suggested in the
>>> PowerKVM feature page
>>> (http://wiki.ovirt.org/wiki/Features/Engine_support_for_PPC64). This
>>> would benefit both and
>>> converge to a project's solution.
>>>
>>> Appreciate comments you may have.
>>>
>>> Kind regards,
>>>>>
>>>>> [1] some of the patches are:
>>>>> http://gerrit.ovirt.org/9065
>>>>> http://gerrit.ovirt.org/9063
>>>>> http://gerrit.ovirt.org/9049
>>>>>
>>>>
>>>> _______________________________________________
>>>> Arch mailing list
>>>> Arch at ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/arch
>>>>
>>>
>>> _______________________________________________
>>> Arch mailing list
>>> Arch at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/arch
>>
>>
>