Re: save/restore support for KVM

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]