On 07/11/2013 08:18 PM, Itamar Heim wrote:
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).
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).
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.
i took a look at the patches and commented on some things on them.
assuming i undestood it correclty, i think i under stand how you tried
to avoid the need for arch by having it implied from the cpu family.
could be just a matter of taste, i guess even if i didn't want user to
set it per cluster, i'd still add a field for it and persist it, then
use the persisted field instead of all the code/strategies around it?
another question is around the new arch repo - do we need per arch
definitions, or in any case OSs would be per arch (even if they are the
same), hence any fine tuning per arch could be done at the "default os"
of that arch?
it seems similarly, instead of keeping an arch field for a VM or
template, you are just assuming it based on the cluster its in.
for VMs, this could be enough as long as they are in the system.
I'm a bit torn about templates, since it seems you are re-using the
cluster approach for them as well. however, for a template, which is a
DC level entity, the cluster is just a default cluster.
more so, with the advent of instance types, which are just images,
without a default cluster.
it also seems we'll be losing the information on which arch a
vm/template belong to when exporting it (user will have to import it to
the "right cluster" for that cluster to imply the arch)?
Thanks,
Itamar
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
