official metadata fields for improved interoperation across applications
Objective
The objective of the request is to facilitate various filtering operations by libvirt clients of installed domains, including those installed by other applications.
The <metadata>
element in the domain definition allows inclusion of data that supports administrative operations of domains but does not determine their operation. However, without any data elements prescribed officially by the libvirt project, use of this feature for robust cooperation among various libvirt clients is not broadly feasible.
Example
As a simple and concrete case, I am currently operating a private system with two libvirt domains. One was provisioned through an automated process provided by the development tool Vagrant. The other was provisioned manually through Virtual Machine Manager. Both domains are QEMU/KVM, and because the differences in their management cycle cannot be resolved reliably by any data available to VMM, both are shown in the same graphical list within the application, one with an automatically-generated name, the other with one natural for human readability.
If both applications, Vagrant and VMM, understood common semantics by which a domain might be marked as generated manually versus automatically, then VMM might apply a filter, per user preference, to display only domains in the former category in certain lists.
Details
Because the libvirt project controls the domain definition schema, it may elect to place information of such kind directly into this top-level domain schema. However, such a choice would create bloat and chaos, by conflating elements that describe actual operation of the domain versus those that describe its origin and intended usage in lifecycle and other management events. Use of fields that are supported directly by the libvirt project, but that appear inside the metadata parent element, would appear as an appropriate solution.
We might imagine a scenario in which metadata elements, defined by the libvirt project, provide information such as which application created a domain, and whether the domain is intended to be managed directly by the user. We might further imagine a scenario in which clients are encouraged, but not required, to process and to update these fields where appropriate.
Discussion
For more advanced cases, we might imagine data that would help an application detect whether a domain was unexpectedly edited by another application since its insertion, if the latter application published its identify and a timestamp in the metadata section such that it might be detected by the prior. Manually changing the domain created by Vagrant might lead to results different from the highly-reproducible outcomes that Vagrant seeks to ensure, and these concepts would allow Vagrant to develop these protective features.
From a purely technical standpoint, the objective may be considered as reachable simply through a refined level of mutual cooperation among the various libvirt clients in widespread use, but more practically, the central administration of such concerns is more likely to lead to effects that improve user experience.