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

[Roy Golan]

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.
>
>>    * 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.
>
>
>>
>> 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
>
>