Ok, great. Yeah, you confused me by the migration sentence. Martin
On Wed, Nov 23, 2016 at 5:12 PM, Arik Hadas <[email protected]> wrote: > > > ----- Original Message ----- >> Hi, >> >> Arik there is also custom metadata section for MOM and QoS in the >> libvirt domain XML and those values are now created as XML and later >> manipulated using libvirt API. VDSM will still need to know at least >> some basic stuff about the XML to be able to process it correctly (the >> metadata descriptor and the structure for example). > > Besides the parsing of the devices that we would love to get rid of, I > believe the parsing of Libvirt XML done by VDSM would remain as is. > >> >> Will the engine assume anything about the XML post-migration (for >> example to speed-up restarts for highly available VMs)? Because the >> hooks can change it significantly. Start hooks will be used anyway, >> but migration hook changes might not be reflected during the restart. >> > > Not sure that I fully understand. > You have a VM with configuration conf1 running on host1. While being migrated > to host2 the configuration is changed to conf2. > Do you suggest that the next time the VM restarts it would be created based > on conf2? > > Changes in the devices would be reflected on the next run (assuming the > engine got the updated devices) - as today. > Other than the devices, no configuration that is used on VM creation (static > data) is read back by the engine so if it is changed it won't be reflected. > And at the moment we have no plan to change the content of the data that is > passed between the engine and VDSM, only its representation. > > Btw, I'm taking back my statement about migration: > "5. Not to re-generate the XML on each rerun attempt of VM run/migration." > VM migration flow is irrelevant since the engine doesn't pass the VM > configuration. It will remain as-is. > >> >> Martin >> >> >> >> On Wed, Nov 23, 2016 at 1: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] >> > >> > >> > [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 >> _______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
