On 11/23/2016 07:59 AM, Arik Hadas 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.
This would be interesting in several aspects: - parsing it to learn what we expect. - but not throwing an exception if a hook changed the expected result/device-type to something we don't know/expect in the engine... - to make "external VMs" better integrated - so we can at some point allow external manipulation/creation of a VM.
* 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@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel