----- Original Message ----- > On Wed, Nov 23, 2016 at 2:59 PM, Arik Hadas <[email protected]> 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 > > [email protected] > > http://lists.ovirt.org/mailman/listinfo/devel > > > > -- > Didi > _______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
