[ovirt-devel] Heads-up: moving Libvirt xml creation to the engine

[Arik Hadas]

----- 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: ydary at redhat.com
> IRC : ydary
> 
> 
> On Wed, Nov 23, 2016 at 6:12 PM, Arik Hadas <ahadas at 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 <ahadas at 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 at ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/devel
> > >
> > _______________________________________________
> > Devel mailing list
> > Devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
> >
>