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?
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.
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)?
Thanks,
Itamar
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
