on November 8, oVirt 4.2 saw the introduction of an important behind-the-scenes enhancement.

The change is associated with the exchange of information between the engine and the VDSM. It addresses the issue of multiple abstraction layers, with each layer needing to convert its input into a suitably readable format in order to report to the next layer.

This change improves data communication between the engine and Libvirt – the tool that manages platform virtualization.

Background

Previously, the configuration file for a newly created virtual machine (VM) originated in the engine as a map or dictionary.
Then, in the VDSM, it was converted into an XML file that was readable by Libvirt. This process required a greater coding
effort which in turn slowed down the development process.

What’s changed?

Now, this map or dictionary has been replaced by engine XML, an XML configuration file that complies with the Libvirt API.
VDSM now simply routes this Libvirt-readable file to/from Libvirt, in VM lifecycle (virt) related flows.

As an oVirt user, it’s business as usual.

However, if you are a developer dealing with debugging issues that involve running a VM, simply be aware that the Domain XML is now generated by ovirt-engine, and printed to engine.log.

Also, if you are debugging issues with device monitoring, note that ovirt-engine matches the devices reported by Libvirt with those stored in the database rather than VDSM.

The figure below shows the new flow for running a VM:

For an in-depth description of the new enhancement, read Arik Hadas’ Addressing Abstraction Hell in oVirt.