Re: [libvirt] [PATCH v4 12/20] wip: backup: Parse and output backup XML
[...]
>
> Ahh... so this is where it's referenced... I recall this from RNG...
Which also raises the question of whether the RNG has to call it out, if
the only thing using it is internal code, or if the user will ever see
it. We have the interesting problem of outputting some things as
user-visible which are output-only, but then having to validate them in
the RNG on reparse even if we are going to ignore them, so that the user
doesn't have to trim them out. I'll have to double-check my intent
here, and will leave an appropriate comment (probably along the lines of
"id is valid in output and hence part of the RNG, but ignored on input
except when parsing internal XML for reconstructing job state across
libvirtd restarts").
There's quite a bit of stuff kept in private domain status files/output
that's managed by qemuDomainObjPrivateXMLFormat that is meant to handle
internal status that would be read on restarts that is important enough
to save somewhere, but not something added to the formal RNG.
[...]
>> +
>> + virBufferAsprintf(buf, " type='%s'>\n",
virStorageTypeToString(type));
>> + virBufferAdjustIndent(buf, 2);
>> +
>> + if (disk->store->format > 0)
>> + virBufferEscapeString(buf, "<driver
type='%s'/>\n",
>> +
virStorageFileFormatTypeToString(disk->store->format));
>> + /* TODO: should node names be part of storage file xml, rather
>> + * than a one-off hack for qemu? */
>
> Do we really want to store them in two places? I think it's been hard
> enough with just one.
>
> Hazards of a design where the checkpoint and/or backup are not
> subelements of the disk I suppose.
I've already had quite a bit of a battle making checkpoints work sanely
across qemu restarts (let alone libvirtd restarts); v5 already has some
different code here. Basically, libvirt has to recompute the node name
any time it connects to a new qemu instance (well, new compared to that
libvirtd process), but caching the node names internally is useful. This
may clean up somewhat if I rebase on top of Peter's blockdev work, but
I'm also trying to make my approaches work without being stuck waiting
for his work to land. (Ideally, when blockdev DOES land, the API parts
are all stable, and only the internals have to change - so I _really_
need to make sure that no XML locks us in to a particular node name
being stored on disk, as that might be incompatible with blockdev
refactoring down the road).
It's a complex maze of twisty passages, in the distance you hear a
babbling engineer ...
[based loosely on an old or shall I say original computer game of
Colossal Cave Adventure]
Exception processing is never easy... We should ask the OS to keep track
of what was run before and knowing that some failure occurred be able to
restart where things left off just before the failure and of course
avoid the code that caused the failure ;-). The future of AI maybe.
Nodenames certainly will make things complex... I guess I've thought
about that as an under the covers thing and all that the XML really
cares about is the target device (regardless of what's behind it)
because that's someone else's problem.
John
[...]