5 p.m.
Hi,
Arik there is also custom metadata section for MOM and QoS in the
libvirt domain XML and those values are now created as XML and later
manipulated using libvirt API. VDSM will still need to know at least
some basic stuff about the XML to be able to process it correctly (the
metadata descriptor and the structure for example).
Will the engine assume anything about the XML post-migration (for
example to speed-up restarts for highly available VMs)? Because the
hooks can change it significantly. Start hooks will be used anyway,
but migration hook changes might not be reflected during the restart.
Martin
On Wed, Nov 23, 2016 at 1:59 PM, Arik Hadas <ahadas(a)redhat.com> wrote:
Hi All,
We are working on something that is expected to have a big impact, hence this heads-up.
First, we want you to be aware of this change and provide your feedback to make it as
good as possible.
Second, until the proposed mechanism is fully merged there will be a chase to cover all
features unless new features are also implemented with the new mechanism. So please, if
you are working on something that adds/changes something in the Libvirt's domain xml,
do it with this new mechanism as well (first version would be merged soon).
* Goal
Creating Libvirt XML in the engine rather than in VDSM.
** Today's flow
Engine: VM business entity -> VM properties map
VDSM: VM properties map -> Libvirt XML
** Desired flow
Engine: VM business entity -> Libvirt XML
* Potential Benefits
1. Reduce the number of conversions from 2 to 1, reducing chances for mistakes in the
process.
2. Reduce the amount of code in VDSM.
3. Make VM related changes easier - today many of these changes need to be reviewed in 2
projects, this will eliminate the one that tends to take longer.
4. Prevent shortcuts in the form of VDSM-only changes that should be better reflected in
the engine.
5. Not to re-generate the XML on each rerun attempt of VM run/migration.
6. Future - not to re-generate the XML on each attempt to auto-start HA VM when using
vm-leases (need to make sure we're using the up-to-date VM configuration though).
7. We already found improvements and cleanups that could be made while touching this area
(e.g., remove the boot order from devices in the database).
* Challenges
1. Not to move host-specific information to the engine. For example, path to storage
domain or sockets of channels.
The solution is to use place-holders that will be replaced by VDSM.
2. Backward compatibility.
3. The more challenging part is the other direction - that will be the next phase.
* Status
As a first step, we began with producing the Libvirt XML in the engine by converting the
VM properties map to XML in the engine [1]
And using the XML that is received as an input in VDSM [2]
[1] https://gerrit.ovirt.org/#/c/64473/
[2] https://gerrit.ovirt.org/#/c/65182/
Regards,
Arik
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel