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

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.