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

[Michal Skrivanek]

> On 23 Nov 2016, at 14:53, Arik Hadas <ahadas at redhat.com> wrote:
> 
> 
> 
> ----- Original Message -----
>> On Wed, Nov 23, 2016 at 2: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]
>> 
>> Thanks for the heads up!
>> 
>> How does this, if at all, affect:
>> 1. vdsm hooks
> 
> VDSM hooks will remain unaffected - they will get the same XML.
> The only difference is that this XML will be one that was produced by the engine after the replacement of its place-holders rather than one that is produced by VDSM from the properties map.
> 
>> 2. The interaction of engine, hosted-engine HA agent, engine vm
>> configuration saved in shared storage, etc.? Will this require a
>> change in ha-agent and the saved configuration?
> 
> In the foreseeable future VDSM should support creating the VM from VM properties map as well - so legacy code will keep working, including the creation of the hosted-engine.
> However, at some point the creation of the hosted-engine would also need to change I assume.

it would be a bit more straightforward than today, instead of the fragile code creating vdsm internal API properties you would be able to use a regular domain xml definition which is easier to define and maintain than internal representation of features/parameters of vdsm

> The rest, other than the creation flow, will also remain unaffected.
> 
>> 
>> Best,
>> 
>>> 
>>> 
>>> [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
>> 
>> 
>> 
>> --
>> Didi
>> 
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
> 
>