>-----Original Message----- >From: Itamar Heim [mailto:[email protected]] >Sent: sexta-feira, 12 de julho de 2013 12:10 >To: Leonardo Bianconi >Cc: Michal Skrivanek; [email protected]; 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:[email protected]] >>> Sent: quinta-feira, 11 de julho de 2013 14:18 >>> To: Leonardo Bianconi >>> Cc: Michal Skrivanek; [email protected]; 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:[email protected]] >>>> Sent: sábado, 25 de maio de 2013 10:12 >>>> To: Michal Skrivanek >>>> Cc: Leonardo Bianconi; [email protected]; 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 >>>>> <[email protected]> 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 ([email protected]) / Leonardo >>>>>> ([email protected]) >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Dave Neary [mailto:[email protected]] >>>>>> Sent: quarta-feira, 15 de maio de 2013 12:25 >>>>>> To: Leonardo Bianconi >>>>>> Cc: [email protected]; 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 >>>>>> [email protected] >>>>>> http://lists.ovirt.org/mailman/listinfo/arch >>>>> >>>>> _______________________________________________ >>>>> Arch mailing list >>>>> [email protected] >>>>> http://lists.ovirt.org/mailman/listinfo/arch >>>>> >>>> >>
_______________________________________________ Arch mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/arch
