On 4/9/2025 9:34 AM, Markus Armbruster wrote:
Steven Sistare <steven.sist...@oracle.com> writes:
On 4/9/2025 3:39 AM, Markus Armbruster wrote:
Hi Steve, I apologize for the slow response.
Steve Sistare <steven.sist...@oracle.com> writes:
Using qom-list and qom-get to get all the nodes and property values in a
QOM tree can take multiple seconds because it requires 1000's of individual
QOM requests. Some managers fetch the entire tree or a large subset
of it when starting a new VM, and this cost is a substantial fraction of
start up time.
"Some managers"... could you name one?
My personal experience is with Oracle's OCI, but likely others could benefit.
Peter Krempa tells us libvirt would benefit.
To reduce this cost, consider QAPI calls that fetch more information in
each call:
* qom-list-get: given a path, return a list of properties and values.
* qom-list-getv: given a list of paths, return a list of properties and
values for each path.
* qom-tree-get: given a path, return all descendant nodes rooted at that
path, with properties and values for each.
Libvirt developers, would you be interested in any of these?
In all cases, a returned property is represented by ObjectPropertyValue,
with fields name, type, value, and error. If an error occurs when reading
a value, the value field is omitted, and the error message is returned in the
the error field. Thus an error for one property will not cause a bulk fetch
operation to fail.
Returning errors this way is highly unusual. Observation; I'm not
rejecting this out of hand. Can you elaborate a bit on why it's useful?
It is considered an error to read some properties if they are not valid for
the configuration. And some properties are write-only and return an error
if they are read. Examples:
legacy-i8042: <EXCEPTION: Property 'vmmouse.legacy-i8042' is not readable>
(str)
legacy-memory: <EXCEPTION: Property 'qemu64-x86_64-cpu.legacy-memory' is not
readable> (str)
crash-information: <EXCEPTION: No crash occurred> (GuestPanicInformation)
With conventional error handling, if any of these poison pills falls in the
scope of a bulk get operation, the entire operation fails.
I suspect many of these poison pills are design mistakes.
If a property is not valid for the configuration, why does it exist?
QOM is by design dynamic. I wish it wasn't, but as long as it is
dynamic, I can't see why we should create properties we know to be
unusable.
Why is reading crash-information an error when no crash occured? This
is the *normal* case. Errors are for the abnormal.
Anyway, asking you to fix design mistakes all over the place wouldn't be
fair. So I'm asking you something else instead: do you actually need
the error information?
I don't need the specific error message.
I could return a boolean meaning "property not available" instead of returning
the exact error message, as long as folks are OK with the output of the qom-tree
script changing for these properties.
- Steve
