<div dir="ltr">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.</div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><pre cols="72"><span style="font-family:arial,helvetica,sans-serif">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: <a href="mailto:ydary@redhat.com" target="_blank">ydary@redhat.com</a>
IRC : ydary</span></pre>
</div></div></div></div></div>
<br><div class="gmail_quote">On Wed, Nov 23, 2016 at 6:12 PM, Arik Hadas <span dir="ltr"><<a href="mailto:ahadas@redhat.com" target="_blank">ahadas@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
----- Original Message -----<br>
> Hi,<br>
><br>
> Arik there is also custom metadata section for MOM and QoS in the<br>
> libvirt domain XML and those values are now created as XML and later<br>
> manipulated using libvirt API. VDSM will still need to know at least<br>
> some basic stuff about the XML to be able to process it correctly (the<br>
> metadata descriptor and the structure for example).<br>
<br>
</span>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.<br>
<span class=""><br>
><br>
> Will the engine assume anything about the XML post-migration (for<br>
> example to speed-up restarts for highly available VMs)? Because the<br>
> hooks can change it significantly. Start hooks will be used anyway,<br>
> but migration hook changes might not be reflected during the restart.<br>
><br>
<br>
</span>Not sure that I fully understand.<br>
You have a VM with configuration conf1 running on host1. While being migrated to host2 the configuration is changed to conf2.<br>
Do you suggest that the next time the VM restarts it would be created based on conf2?<br>
<br>
Changes in the devices would be reflected on the next run (assuming the engine got the updated devices) - as today.<br>
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.<br>
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.<br>
<br>
Btw, I'm taking back my statement about migration:<br>
<span class="">"5. Not to re-generate the XML on each rerun attempt of VM run/migration."<br>
</span>VM migration flow is irrelevant since the engine doesn't pass the VM configuration. It will remain as-is.<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> Martin<br>
><br>
><br>
><br>
> On Wed, Nov 23, 2016 at 1:59 PM, Arik Hadas <<a href="mailto:ahadas@redhat.com">ahadas@redhat.com</a>> wrote:<br>
> > Hi All,<br>
> ><br>
> > We are working on something that is expected to have a big impact, hence<br>
> > this heads-up.<br>
> > First, we want you to be aware of this change and provide your feedback to<br>
> > make it as good as possible.<br>
> > Second, until the proposed mechanism is fully merged there will be a chase<br>
> > to cover all features unless new features are also implemented with the<br>
> > new mechanism. So please, if you are working on something that<br>
> > adds/changes something in the Libvirt's domain xml, do it with this new<br>
> > mechanism as well (first version would be merged soon).<br>
> ><br>
> > * Goal<br>
> > Creating Libvirt XML in the engine rather than in VDSM.<br>
> > ** Today's flow<br>
> > Engine: VM business entity -> VM properties map<br>
> > VDSM: VM properties map -> Libvirt XML<br>
> > ** Desired flow<br>
> > Engine: VM business entity -> Libvirt XML<br>
> ><br>
> > * Potential Benefits<br>
> > 1. Reduce the number of conversions from 2 to 1, reducing chances for<br>
> > mistakes in the process.<br>
> > 2. Reduce the amount of code in VDSM.<br>
> > 3. Make VM related changes easier - today many of these changes need to be<br>
> > reviewed in 2 projects, this will eliminate the one that tends to take<br>
> > longer.<br>
> > 4. Prevent shortcuts in the form of VDSM-only changes that should be better<br>
> > reflected in the engine.<br>
> > 5. Not to re-generate the XML on each rerun attempt of VM run/migration.<br>
> > 6. Future - not to re-generate the XML on each attempt to auto-start HA VM<br>
> > when using vm-leases (need to make sure we're using the up-to-date VM<br>
> > configuration though).<br>
> > 7. We already found improvements and cleanups that could be made while<br>
> > touching this area (e.g., remove the boot order from devices in the<br>
> > database).<br>
> ><br>
> > * Challenges<br>
> > 1. Not to move host-specific information to the engine. For example, path<br>
> > to storage domain or sockets of channels.<br>
> > The solution is to use place-holders that will be replaced by VDSM.<br>
> > 2. Backward compatibility.<br>
> > 3. The more challenging part is the other direction - that will be the next<br>
> > phase.<br>
> ><br>
> > * Status<br>
> > As a first step, we began with producing the Libvirt XML in the engine by<br>
> > converting the VM properties map to XML in the engine [1]<br>
> > And using the XML that is received as an input in VDSM [2]<br>
> ><br>
> ><br>
> > [1] <a href="https://gerrit.ovirt.org/#/c/64473/" rel="noreferrer" target="_blank">https://gerrit.ovirt.org/#/c/<wbr>64473/</a><br>
> > [2] <a href="https://gerrit.ovirt.org/#/c/65182/" rel="noreferrer" target="_blank">https://gerrit.ovirt.org/#/c/<wbr>65182/</a><br>
> ><br>
> > Regards,<br>
> > Arik<br>
> > ______________________________<wbr>_________________<br>
> > Devel mailing list<br>
> > <a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
> > <a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/devel</a><br>
><br>
______________________________<wbr>_________________<br>
Devel mailing list<br>
<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/devel</a><br>
</div></div></blockquote></div><br></div>