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