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