[libvirt] [PATCH v4 12/20] wip: backup: Parse and output backup XML

John Ferlan jferlan at redhat.com
Thu Feb 28 14:30:01 UTC 2019



[...]

>>
>> 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

[...]




More information about the libvir-list mailing list