On Fri, Apr 24, 2020 at 02:33:13PM +0200, Michal Privoznik wrote:
On 4/24/20 6:38 AM, Vincent Wu wrote:
>
The save format is fragile. At the beginning there is a header which
describes the file, then there is libvirt section (which contains the domain
XML and a cookie) and then there is QEMU section (where QEMU saved the guest
memory). Because of this, we have to have the check you are hitting in place
so that we don't accidentally overwrite the QEMU section.
BTW, does anyone recall why we were so restrictive on the XML length
in the first place ? I looked at history and didn't see why we did
it this way.
It occurrs to me that given guest typical RAM sizes measuring many
100's of MB, we could easily make the header section have 1 MB of
padding, and thus allow essentially arbitrary XML updates without
worry about hitting a size limit.
But, what you can do is provide the changed XML not in
virDomainSaveImageDefineXML() but provide it to virDomainRestoreFlags()
which doesn't check for XML length.
Michal
Regards,
Daniel
--
|:
https://berrange.com -o-
https://www.flickr.com/photos/dberrange :|
|:
https://libvirt.org -o-
https://fstop138.berrange.com :|
|:
https://entangle-photo.org -o-
https://www.instagram.com/dberrange :|