[libvirt] question about save/restore domain

[Daniel P. Berrange]

On Tue, Jul 03, 2012 at 11:44:16PM +0300, Zeeshan Ali (Khattak) wrote:
> On Tue, Jul 3, 2012 at 9:18 PM, Eric Blake <eblake at redhat.com> wrote:
> > On 07/03/2012 11:35 AM, Jovanka Gulicoska wrote:
> >> On Tue, Jul 3, 2012 at 6:01 PM, Eric Blake <eblake at redhat.com> wrote:
> >>>
> >>> On 07/03/2012 06:42 AM, Jovanka Gulicoska wrote:
> >>>> Hi,
> >>>>
> >>>> my name is Jovanka Gulicoska and I'm SoC student. I'm working on
> >>>> implementing save/load of VM in Gnome-Boxes.
> >>>> Something confused me about snapshots. In the documentation about life
> >>>> cycle, in section about Save/Restore is said that domain saved with
> >>>> virDomainSave/virDomainSaveFlags can be restored only once.
> >>>
> >>> Can you point out the URL to that documentation?  It's slightly
> >>> incorrect, and worth patching to make clearer if that would help the
> >>> next person to read them.
> >>
> >> This is in the draft of the documentation:
> >> http://libvirt.org/guide/html-single/#Application_Development_Guide-Lifecycle-Save
> >> --- "For basic usage this implies that a guest can only be restored
> >> once from any given saved state image."
> >
> > Ah, and I think reading that sentence in context clarifies the situation:
> >
> > "Thus when the guest is restored, the underlying guest storage must be
> > in exactly the same state as it was when the guest was initially saved.
> > For basic usage this implies that a guest can only be restored once from
> > any given saved state image. To allow a guest to be restored from the
> > same saved state multiple times, the application must also have taken a
> > snapshot of the guest storage at time of saving, and explicitly revert
> > to this storage snapshot when restoring."
> >
> > Either you manually revert the storage back to match the save image
> > state before restoring, or you use things in a more basic manner (never
> > touch the storage manually, and therefore restore works only once
> > because the storage was unchanged between the save/restore cycle but is
> > now altered after the successful restore).
> >
> > But you're still welcome to provide a patch; the source code for that
> > page can be found at this repo:
> >  http://libvirt.org/git/?p=libvirt-appdev-guide.git;a=summary
> >
> >>>> So is it better just to use virDomainSnapshotCreateXML instead of
> >>>> virDomainSave/virDomainSaveFlags?
> >>>
> >>> It all depends on what your end goal is with doing a save/load of a VM.
> >>>  Do you need fast saves, or is it okay if the save takes several
> >>> seconds?  Will you be loading the state exactly once, or do you plan to
> >>> make it something that the user can revert to multiple times in a row?
> >>
> >> The main idea is to allow the user to save the virtual machine and be
> >> able to load it when he wants and be able to share it with others who
> >> uses Boxes, so the other person can also load it on his machine (in
> >> Boxes).
> >
> > Letting _another_ person load the saved image sounds like some degree of
> > cloning.  Are you trying to clone from an offline state (in which case,
> > it is just as easy to create a new domain from XML pointing to the
> > cloned disks), or are you trying to clone from an online state (where
> > the other user gets to load the domain already booted to the point that
> > the first user had it)?
> 
> Yeah, this feature is about cloning the VM but using a single file
> that has everything about the domain: disk, ram and the config.

I don't really see that having a single file is at all relevant
to locally cloning VMs. If, however, you are actually trying to
share & distribute VM images between users, this is an entirely
separate concept from save/restore and cloning, and different
factors come into play.

For a start you do not want to be distributing the normal libvirt
XML for the VM. The libvirt XML represents the host-specific config
for a specific instantiation of the VM. When distributing images
you have to have a config format that describes the host-agnostic
requirements of the VM. This is the distinction between libvirt
XML and something like the OVF appliance metadata format.  You'll
find that anyone distributing VM appliances uses a "single file"
simply by virtue of distributing a ZIP/tar.gz file containing the
disk image + OVF metadata + whatever else they desire.


Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|