1:30 a.m.
On Wed, Nov 23, 2016 at 2:59 PM, Arik Hadas <ahadas(a)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
This is an interesting path to take, but centralizing the logic to a single
component often limits and does not allow scaling.
A large amount of solutions these days attempt to distribute work, reducing
central work to a minimum, but this approach suggests the opposite.
In the networking area, from my limited experience, changes are pushed
faster to VDSM compared to Engine.
In many cases it is just logically simpler: Engine needs to handle and be
concern about all the system as a whole, while VDSM just takes care of the
host.
Therefore, in my mind, the goal is to distribute as much as possible to the
edges, keeping in the centre the minimum required to connect then all
together.
This approach will remove a conversion and with it an abstraction layer. I
find abstraction useful, decoupling components and increasing modularity.
As an example from the OvS integration work, changing the underlying
networking implementation should not concern the upper business logic
components,
it should be well hidden in the hypervisor, exposing only capabilities and
nothing more that hints about the what and how.
Thanks,
Edy.