[libvirt] vbox save/restore
Hello, I see that the vbox driver in virDomainSave doesn't use the destination file path and calls vbox's IConsole::SaveState. As I see it IConsole::SaveState is more like a "pause" command: you can save the state you're in and wait for the machine to stop running and you can resume it later. This limits the uses of the vbox support of libvirt. There is another way you can do virDomainSave/virDomainRestore: use snapshots. This way, you can specify the file in which you want to save the snapshot, you can continue to use the machine and do some crazy experiments and then restore the machine to the known good state. As of the current implementation, I don't think there's a way to do this in libvirt. I'd like to know if there's a real reason why virDomainSave is implemented this way (and virDomainRestore is unimplemented), or it just got implemented like this and no one cared much about it. -- . ..: Lucian
On Monday 10 August 2009 02:48:10 Lucian Adrian Grijincu wrote:
Hello,
I see that the vbox driver in virDomainSave doesn't use the destination file path and calls vbox's IConsole::SaveState. As I see it IConsole::SaveState is more like a "pause" command: you can save the state you're in and wait for the machine to stop running and you can resume it later. This limits the uses of the vbox support of libvirt.
There is another way you can do virDomainSave/virDomainRestore: use snapshots. This way, you can specify the file in which you want to save the snapshot, you can continue to use the machine and do some crazy experiments and then restore the machine to the known good state. As of the current implementation, I don't think there's a way to do this in libvirt.
I'd like to know if there's a real reason why virDomainSave is implemented this way (and virDomainRestore is unimplemented), or it just got implemented like this and no one cared much about it.
Hi Lucian, The reason for the current way for implementing virDomainSave is: The iConsole::takeSnapshot() method is still inadequate in the sense that it doesn't take file name as parameter. Secondly snapshots create UUID's and other relevant data which is stored in the Machine's xml config file and it is simply a no-no to change the xml settings manually and thus it is not an option to manually copy that snapshot from current location to the one specified by the virDomainSave libvirt call. so until there is a fully developed API which can cleanly save the snapshot to a file at given location, i guess the above method is likely to be near to what is expected of virDomainSave(). Regards, Pritesh
On Mon, Aug 10, 2009 at 10:04 AM, Pritesh Kothari<Pritesh.Kothari@sun.com> wrote:
so until there is a fully developed API which can cleanly save the snapshot to a file at given location, i guess the above method is likely to be near to what is expected of virDomainSave().
I see that TakeSnapshot receives a name, not a path as virDomainSave desires. As of now, the virDomainSave implementation in vbox does not follow to heart it's description: it ignores the filename completely. I was thinking of two implementations: 1. only allow simple names (e.g. no path separators) as a parameter for vbox virDomainSave. Pass that name to IConsole::takeSnapshot() and let vbox take care of everything needed. You can then use the name to enable virDomainRestore() -- which currently is not implemented. 2. parse the filename given to virDomainSave and split it into dir+fname. Change the snapshot folder of the vm IMachine::COMSETTER(SnapshotFolder) to `dir' and take a snapshot with the name=`fname'. This means that for each snapshot we have to change the snapshot folder. I'm not sure whether this works properly or not. At restore time we do the same things: split the param to virDomainRestore() into dir+fname, change the snapshot folder to `dir' and restore the `fname' snapshot. I'm not sure it the second is implementable: from what I tested, to change the snapshot folder you need to modify the vm (vboxmanage modifyvm $VMNAME --snapshotfolder $SNAPDIR) and that means that you have to shut it down, which breaks the semantics of virDomainSave(). If 2. is not implementable, I think the first solution is better that what we currently have, because it allows the user to use the vm and restore it to a known previous state, which cannot currently be done. -- . ..: Lucian
On Mon, Aug 10, 2009 at 03:48:10AM +0300, Lucian Adrian Grijincu wrote:
Hello,
I see that the vbox driver in virDomainSave doesn't use the destination file path and calls vbox's IConsole::SaveState. As I see it IConsole::SaveState is more like a "pause" command: you can save the state you're in and wait for the machine to stop running and you can resume it later. This limits the uses of the vbox support of libvirt.
There is another way you can do virDomainSave/virDomainRestore: use snapshots. This way, you can specify the file in which you want to save the snapshot, you can continue to use the machine and do some crazy experiments and then restore the machine to the known good state. As of the current implementation, I don't think there's a way to do this in libvirt.
I'd like to know if there's a real reason why virDomainSave is implemented this way (and virDomainRestore is unimplemented), or it just got implemented like this and no one cared much about it.
To be honest, the vbox driver shouldn't implement virDomainSave like this at all, as ignoring the filename parameter is not in compliance with the API contract. Since there's no corresponding Restore impl I'd say we'd be better off just removeing the current virDomainSave impl since its not usable by libvirt apps in its form THe current virDomainSave/Restore APIs are really pretty limited in their flexibility, and are well overdue for deprecation and replacement with something that can be implemented sanely across all hypervisors. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On Tue, Aug 11, 2009 at 1:10 PM, Daniel P. Berrange<berrange@redhat.com> wrote:
To be honest, the vbox driver shouldn't implement virDomainSave like this at all, as ignoring the filename parameter is not in compliance with the API contract. Since there's no corresponding Restore impl I'd say we'd be better off just removeing the current virDomainSave impl since its not usable by libvirt apps in its form
There's no corresponding virDomainRestore, but "virsh start $vmname" works: it starts the machine from the snapshot. Instead of being NULL, the pointer to virDomainRestore should be initialized with the function that is called for "start".
THe current virDomainSave/Restore APIs are really pretty limited in their flexibility, and are well overdue for deprecation and replacement with something that can be implemented sanely across all hypervisors.
Your very right! As of now: * virDomainRestore works only on three out of 6 hypervisors. * virDomainSave is implemented on 4/6, but vbox's implementation is not conformant and lacks a corresponding restore. Until a better API is defined in libvirt and/or virtualbox, would you be interested in a patch that would tread the filename for the snapshot as a name and which would enable restore support as I described in https://www.redhat.com/archives/libvir-list/2009-August/msg00185.html ? -- . ..: Lucian
participants (3)
-
Daniel P. Berrange -
Lucian Adrian Grijincu -
Pritesh Kothari