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

Mon Nov 19 13:38:52 UTC 2012

On 11/19/2012 11:25 AM, 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.

just to avoid confusion: I am referring to the libosinfo patches, not 
the libosinfo itself. Libosinfo has support to manage hypervisor 
information.

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