> On 23 Nov 2016, at 14:53, Arik Hadas <[email protected]> wrote: > > > > ----- 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.
it would be a bit more straightforward than today, instead of the fragile code creating vdsm internal API properties you would be able to use a regular domain xml definition which is easier to define and maintain than internal representation of features/parameters of vdsm > 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 > > _______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
