oVirt on IBM POWER (PPC64) - new feature contributors

Tue Jul 16 13:25:18 UTC 2013


>-----Original Message-----
>From: Itamar Heim [mailto:iheim at redhat.com]
>Sent: sexta-feira, 12 de julho de 2013 12:10
>To: Leonardo Bianconi
>Cc: Michal Skrivanek; arch at ovirt.org; Roy Golan
>Subject: Re: oVirt on IBM POWER (PPC64) - new feature contributors
>
>On 07/12/2013 03:52 PM, Leonardo Bianconi wrote:
>>
>>
>>> -----Original Message-----
>>> From: Itamar Heim [mailto:iheim at redhat.com]
>>> Sent: quinta-feira, 11 de julho de 2013 14:18
>>> To: Leonardo Bianconi
>>> Cc: Michal Skrivanek; arch at ovirt.org; Roy Golan
>>> Subject: Re: oVirt on IBM POWER (PPC64) - new feature contributors
>>>
>>> On 07/11/2013 08:04 PM, Leonardo Bianconi wrote:
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Itamar Heim [mailto:iheim at redhat.com]
>>>> Sent: sábado, 25 de maio de 2013 10:12
>>>> To: Michal Skrivanek
>>>> Cc: Leonardo Bianconi; arch at ovirt.org; Roy Golan
>>>> Subject: Re: oVirt on IBM POWER (PPC64) - new feature contributors
>>>>
>>>> On 05/22/2013 10:46 AM, Michal Skrivanek wrote:
>>>>>
>>>>> On May 21, 2013, at 17:33 , Leonardo Bianconi <leonardo.bianconi at eldorado.org.br> wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> We are planning to deliver support for PPC64 in 4 phases. We will manage to deliver a set of patches at the end of each phase.
>>>>>>
>>>>>> Phase 1
>>>>>>
>>>>>> 	 Change oVirt to handle other architectures by encapsulating all
>>>>>> the architecture specific code and queries about the
>>> capabilities of the hypervisor into a new class called ArchStrategy
>>> (based on the Strategy Design Pattern). Every operation involving
>>> clusters and hosts will be validated by this new class. Some hard-coded parameters are going to be replaced by queries in the
>backend in order to accommodate the support for new architectures into the engine.
>>>>>
>>>>> If you would like to discuss some internals or if anything is
>>>>> unclear please feel free to set up a quick mtg with myself, Omer
>>>>> and
>>> Roy.
>>>>> Sometimes (e.g. in the case of VmInterfaceType as mentioned on
>>>>> feature page) it would be actually beneficial for oVirt on x86 as
>>> well to have a greater flexibility directly in the code, without Strategy encapsulation.
>>>>>
>>>>>>
>>>>>>
>>>>>> Phase 2
>>>>>>
>>>>>> 	Currently, each host hypervisor capabilities are obtained using
>>>>>> hard-coded data structures. These structures will be replaced
>>> either by some form of integration with libosinfo or by reading
>>> internal configuration files describing these capabilities. It will be handled after Roy's patch.
>>>>> Roy's osinfo will soon be merged.
>>>>
>>>>> link to patches?
>>>>> does it cover adding arch at cluster level?
>>>>
>>>> Sorry about the late reply. We have already handled the gap between
>>>> the osinfo patch, the architecture parameters are being
>>> stored the same way as the OS info.
>>>>
>>>> We didn't add a specific architecture field on each cluster, because
>>>> based on the cpu name and cluster compatibility version of the
>>> cluster the architecture can be determined. Do you think it is really
>>> necessary to add another way to describe the architecture of each cluster?
>>>
>>> i think it would be much easier to specify the list of OSs per arch
>>> type, rather than per list of cpu's. it will also be easier to know if a VM can be created from a template based on their arch, rather
>than cpu lists (since x86_64 has a new cpu family every 6 months usually).
>>
>> We are not specifying the OS (or any other architecture specific
>> detail) based on the cpu family directly. The ServerCpuList was modified to associate each processor family name to an architecture
>(currently there are only two possible values for this association, x86_64 and ppc64). For example:
>>
>> "3:Intel Conroe Family:vmx,nx,model_Conroe:Conroe:x86_64"
>>
>> Every architecture specific operation checks which is the associated architecture, and all the operations are done based only on this
>value. When initializing the engine this parameter is read by CpuFlagsManagerHandler. The OS property file (osinfo-
>defaults.properties) contains the architecture for each OS, so internally the ArchStrategy (the class responsible for abstracting
>architecture specific code) checks the compatibility based on the architecture name, not on the cpu family.
>
>yes, i saw that, and it will work (just more code level comparisons than db ones, but as i said, just a matter of taste and i'm not strongly
>opinionated about this).
>
>the question is if arch specific are part of the OS (there is a
>RHEL6_x64 and a RHEL6_ppc7 OSs).
>
>if we separate the OSs, than why do we need the arch level repo, as you can do the limitation on the base default_os_ppc7?
Yes, that is right, we are going to change that (as commented on the patch)
>
>the other concern is behavior with export/import.
>since some issues are also discussed at patch level - lets move there and come back here if there is a conceptual issue worth revisiting.
>
Ok
>one question though to help me read the patches - what guest OSs can run on ppc7 arch (fedora? .el6? debian? other (i know
>windows isn't relevant, but what to expect there)?
About the guest OSes, we expect run all available linux for PPC64, but initially mainly Fedora and RHEL.
>
>Thanks,
>    Itamar
Thanks
Leonardo Bianconi/Vitor de Lima/Gustavo Pedrosa
>
>>
>>> similarly, it will be easier to know if you can move a VM between two
>>> clusters, according to their arch, rather trying to understand if their cpu families allow that or not (you can move a VM between
>intel and amd cpu families).
>>
>> Actually we have already thought about it. The ArchStrategy class has a method to compare two CPU families and return if they are
>compatible. On this case, like above, it is using the architecture name added for each cpu family on the ServerCpuList and will be
>compatible only if both CPUs have the same architecture.
>>
>> Another advantage besides having the architecture encapsulated in the ArchStrategy is that every place on the code that the cpu
>name and compatibility version is accessible, the ArchStrategy can be obtained and there is no need to retrieve the cluster object.
>>
>>
>>
>> We are checking the comments on the patch and we will reply soon.
>>
>>>
>>> so i think cluster arch is a good grouping for cpu families that are compatible.
>>>
>>> (and I wonder if anyone will get to add an arm arch as well...)
>>>
>>> in any case, I was very happy to see the set of patches arriving.
>>>
>>> Thanks,
>>>     Itamar
>>>
>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> Phase 3
>>>>>>
>>>>>> 	The code for providing the support for IBM POWER systems will be
>>>>>> added. The encapsulation done in the previous phase will
>>> reduce the effort to include this feature into the engine. The other changes that will be introduced in this phase include:
>>>>>>
>>>>>> 	- Modifications in the frontend to avoid running a VM created on a POWER host in a x86-64 host (and vice-versa),
>>>>>> 	- All the dynamically provided capacities of the first phase will
>>>>>> be implemented according to the capacities of the QEMU/KVM
>>> on POWER
>>>>>> 	- The POWER processors will be available as an option in the list
>>>>>> of processor names (this will imply in significant changes in the
>>>>>> backend)
>>>>>>
>>>>>>
>>>>>> Phase 4
>>>>>>
>>>>>> 	Adapt secondary features to polish the support for POWER:
>>>>>>
>>>>>> 	- OVF import and export of VMs running in POWER hosts
>>>>>> 	- Dynamic searches capable of finding hosts, pools, vms and
>>>>>> clusters according to their architectures
>>>>>>
>>>>>>
>>>>>> Is there any ongoing oVirt architecture refactoring ? (that may
>>>>>> conflict with Phase 1, for instance)
>>>>> no, nothing major going on
>>>>>
>>>>>>
>>>>>> Any comments ?
>>>>> Looking forward to your patches!:-)
>>>>>
>>>>> Thanks,
>>>>> michal
>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Vitor (vitor.lima at eldorado.org.br) / Leonardo
>>>>>> (leonardo.bianconi at eldorado.org.br)
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Dave Neary [mailto:dneary at redhat.com]
>>>>>> Sent: quarta-feira, 15 de maio de 2013 12:25
>>>>>> To: Leonardo Bianconi
>>>>>> Cc: arch at ovirt.org; Adam Litke
>>>>>> Subject: Re: oVirt on IBM POWER (PPC64) - new feature contributors
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> On 05/14/2013 08:05 PM, Leonardo Bianconi wrote:
>>>>>>> We would like to introduce ourselves: Leonardo Bianconi and Vitor Lima.
>>>>>>
>>>>>> Welcome!
>>>>>>
>>>>>>> We would like to work on the features "Engine support for PPC64"
>>>>>>> (http://wiki.ovirt.org/Features/Engine_support_for_PPC64)
>>> and the "Vdsm for PPC64"
>>> (http://wiki.ovirt.org/Features/Vdsm_for_PPC64). This work has already been started by some developers at IBM.
>>>>>>
>>>>>> <snip>
>>>>>>
>>>>>>> About libosinfo:
>>>>>>> =============
>>>>>>>
>>>>>>> In the previous discussion about this topic
>>>>>>> (http://lists.ovirt.org/pipermail/arch/2012-November/000976.html)
>>>>>>> , occurred in
>>> November 2012, it was suggested that integrating the libosinfo into
>>> the engine would be a better way to handle the differences between the architectures that would be supported in the future.
>>>>>>>
>>>>>>> Is this approach still valid? If so, when will it be available? It seems to be a dependency for oVirt "Engine_support_for_PPC64"
>>> feature implementation.
>>>>>>
>>>>>>
>>>>>> This is great news. I don't know who, specifically, has been
>>>>>> working on this issue in IBM - perhaps Adam Litke (CCed) can
>>>>>> update
>>> you on the progress that has been made.
>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>> Dave.
>>>>>>
>>>>>> --
>>>>>> Dave Neary - Community Action and Impact Open Source and
>>>>>> Standards, Red Hat - http://community.redhat.com
>>>>>> Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>>
>>