domain: how long is new xml in saved file

[Eric Blake]

On 4/24/20 7:37 AM, Daniel P. Berrangé wrote:
> 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.

We've had guest XML reaching 1M before, but I agree that the initial 
saved image creation should include padding to a nice boundary to make 
future edits less likely to overflow the reserved heading.

On new enough Linux, some file systems support 
fallocate(FALLOC_FL_INSERT_RANGE) which can splice in a hole (all later 
file contents are shifted in offsets); maybe our save code could take 
advantage of that to repair existing saved images with insufficient 
header size in a more efficient manner than manually shifting the rest 
of the file contents ourselves.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org