7:48 p.m.
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
2:04 a.m.
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
5 p.m.
On Mon, Aug 10, 2009 at 10:04 AM, Pritesh
Kothari<Pritesh.Kothari(a)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
5:10 a.m.
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 :|
5:48 a.m.
On Tue, Aug 11, 2009 at 1:10 PM, Daniel P. Berrange<berrange(a)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
5582
days inactive
5583
days old
4 comments
3 participants
participants (3)
-
Daniel P. Berrange -
Lucian Adrian Grijincu -
Pritesh Kothari