Daniel Veillard wrote: > On Thu, Aug 09, 2007 at 10:55:10PM +0100, Daniel P. Berrange wrote: > > Just been committed to KVM repos I see. Should be an easy patch to backport > > too. As long as we can detect failure if this is missing & report it back > > then I'm fine depending on this. > > Would checking for the kvm version from the console sufficient ? Since KVM > makes even more releases than libvirt in average I guess that would be > fine.
I'm not sure the kvm qemu binary even reports the kvm version anywhere. I'll ask on kvm-devel to see if qemu/VERSION could get updated with each KVM release. > > > - I append the domain's UUID at the end of the migration image. > > > This doesn't affect KVM at all (it ignores the extra data). > > > Does that seem reasonable? It's unclear how the saved image > > > is supposed to get associated with a particular VM configuration > > > without doing something like this. > > > > Actually I'd store the entire XML config appended to the end of the image. > > Its quite possible the saved image may be restored on a different machine > > so libvirt will need the XML config there & its not much work to > > automatically > > append it all & use it when restoring later. > > +1 . The only problem is that the XML has no predefined size, so it may be > hard to stack more stuff behind it. I would ask first on the KVM list to check > 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> 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. -jim -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
