Re: [ovirt-devel] Heads-up: moving Libvirt xml creation to the engine

On 23 Nov 2016, at 14:53, Arik Hadas <ahadas(a)redhat.com&gt; wrote: ----- Original Message ----- > On Wed, Nov 23, 2016 at 2:59 PM, Arik Hadas <ahadas(a)redhat.com&gt; 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] > > 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 properties map. > 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 assume.

The rest, other than the creation flow, will also remain unaffected. > > Best, > >> >> >> [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 > > > > -- > Didi > _______________________________________________ Devel mailing list Devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/devel