On 07/28/2011 12:00 PM, Laine Stump wrote:
---
v3: change virDomainSave to always output minimal information, but with fixed padding added, so that save file modification will always be more likely to succeed,
"always be more likely". Heh.
I guess dropping "always" would make that sentence more believable.
Looking at this problem from the outside, it seems that if we wanted a 100% reliable solution, we would need to introduce the idea of a linked header, which can be continued at the end of the file (of course that wouldn't work if there are ever cases where the file is being read from a pipe, and we can't seek, and it's entirely possible that 1024 is always enough extra to ensure everything works).
We hand the file over to qemu after seeking to the end of our header, and I don't think qemu tolerates garbage at the end of its saved state files (qemu only reads in the saved state as if by a pipe; in reality the saved state file is the same as what gets sent over a socket during migration, which really is a one-pass non-seeking algorithm). So a split header won't really work. But hopefully there's not too many ABI compatible changes that you can make that significantly increase the size of the XML. And in the worst case, you can always fall back to: virsh restore file --xml alternate in the case where virsh save-image-define file alternate complains about a too-large alternate.
ACK.
Thanks; pushed. -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org