----- Original Message ----- > Does this mean we will be able to move the hooks to the engine side at some > point? That would be much better than needing it on VDSM.
Well, it sounds feasible to provide a hooking mechanism that enables to alter the domain XML in the engine, at some point. I'm not sure though that it could actually replace the hooks in VDSM since: 1. The XML won't be complete (host-specific configuration will be missing). 2. If the user wants to do some operation on the host with the hook, he'll need to send a request from the engine to the host, which is more complicated. > > Yaniv Dary > Technical Product Manager > Red Hat Israel Ltd. > 34 Jerusalem Road > Building A, 4th floor > Ra'anana, Israel 4350109 > > Tel : +972 (9) 7692306 > 8272306 > Email: yd...@redhat.com > IRC : ydary > > > On Wed, Nov 23, 2016 at 6:12 PM, Arik Hadas <aha...@redhat.com> 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 <aha...@redhat.com> 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 > > > > Devel@ovirt.org > > > > http://lists.ovirt.org/mailman/listinfo/devel > > > > > _______________________________________________ > > Devel mailing list > > Devel@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/devel > > > _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
