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@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list