----- Original Message -----
On Wed, Nov 23, 2016 at 2:59 PM, Arik Hadas <ahadas(a)redhat.com>
> 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
> 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
> * 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
> * 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 
> And using the XML that is received as an input in VDSM 
Thanks for the heads up!
How does this, if at all, affect:
1. vdsm hooks
VDSM hooks will remain unaffected - they will get the same XML.
The only difference is that this XML will be one that was produced by the engine after the
replacement of its place-holders rather than one that is produced by VDSM from the
2. The interaction of engine, hosted-engine HA agent, engine vm
configuration saved in shared storage, etc.? Will this require a
change in ha-agent and the saved configuration?
In the foreseeable future VDSM should support creating the VM from VM properties map as
well - so legacy code will keep working, including the creation of the hosted-engine.
However, at some point the creation of the hosted-engine would also need to change I
The rest, other than the creation flow, will also remain unaffected.
>  https://gerrit.ovirt.org/#/c/64473/
>  https://gerrit.ovirt.org/#/c/65182/
> Devel mailing list