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

[Fernando Granha Jeronimo]

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

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