On Tue, Jul 3, 2012 at 9:18 PM, Eric Blake <eblake(a)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(a)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-Lifec...
>> --- "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
--
|: