On Fri, Aug 10, 2007 at 12:36:05PM -0400, Jim Paris wrote:
> if it's okay to add a variable lenght data structure at the
end, they might
> want to extend it in the future and that would be hard to handle.
I think appending unrelated data to the migration image is a bit of a
hack anyway. A better plan would be a file containing
<header> <XML config> <migration data>
Hum, beware you then need to make sure that you indicate in the
header the lenght of the XML config, because you can't ask the XML parser
to tell you when the XML file ends. Should not be hard but it's a pitfall
I have seen too many people trip on :-)
On save, libvirt writes <header> and <XML config>, then
closes it and
uses "dd of=path oflag=append conv=notrunc" or just "cat >>
path" as
the migration command.
On restore, libvirt reads the header and XML config, and then
feeds the remaining migration data to KVM using "-incoming stdio".
I had wanted to avoid the trouble of feeding data via stdin, but
maybe a well placed dup2(fd,STDIN_FILENO) would do the trick
automatically.
This file format would also make it easier for e.g. virt-manager to
determine that a file is a valid libvirt restore image.
Or just to be able to get informations from an image without having
to scan in the restore image to find the index etc. Putting (some)
metadata first is usually a good thing when designing a compound format.
I feel way better with such a proposal.
Daniel
--
Red Hat Virtualization group
http://redhat.com/virtualization/
Daniel Veillard | virtualization library
http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit
http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine
http://rpmfind.net/