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@xxxxxxxxxx> wrote: > > On 07/03/2012 11:35 AM, Jovanka Gulicoska wrote: > >> On Tue, Jul 3, 2012 at 6:01 PM, Eric Blake <eblake@xxxxxxxxxx> 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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list