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

Mon Nov 19 13:25:35 UTC 2012

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.

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.

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

>> 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
>
>
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
>