On 11/18/2012 09:47 AM, Itamar Heim wrote:
On 11/16/2012 07:34 PM, Fernando Granha Jeronimo wrote:
On 11/13/2012 10:02 AM, Paulo de Rezende Pinatti wrote:
On 11/13/2012 05:05 AM, Itamar Heim wrote:
On 11/09/2012 08:35 AM, Itamar Heim wrote:
On 11/07/2012 04:17 PM, Paulo de Rezende Pinatti wrote:
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.
iiuc, the most obvious change to mention is addition of an 'arch'
field
to cluster, which would affect the list of supported cpu families,
etc.?
(and to later know to filter all other aspects of entities based on
this
arch field)?
list of possible arch's would be per cluster compatibility level.
i'd expect default for API of this field to be x86_64 for backward
compatibility, so it is not mandatory.
I'd also prefer this field to be disabled or hidden if there is only
one
option available in it.
it gets more complicated, as VMs can be moved around between
clusters,
exported/imported, etc.
you would need to validate a VM isn't moved to a cluster with a
different arch, or imported into a cluster with a different arch as
well.
(probably more like that).
i assume the config to filter device types per arch like the network
devices is also for console (spice), audio, etc.
the system already has the concept of filtering per cluster level, so
filtering per cluster level and arch would mean reviewing all
places in
code for that.
I'm adding roy/omer/michal as the work on libosinfo (patches in
gerrit[1]) seems to make some of these changes not needed (if it is
merged).
rather just need to extend libosinfo with the information on ppc.
for sure worth reviewing both approaches to make sure the chosen
solution benefits both and we collaborate on same end goal.
thanks, we will check these patches and possibly change the approach
to use libosinfo.
Hello,
We have carefully analyzed the engine libosinfo patches and the
libosinfo itself to devise
our conclusion. During this process, we found the following key points:
* In order to have a clear notion of supported versions and devices,
we would
need to populate libosinfo's xmls for qemu and for devices, as well
as implement logic in
ovirt-engine to process the relationship between them. This would
be basically partially
reimplement the lib itself. In addition, given that we are not
using the lib but actually processing
the xmls directly there is no guarantee that their structure will
be preserved in the future,
which in the mid/long term may lead to code changes in the engine
to adapt to it.
I thought that is what roy's patches are doing?
i agree about the concern if the xml is changing.
* Even if libosinfo had all the information we needed in the xmls, we
would still need to validate
or filter values according to ovirt-engine's rules. For instance,
if the list of network devices
for PowerKVM in libosinfo had 5 elements and the engine only
intended to support/expose 2 specific models,
(for a given version for example) it has to be aware of these two
models, meaning that even using libosinfo
we still need something in engine to validate them (which
reinforces Itamar's filter suggestion).
good point - Roy, how would cluster level compatibility for features
would work in your libosinfo approach?
The primary concern of libosinfo patches is focused on virtual machine
parameters validation based on OS.
With regard to Power KVM support it doesn't address other areas like
hypervisor/cluster validation logic.
well, this could just be since it wasn't populated for a non x86_64
arch. would it make sense for you to discuss ppc support for libosinfo
regardless?
Thanks for your comments Itamar. It's good to discuss to find the best
ways to proceed.
I think the point Fernando made was that the libosinfo integration with
ovirt is just for vm parameter validation, and other areas needing to
change to support powerkvm such the hypervisor/cluster validation are
not addressed by libosinfo at all, even for x86.
It means that if we choose this path it would first be necessary to
change ovirt code to tighter integrate with libosinfo, and implement the
processing of links between xmls as well as validation of values against
ovirt rules (both mentioned in bullets above). Libosinfo in turn would
need its xmls populated to provide things like cpu flags, devices,
hypervisor and versions information. These would be needed just for the
code we have today, with no PowerKVM support yet.
This would be a longer road which would be interesting to take if we had
as a result a stable and centralized point of platform related
information. But rather ovirt would be possibly sitting on unstable
ground as Fernando well pointed the xmls can change at any time due to
libosinfo projects needs, which would force ovirt to re-adapt to new xml
formats. As to centralization, the information would still be partially
dispersed due to the need to determine what ovirt wants to support (this
kind of information cannot go in libosinfo).
Based on that and the exposed in the previous items, an approach that
seems to make sense if the libosinfo patches
are merged is to keep the focus of libosinfo usage as it is and for the
other areas to use the suggested in the
PowerKVM feature page
(http://wiki.ovirt.org/wiki/Features/Engine_support_for_PPC64). This
would benefit both and
converge to a project's solution.
Appreciate comments you may have.
Kind regards,
[1] some of the patches are:
http://gerrit.ovirt.org/9065
http://gerrit.ovirt.org/9063
http://gerrit.ovirt.org/9049
_______________________________________________
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
_______________________________________________
Arch mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/arch
