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

[Paulo de Rezende Pinatti]

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.

Thanks,

Paulo de Rezende Pinatti
Staff Software Engineer
IBM Linux Technology Center

On 10/21/2012 05:05 AM, Itamar Heim wrote:
> On 09/09/2012 07:38 PM, Pradipta Kumar Banerjee wrote:
>> Dear All,
>> Request your comments and suggestions on managing KVM on IBM POWER 
>> (PPC64) via
>> ovirt/vdsm
>>
>> Please find the feature page here -
>> http://wiki.ovirt.org/wiki/Features/Vdsm_for_PPC64
>>
>> The vdsm changes are under discussion and can be found here
>> http://gerrit.ovirt.org/7072
>>
>
> was in my queue for a while, finally got to it.
> thanks for the feature page.
> some comments on the text i copy/pasted from the wiki:
>
>> Managing KVM on IBM POWER processors requires changes to both vdsm 
>> and ovirt-engine. However the intent is to keep ovirt-engine changes 
>> to the minimum
>>
>> Following are the key changes that will be required
>>
>>     Enhancing the bootstrapping mechanism in VDSM to handle IBM POWER 
>> processor and ppc64 specifics (like cpuid, cpu speed, cpu flags)
>>     Adding a new CPU type (IBM POWER) to ovirt-engine
>
> so would this be something like intel/amd/ppc7 type of a thing?
> the current cpu types are indeed separated into intel and amd, but 
> this only affects the cpu level compatibility feature at the cluster 
> level.
> but they are both x86_64, so all other aspects of hardware are the 
> same for them.
> i think you need a new 'arch' parameter for cluster.
> then you need the config to be both version and arch dependent, so you 
> could specify things like disk/network/display/audio drives available 
> per version, per arch.
> now i'm not sure i would call this 'arch', since it would make the 
> change to the config too specific, but maybe a more general 'filter' 
> column which allows to specify various filters on the config (arch 
> would be one of them.
> maybe make filter notation a convention of "arch:x86_64" to specify 
> what the filter is about.
>
>>     Enhancing the VM templates based on guest device models (disk, 
>> network, video) supported by KVM on IBM POWER
>>
>> KVM on IBM POWER supports the following device models for guest
>>
>>     virt-io, spapr-vscsi for disk
>>     virt-io, e1000, rtl and spapr-vlan for network
>>     vga device is supported for guest video
>>     Only VNC backend is supported for guest console access.
>>
>> There is currently no support for SPICE protocol and USB support in 
>> guests.
>>
>> Both NFS and SAN storage is supported for the hosts. iSCSI support is 
>> currently work in progress
>> User Interface
>>
>> No new user interfaces are required to be added. However few of the 
>> existing interfaces needs to be updated to reflect KVM on IBM POWER 
>> related specifics.
>
> i think the arch field is needed at cluster, level, but that's indeed 
> a small ui change.
> but you probably also need to add the arch to the VM/template 
> entities, and to the OVF.
> all places using configs (that are relevant) would need to be fixed to 
> use the filter.
> logic of moving VMs between clusters, creation of VMs from template, 
> import/export, etc. would need to validate arch as well.
>
>>
>> At the minimum following user interfaces will be affected
>>
>>     New Server/New Desktop Virtual Machine in userportal
>>     New Server/New Desktop Virtual Machine in webadmin
>>     Make Template in userportal and webadmin
>>     Editing Virtual Disks and Editing Network Interfaces in webadmin
>>     New Cluster in webadmin
>
> so actually, these would be affected in having more options, but these 
> options would come from enum's.
> only change to look and feel of them would probably be the arch field 
> (derived from template/cluster, not something user should be able to 
> set, just view?)
> logic changes would be based on the filtering of relevant values as 
> mentioned above.
>
> thanks,
>    Itamar
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
>