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

[Itamar Heim]

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?

> 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