Re: domain: how long is new xml in saved file

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2020-04-24 at 10:20 -0500, Eric Blake wrote:
> 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.

There's a bug filed for this:

  https://bugzilla.redhat.com/show_bug.cgi?id=1229255

Both you and Dan commented on it at some point, but I thought I'd
bring it up in case you forgot - it was a while ago :)

-- 
Andrea Bolognani / Red Hat / Virtualization





[Index of Archives]     [Virt Tools]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]

  Powered by Linux