[Qemu-devel] Adding Save States menu items

[Qemu-devel] Adding Save States menu items

[Programmingkid]

Would you accept a patch that added "Save State" and "Restore State" menu items to the cocoa interface? They would allow the user to save the running state of the emulator.

Re: [Qemu-devel] Adding Save States menu items

[Peter Maydell]

On 6 October 2016 at 15:22, Programmingkid <programmingkidx@gmail.com> wrote:
> Would you accept a patch that added "Save State" and
> "Restore State" menu items to the cocoa interface? They would
> allow the user to save the running state of the emulator.

If you can get consensus on first adding those to one of the other
UI frontends that's better maintained than the cocoa UI,
then I would accept a cocoa UI patch that added them second.

thanks
-- PMM

Re: [Qemu-devel] Adding Save States menu items

[Programmingkid]

On Oct 6, 2016, at 10:28 AM, Peter Maydell wrote:

> On 6 October 2016 at 15:22, Programmingkid <programmingkidx@gmail.com> wrote:
>> Would you accept a patch that added "Save State" and
>> "Restore State" menu items to the cocoa interface? They would
>> allow the user to save the running state of the emulator.
> 
> If you can get consensus on first adding those to one of the other
> UI frontends that's better maintained than the cocoa UI,
> then I would accept a cocoa UI patch that added them second.


Ok, I will ask around.

Does anyone else like the idea of having a "Save State" and
"Restore State" menu items added to QEMU's gui?

Re: [Qemu-devel] Adding Save States menu items

[Paolo Bonzini]

On 06/10/2016 16:42, Programmingkid wrote:
> 
> On Oct 6, 2016, at 10:28 AM, Peter Maydell wrote:
> 
>> On 6 October 2016 at 15:22, Programmingkid <programmingkidx@gmail.com> wrote:
>>> Would you accept a patch that added "Save State" and
>>> "Restore State" menu items to the cocoa interface? They would
>>> allow the user to save the running state of the emulator.
>>
>> If you can get consensus on first adding those to one of the other
>> UI frontends that's better maintained than the cocoa UI,
>> then I would accept a cocoa UI patch that added them second.
> 
> 
> Ok, I will ask around.
> 
> Does anyone else like the idea of having a "Save State" and
> "Restore State" menu items added to QEMU's gui?

What would they do exactly?

Paolo

Re: [Qemu-devel] Adding Save States menu items

[Programmingkid]

On Oct 6, 2016, at 11:35 AM, Paolo Bonzini wrote:

> 
> 
> On 06/10/2016 16:42, Programmingkid wrote:
>> 
>> On Oct 6, 2016, at 10:28 AM, Peter Maydell wrote:
>> 
>>> On 6 October 2016 at 15:22, Programmingkid <programmingkidx@gmail.com> wrote:
>>>> Would you accept a patch that added "Save State" and
>>>> "Restore State" menu items to the cocoa interface? They would
>>>> allow the user to save the running state of the emulator.
>>> 
>>> If you can get consensus on first adding those to one of the other
>>> UI frontends that's better maintained than the cocoa UI,
>>> then I would accept a cocoa UI patch that added them second.
>> 
>> 
>> Ok, I will ask around.
>> 
>> Does anyone else like the idea of having a "Save State" and
>> "Restore State" menu items added to QEMU's gui?
> 
> What would they do exactly?

"Save State" would save the current running state of the emulator to
file. "Restore State" would restore the saved running state. This
feature is really good for cheating at video games and saving your
work exactly as you left it.

Re: [Qemu-devel] Adding Save States menu items

[Paolo Bonzini]

On 06/10/2016 17:48, Programmingkid wrote:
> 
> On Oct 6, 2016, at 11:35 AM, Paolo Bonzini wrote:
> 
>>
>>
>> On 06/10/2016 16:42, Programmingkid wrote:
>>>
>>> On Oct 6, 2016, at 10:28 AM, Peter Maydell wrote:
>>>
>>>> On 6 October 2016 at 15:22, Programmingkid <programmingkidx@gmail.com> wrote:
>>>>> Would you accept a patch that added "Save State" and
>>>>> "Restore State" menu items to the cocoa interface? They would
>>>>> allow the user to save the running state of the emulator.
>>>>
>>>> If you can get consensus on first adding those to one of the other
>>>> UI frontends that's better maintained than the cocoa UI,
>>>> then I would accept a cocoa UI patch that added them second.
>>>
>>>
>>> Ok, I will ask around.
>>>
>>> Does anyone else like the idea of having a "Save State" and
>>> "Restore State" menu items added to QEMU's gui?
>>
>> What would they do exactly?
> 
> "Save State" would save the current running state of the emulator to
> file. "Restore State" would restore the saved running state. This
> feature is really good for cheating at video games and saving your
> work exactly as you left it.

Yes, but what would they do in QEMU terms?  What would they call, when
would they be available, and how would the GUI behave?

Paolo

Re: [Qemu-devel] Adding Save States menu items

[Programmingkid]

On Oct 6, 2016, at 11:49 AM, Paolo Bonzini wrote:

> 
> 
> On 06/10/2016 17:48, Programmingkid wrote:
>> 
>> On Oct 6, 2016, at 11:35 AM, Paolo Bonzini wrote:
>> 
>>> 
>>> 
>>> On 06/10/2016 16:42, Programmingkid wrote:
>>>> 
>>>> On Oct 6, 2016, at 10:28 AM, Peter Maydell wrote:
>>>> 
>>>>> On 6 October 2016 at 15:22, Programmingkid <programmingkidx@gmail.com> wrote:
>>>>>> Would you accept a patch that added "Save State" and
>>>>>> "Restore State" menu items to the cocoa interface? They would
>>>>>> allow the user to save the running state of the emulator.
>>>>> 
>>>>> If you can get consensus on first adding those to one of the other
>>>>> UI frontends that's better maintained than the cocoa UI,
>>>>> then I would accept a cocoa UI patch that added them second.
>>>> 
>>>> 
>>>> Ok, I will ask around.
>>>> 
>>>> Does anyone else like the idea of having a "Save State" and
>>>> "Restore State" menu items added to QEMU's gui?
>>> 
>>> What would they do exactly?
>> 
>> "Save State" would save the current running state of the emulator to
>> file. "Restore State" would restore the saved running state. This
>> feature is really good for cheating at video games and saving your
>> work exactly as you left it.
> 
> Yes, but what would they do in QEMU terms?  What would they call, when
> would they be available, and how would the GUI behave?


In the Machine menu, you would see these three additional menu items:

-----------------------
Save State...
Restore State...
Manage Save States...
------------------------

'Save State...' would call something equivalent to the monitor command savevm.
It would display a dialog box asking to give a name to this save. The default
name would probably be "save state mm-dd-yyyy - n". The m,d,y stand
for month, day, and year respectively. The n would be the save state
count for that day.
 
'Restore state...' would probably display a dialog box with all the save
states displayed in a list. The user could select one of them and
QEMU would restore that state.

'Manage Save States...' would display a dialog box with all the saves
states displayed in a list. There would be buttons on the bottom called "Delete", "Rename",
and "Duplicate". They would give the user the options that can
be done to each save state. The Delete button would correspond to
the monitor command delvm "name". Rename and Duplicate would have to
be researched a little more before I can say how they would be implemented.

Code in the gui would detect if the hard drive image was in a format that
supported save states. The menu items would probably be grayed out if
save states could not work with the current HD image file. 

Re: [Qemu-devel] Adding Save States menu items

[Paolo Bonzini]

On 06/10/2016 18:04, Programmingkid wrote:
> 'Save State...' would call something equivalent to the monitor command savevm.
> It would display a dialog box asking to give a name to this save. The default
> name would probably be "save state mm-dd-yyyy - n". The m,d,y stand
> for month, day, and year respectively. The n would be the save state
> count for that day.
>  
> 'Restore state...' would probably display a dialog box with all the save
> states displayed in a list. The user could select one of them and
> QEMU would restore that state.

These are of course savevm and loadvm.

> 'Manage Save States...' would display a dialog box with all the saves
> states displayed in a list. There would be buttons on the bottom called "Delete", "Rename",
> and "Duplicate". They would give the user the options that can
> be done to each save state. The Delete button would correspond to
> the monitor command delvm "name". Rename and Duplicate would have to
> be researched a little more before I can say how they would be implemented.

I think Delete is enough.

> Code in the gui would detect if the hard drive image was in a format that
> supported save states. The menu items would probably be grayed out if
> save states could not work with the current HD image file. 

Ok, this makes sense.  Thanks for explaining it!  I think this would be
nice to have in the GTK+ interface.

Paolo

Re: [Qemu-devel] Adding Save States menu items

[Programmingkid]

On Oct 6, 2016, at 12:17 PM, Paolo Bonzini wrote:

> 
> 
> On 06/10/2016 18:04, Programmingkid wrote:
>> 'Save State...' would call something equivalent to the monitor command savevm.
>> It would display a dialog box asking to give a name to this save. The default
>> name would probably be "save state mm-dd-yyyy - n". The m,d,y stand
>> for month, day, and year respectively. The n would be the save state
>> count for that day.
>> 
>> 'Restore state...' would probably display a dialog box with all the save
>> states displayed in a list. The user could select one of them and
>> QEMU would restore that state.
> 
> These are of course savevm and loadvm.
> 
>> 'Manage Save States...' would display a dialog box with all the saves
>> states displayed in a list. There would be buttons on the bottom called "Delete", "Rename",
>> and "Duplicate". They would give the user the options that can
>> be done to each save state. The Delete button would correspond to
>> the monitor command delvm "name". Rename and Duplicate would have to
>> be researched a little more before I can say how they would be implemented.
> 
> I think Delete is enough.
> 
>> Code in the gui would detect if the hard drive image was in a format that
>> supported save states. The menu items would probably be grayed out if
>> save states could not work with the current HD image file. 
> 
> Ok, this makes sense.  Thanks for explaining it!  I think this would be
> nice to have in the GTK+ interface.
> 
> Paolo

@ Paolo Thanks for the help.

@ Peter I don't know how to implement this in GTK. The GTK GUI maintainer doesn't even
reply to my emails. Could we start this in Cocoa and then port it to GTK? I think
the time is right. QEMU has progressed to the point that the save and restore
feature works. A lot of users would appreciate this feature if it were more
accessible.

Re: [Qemu-devel] Adding Save States menu items

[Peter Maydell]

On 6 October 2016 at 18:43, Programmingkid <programmingkidx@gmail.com> wrote:
> @ Peter I don't know how to implement this in GTK. The GTK GUI maintainer doesn't even
> reply to my emails. Could we start this in Cocoa and then port it to GTK? I think
> the time is right. QEMU has progressed to the point that the save and restore
> feature works. A lot of users would appreciate this feature if it were more
> accessible.

I'm afraid I don't have time to design-review and code-review significant
changes to the cocoa UI. So you would need to find somebody else to
review it anyway, in which case you might as well start with GTK
or whatever that reviewer's preference for UI frontend is.

thanks
-- PMM

Re: [Qemu-devel] Adding Save States menu items

[Programmingkid]

On Oct 6, 2016, at 1:49 PM, Peter Maydell wrote:

> On 6 October 2016 at 18:43, Programmingkid <programmingkidx@gmail.com> wrote:
>> @ Peter I don't know how to implement this in GTK. The GTK GUI maintainer doesn't even
>> reply to my emails. Could we start this in Cocoa and then port it to GTK? I think
>> the time is right. QEMU has progressed to the point that the save and restore
>> feature works. A lot of users would appreciate this feature if it were more
>> accessible.
> 
> I'm afraid I don't have time to design-review and code-review significant
> changes to the cocoa UI. So you would need to find somebody else to
> review it anyway, in which case you might as well start with GTK
> or whatever that reviewer's preference for UI frontend is.

Is there another person you could suggest? Gerd seems too unavailable for this. 

Re: [Qemu-devel] Adding Save States menu items

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1660 bytes --]

On 10/06/2016 11:17 AM, Paolo Bonzini wrote:
> 
> 
> On 06/10/2016 18:04, Programmingkid wrote:
>> 'Save State...' would call something equivalent to the monitor command savevm.
>> It would display a dialog box asking to give a name to this save. The default
>> name would probably be "save state mm-dd-yyyy - n". The m,d,y stand
>> for month, day, and year respectively. The n would be the save state
>> count for that day.
>>  
>> 'Restore state...' would probably display a dialog box with all the save
>> states displayed in a list. The user could select one of them and
>> QEMU would restore that state.
> 
> These are of course savevm and loadvm.

Which are somewhat limited in their power - they don't always work if
the user does hotplug in between.

>> Code in the gui would detect if the hard drive image was in a format that
>> supported save states. The menu items would probably be grayed out if
>> save states could not work with the current HD image file. 
> 
> Ok, this makes sense.  Thanks for explaining it!  I think this would be
> nice to have in the GTK+ interface.

I don't know - libvirt already learned the hard way that qcow2 images
alone are not ideal for saving machine state; and libvirt ended up
creating its own save state format that consists of a concatenation of
libvirt XML and the qemu migration format.  And the problem of how to
revert to a state with different devices than the guest currently has
seems rather difficult to squeeze into a GTK app that only manages a
single VM.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

Re: [Qemu-devel] Adding Save States menu items

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 2581 bytes --]

On 10/06/2016 09:22 AM, Programmingkid wrote:
> Would you accept a patch that added "Save State" and "Restore State" menu items to the cocoa interface? They would allow the user to save the running state of the emulator.

Doesn't virt-manager already do this?  What do we gain by duplicating
GUI functionality at this level that is already implemented at higher
levels?  Not that I'm opposed to the idea, but having a solid reason why
it is useful is important.

Speaking with libvirt experience: saving a guest is somewhat easy.  But
once you have a save-state file, then what?  Remember, the qemu GUI is
associated with a SINGLE qemu process.  When libvirt manages save files,
it is managing MULTIPLE qemu processes.  The sequence of 'create a save
file, hot-plug a device, then reverting to the save file' currently
REQUIRES that you destroy one qemu process and create another one, where
the new process is back to the pre-hotplug configuration that was in use
when the save file was created.  Otherwise the qemu 'loadvm' command
will likely fail (and worse, if it does not fail, you are likely to
trigger even-harder-to-diagnose guest corruptions that only strike down
the road, rather than at the time of the loadvm).

If your gui (whether cocoa or GTK) is associated with a single qemu
process, then you will have a VERY tough time figuring out how to start
a new qemu process to replace the current one while still keeping the
gui unchanged.  And the work to convert qemu over to managing multiple
VMs itself is rather pointless, when you already have libvirt and
virt-manager and other wrappers that are already good at that.

Libvirt also learned that the qemu 'migrate-to-disk' format (used by
'savevm' or 'migrate') is NOT self-descriptive - in order to fully and
safely revert to an earlier state, you HAVE to store the command line
(or a way to regenerate the command line) that was associated with the
qemu whose state you saved, along with tracking all hotplugs.  Since a
mere 'savevm' REQUIRES external information to safely be restored, you
would have to figure out a way to store this additional information
alongside whatever save files you plan on creating (and please don't
change the qcow2 file format to become a dumping grounds for this
additional information).

Your idea may be noble, but I think you are going down a rabbit's hole
of unimplementable misery, and advise that you probably won't succeed.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

Re: [Qemu-devel] Adding Save States menu items

[Programmingkid]

On Oct 6, 2016, at 3:59 PM, Eric Blake wrote:

> On 10/06/2016 09:22 AM, Programmingkid wrote:
>> Would you accept a patch that added "Save State" and "Restore State" menu items to the cocoa interface? They would allow the user to save the running state of the emulator.
> 
> Doesn't virt-manager already do this?  What do we gain by duplicating
> GUI functionality at this level that is already implemented at higher
> levels?  Not that I'm opposed to the idea, but having a solid reason why
> it is useful is important.

Virt-manager is a Linux exclusive. This program doesn't run on Windows or
Mac OS.

> Speaking with libvirt experience: saving a guest is somewhat easy.  But
> once you have a save-state file, then what?  Remember, the qemu GUI is
> associated with a SINGLE qemu process.  When libvirt manages save files,
> it is managing MULTIPLE qemu processes.  The sequence of 'create a save
> file, hot-plug a device, then reverting to the save file' currently
> REQUIRES that you destroy one qemu process and create another one, where
> the new process is back to the pre-hotplug configuration that was in use
> when the save file was created.  Otherwise the qemu 'loadvm' command
> will likely fail (and worse, if it does not fail, you are likely to
> trigger even-harder-to-diagnose guest corruptions that only strike down
> the road, rather than at the time of the loadvm).

There are multiple variables to consider. Hardware might be added or taken
away in between save states. Ensuring consistency between save states
is what the user should do.

> If your gui (whether cocoa or GTK) is associated with a single qemu
> process, then you will have a VERY tough time figuring out how to start
> a new qemu process to replace the current one while still keeping the
> gui unchanged.  And the work to convert qemu over to managing multiple
> VMs itself is rather pointless, when you already have libvirt and
> virt-manager and other wrappers that are already good at that.

The save states would be stored in the qcow2 image file of the guest
operating system. Multiple operatings could be managed this way by one
gui.

> Libvirt also learned that the qemu 'migrate-to-disk' format (used by
> 'savevm' or 'migrate') is NOT self-descriptive - in order to fully and
> safely revert to an earlier state, you HAVE to store the command line
> (or a way to regenerate the command line) that was associated with the
> qemu whose state you saved, along with tracking all hotplugs.  Since a
> mere 'savevm' REQUIRES external information to safely be restored, you
> would have to figure out a way to store this additional information
> alongside whatever save files you plan on creating (and please don't
> change the qcow2 file format to become a dumping grounds for this
> additional information).

The savevm feature is anything but perfect, but that doesn't mean we
shouldn't provide easy access to it. This feature is already there in
QEMU, so why not help the user be able to use it?

Re: [Qemu-devel] Adding Save States menu items

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1805 bytes --]

On 10/06/2016 03:10 PM, Programmingkid wrote:
> 
> On Oct 6, 2016, at 3:59 PM, Eric Blake wrote:
> 
>> On 10/06/2016 09:22 AM, Programmingkid wrote:
>>> Would you accept a patch that added "Save State" and "Restore State" menu items to the cocoa interface? They would allow the user to save the running state of the emulator.
>>
>> Doesn't virt-manager already do this?  What do we gain by duplicating
>> GUI functionality at this level that is already implemented at higher
>> levels?  Not that I'm opposed to the idea, but having a solid reason why
>> it is useful is important.
> 
> Virt-manager is a Linux exclusive. This program doesn't run on Windows or
> Mac OS.

Not true. I've seen it ported to Windows, and I'm sure Cole would
welcome a port to Mac.

> The savevm feature is anything but perfect, but that doesn't mean we
> shouldn't provide easy access to it. This feature is already there in
> QEMU, so why not help the user be able to use it?

If you want to HELP the user, then tell them to use a management app
that has already dealt with the problems of consistent snapshots, rather
than making the user reinvent it themselves by clicking a gui button
that does incomplete work.

Yes, qemu has a gui.  But I maintain that it is mostly a mistake, and
that time spent improving the gui in this project, rather than porting
and improving better upper-layer guis, is probably wasted.  The Unix
philosophy is "do one thing and do it well" - we don't always live up to
it, but on THIS mailing list, the thing we do well is emulation, not
guis.  You are going to be hard-pressed to find reviewers, even if you
spend time solving the technical issues.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

Re: [Qemu-devel] Adding Save States menu items

[Paolo Bonzini]

On 06/10/2016 22:26, Eric Blake wrote:
> > > Doesn't virt-manager already do this?  What do we gain by duplicating
> > > GUI functionality at this level that is already implemented at higher
> > > levels?  Not that I'm opposed to the idea, but having a solid reason why
> > > it is useful is important.
> > 
> > Virt-manager is a Linux exclusive. This program doesn't run on Windows or
> > Mac OS.
> 
> Not true. I've seen it ported to Windows, and I'm sure Cole would
> welcome a port to Mac.

I don't think that included a port of libvirtd, so you'd still need a
Linux system to run the VMs on.

Paolo

Re: [Qemu-devel] Adding Save States menu items

[Daniel P. Berrange]

On Fri, Oct 07, 2016 at 09:21:36AM +0200, Paolo Bonzini wrote:
> 
> 
> On 06/10/2016 22:26, Eric Blake wrote:
> > > > Doesn't virt-manager already do this?  What do we gain by duplicating
> > > > GUI functionality at this level that is already implemented at higher
> > > > levels?  Not that I'm opposed to the idea, but having a solid reason why
> > > > it is useful is important.
> > > 
> > > Virt-manager is a Linux exclusive. This program doesn't run on Windows or
> > > Mac OS.
> > 
> > Not true. I've seen it ported to Windows, and I'm sure Cole would
> > welcome a port to Mac.
> 
> I don't think that included a port of libvirtd, so you'd still need a
> Linux system to run the VMs on.

I would expect libvirtd to pretty much "just work" for the most part.
Any part of libvirt which depends on Linux specific APIs has conditional
compilation, or portability layers. OS-X is BSD underneath so majority
of functionality will trivially work - unlike windows where making libvirtd
work is very hard due to missing fork/exec paradigm. There's likely to be
gremlins hiding in the libvirt QEMU driver just because 99% of all work is
done in Linux, but we'd be more than happy with patches to fix any OS-X
portability problems.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|

Re: [Qemu-devel] Adding Save States menu items

[Programmingkid]

On Oct 7, 2016, at 5:14 AM, Daniel P. Berrange wrote:

> On Fri, Oct 07, 2016 at 09:21:36AM +0200, Paolo Bonzini wrote:
>> 
>> 
>> On 06/10/2016 22:26, Eric Blake wrote:
>>>>> Doesn't virt-manager already do this?  What do we gain by duplicating
>>>>> GUI functionality at this level that is already implemented at higher
>>>>> levels?  Not that I'm opposed to the idea, but having a solid reason why
>>>>> it is useful is important.
>>>> 
>>>> Virt-manager is a Linux exclusive. This program doesn't run on Windows or
>>>> Mac OS.
>>> 
>>> Not true. I've seen it ported to Windows, and I'm sure Cole would
>>> welcome a port to Mac.
>> 
>> I don't think that included a port of libvirtd, so you'd still need a
>> Linux system to run the VMs on.
> 
> I would expect libvirtd to pretty much "just work" for the most part.
> Any part of libvirt which depends on Linux specific APIs has conditional
> compilation, or portability layers. OS-X is BSD underneath so majority
> of functionality will trivially work - unlike windows where making libvirtd
> work is very hard due to missing fork/exec paradigm. There's likely to be
> gremlins hiding in the libvirt QEMU driver just because 99% of all work is
> done in Linux, but we'd be more than happy with patches to fix any OS-X
> portability problems.

I have actually tried to port Virt-manager and libvirt to Mac OS X. It does
anything but work. Sorry to have to say this but it was a nightmare trying
to make Virt-manager run. The number of dependencies involved makes installing
QEMU from scratch look easy. Virt-manager is a long ways off from running in
Mac OS X. 

Re: [Qemu-devel] Adding Save States menu items

[Peter Maydell]

On 6 October 2016 at 12:59, Eric Blake <eblake@redhat.com> wrote:
> Libvirt also learned that the qemu 'migrate-to-disk' format (used by
> 'savevm' or 'migrate') is NOT self-descriptive - in order to fully and
> safely revert to an earlier state, you HAVE to store the command line
> (or a way to regenerate the command line) that was associated with the
> qemu whose state you saved, along with tracking all hotplugs.  Since a
> mere 'savevm' REQUIRES external information to safely be restored, you
> would have to figure out a way to store this additional information
> alongside whatever save files you plan on creating (and please don't
> change the qcow2 file format to become a dumping grounds for this
> additional information).

Good point. I think this is a fairly strong argument for
keeping the "user friendly" interface to snapshots in the
VM management layer, not QEMU itself.

thanks
-- PMM

Re: [Qemu-devel] Adding Save States menu items

[Programmingkid]

On Oct 6, 2016, at 4:47 PM, Peter Maydell wrote:

> On 6 October 2016 at 12:59, Eric Blake <eblake@redhat.com> wrote:
>> Libvirt also learned that the qemu 'migrate-to-disk' format (used by
>> 'savevm' or 'migrate') is NOT self-descriptive - in order to fully and
>> safely revert to an earlier state, you HAVE to store the command line
>> (or a way to regenerate the command line) that was associated with the
>> qemu whose state you saved, along with tracking all hotplugs.  Since a
>> mere 'savevm' REQUIRES external information to safely be restored, you
>> would have to figure out a way to store this additional information
>> alongside whatever save files you plan on creating (and please don't
>> change the qcow2 file format to become a dumping grounds for this
>> additional information).
> 
> Good point. I think this is a fairly strong argument for
> keeping the "user friendly" interface to snapshots in the
> VM management layer, not QEMU itself.

Another great feature dies... just kidding. Thank you everyone for giving me
your feedback. 

Re: [Qemu-devel] Adding Save States menu items

[Kevin Wolf]

[-- Attachment #1: Type: text/plain, Size: 1126 bytes --]

Am 06.10.2016 um 21:59 hat Eric Blake geschrieben:
> Libvirt also learned that the qemu 'migrate-to-disk' format (used by
> 'savevm' or 'migrate') is NOT self-descriptive - in order to fully and
> safely revert to an earlier state, you HAVE to store the command line
> (or a way to regenerate the command line) that was associated with the
> qemu whose state you saved, along with tracking all hotplugs.  Since a
> mere 'savevm' REQUIRES external information to safely be restored, you
> would have to figure out a way to store this additional information
> alongside whatever save files you plan on creating (and please don't
> change the qcow2 file format to become a dumping grounds for this
> additional information).

Have we made any progress regarding this in the past few years? I know
we once intended to get to a state where the migration stream could
include information about which devices exist in the first place.

I guess that's somehow linked to the idea of starting with an empty
machine and then creating all devices and backends with QMP rather than
the command line before actually starting the VM.

Kevin

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [Qemu-devel] Adding Save States menu items

[Daniel P. Berrange]

On Thu, Oct 06, 2016 at 02:59:49PM -0500, Eric Blake wrote:
> On 10/06/2016 09:22 AM, Programmingkid wrote:
> > Would you accept a patch that added "Save State" and "Restore State" menu items to the cocoa interface? They would allow the user to save the running state of the emulator.
> 
> Doesn't virt-manager already do this?  What do we gain by duplicating
> GUI functionality at this level that is already implemented at higher
> levels?  Not that I'm opposed to the idea, but having a solid reason why
> it is useful is important.
> 
> Speaking with libvirt experience: saving a guest is somewhat easy.  But
> once you have a save-state file, then what?  Remember, the qemu GUI is
> associated with a SINGLE qemu process.  When libvirt manages save files,
> it is managing MULTIPLE qemu processes.  The sequence of 'create a save
> file, hot-plug a device, then reverting to the save file' currently
> REQUIRES that you destroy one qemu process and create another one, where
> the new process is back to the pre-hotplug configuration that was in use
> when the save file was created.  Otherwise the qemu 'loadvm' command
> will likely fail (and worse, if it does not fail, you are likely to
> trigger even-harder-to-diagnose guest corruptions that only strike down
> the road, rather than at the time of the loadvm).
> 
> If your gui (whether cocoa or GTK) is associated with a single qemu
> process, then you will have a VERY tough time figuring out how to start
> a new qemu process to replace the current one while still keeping the
> gui unchanged.  And the work to convert qemu over to managing multiple
> VMs itself is rather pointless, when you already have libvirt and
> virt-manager and other wrappers that are already good at that.
> 
> Libvirt also learned that the qemu 'migrate-to-disk' format (used by
> 'savevm' or 'migrate') is NOT self-descriptive - in order to fully and
> safely revert to an earlier state, you HAVE to store the command line
> (or a way to regenerate the command line) that was associated with the
> qemu whose state you saved, along with tracking all hotplugs.

Even that is not in fact sufficient - most QEMU command lines do not
contain sufficient info to reliably restart the guest with the exact
same machine ABI. You have to fully expand and canonicalize the
command line so that it includes all the extra bits QEMU would silently
expand - eg device addresses, exact versioned machine type, etc. without
that, you'll fail to restore the guest on a different version of QEMU,
even if you used the exact same command line as before.

> Your idea may be noble, but I think you are going down a rabbit's hole
> of unimplementable misery, and advise that you probably won't succeed.

Agreed, it isn't a productive use of resources IMHO

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|

Re: [Qemu-devel] Adding Save States menu items

[Programmingkid]

On Oct 7, 2016, at 5:09 AM, Daniel P. Berrange wrote:

> On Thu, Oct 06, 2016 at 02:59:49PM -0500, Eric Blake wrote:
>> On 10/06/2016 09:22 AM, Programmingkid wrote:
>>> Would you accept a patch that added "Save State" and "Restore State" menu items to the cocoa interface? They would allow the user to save the running state of the emulator.
>> 
>> Doesn't virt-manager already do this?  What do we gain by duplicating
>> GUI functionality at this level that is already implemented at higher
>> levels?  Not that I'm opposed to the idea, but having a solid reason why
>> it is useful is important.
>> 
>> Speaking with libvirt experience: saving a guest is somewhat easy.  But
>> once you have a save-state file, then what?  Remember, the qemu GUI is
>> associated with a SINGLE qemu process.  When libvirt manages save files,
>> it is managing MULTIPLE qemu processes.  The sequence of 'create a save
>> file, hot-plug a device, then reverting to the save file' currently
>> REQUIRES that you destroy one qemu process and create another one, where
>> the new process is back to the pre-hotplug configuration that was in use
>> when the save file was created.  Otherwise the qemu 'loadvm' command
>> will likely fail (and worse, if it does not fail, you are likely to
>> trigger even-harder-to-diagnose guest corruptions that only strike down
>> the road, rather than at the time of the loadvm).
>> 
>> If your gui (whether cocoa or GTK) is associated with a single qemu
>> process, then you will have a VERY tough time figuring out how to start
>> a new qemu process to replace the current one while still keeping the
>> gui unchanged.  And the work to convert qemu over to managing multiple
>> VMs itself is rather pointless, when you already have libvirt and
>> virt-manager and other wrappers that are already good at that.
>> 
>> Libvirt also learned that the qemu 'migrate-to-disk' format (used by
>> 'savevm' or 'migrate') is NOT self-descriptive - in order to fully and
>> safely revert to an earlier state, you HAVE to store the command line
>> (or a way to regenerate the command line) that was associated with the
>> qemu whose state you saved, along with tracking all hotplugs.
> 
> Even that is not in fact sufficient - most QEMU command lines do not
> contain sufficient info to reliably restart the guest with the exact
> same machine ABI. You have to fully expand and canonicalize the
> command line so that it includes all the extra bits QEMU would silently
> expand - eg device addresses, exact versioned machine type, etc. without
> that, you'll fail to restore the guest on a different version of QEMU,
> even if you used the exact same command line as before.
> 
>> Your idea may be noble, but I think you are going down a rabbit's hole
>> of unimplementable misery, and advise that you probably won't succeed.
> 
> Agreed, it isn't a productive use of resources IMHO

This feature could be very helpful to many users. It could help others
to be more productive. 

http://wiki.qemu.org/Features/SnapshottingImprovements
This pages shows that someone is trying to fix several migration issues.

Re: [Qemu-devel] Adding Save States menu items

[Daniel P. Berrange]

On Fri, Oct 07, 2016 at 10:55:23AM -0400, Programmingkid wrote:
> 
> On Oct 7, 2016, at 5:09 AM, Daniel P. Berrange wrote:
> 
> > On Thu, Oct 06, 2016 at 02:59:49PM -0500, Eric Blake wrote:
> >> On 10/06/2016 09:22 AM, Programmingkid wrote:
> >>> Would you accept a patch that added "Save State" and "Restore State" menu items to the cocoa interface? They would allow the user to save the running state of the emulator.
> >> 
> >> Doesn't virt-manager already do this?  What do we gain by duplicating
> >> GUI functionality at this level that is already implemented at higher
> >> levels?  Not that I'm opposed to the idea, but having a solid reason why
> >> it is useful is important.
> >> 
> >> Speaking with libvirt experience: saving a guest is somewhat easy.  But
> >> once you have a save-state file, then what?  Remember, the qemu GUI is
> >> associated with a SINGLE qemu process.  When libvirt manages save files,
> >> it is managing MULTIPLE qemu processes.  The sequence of 'create a save
> >> file, hot-plug a device, then reverting to the save file' currently
> >> REQUIRES that you destroy one qemu process and create another one, where
> >> the new process is back to the pre-hotplug configuration that was in use
> >> when the save file was created.  Otherwise the qemu 'loadvm' command
> >> will likely fail (and worse, if it does not fail, you are likely to
> >> trigger even-harder-to-diagnose guest corruptions that only strike down
> >> the road, rather than at the time of the loadvm).
> >> 
> >> If your gui (whether cocoa or GTK) is associated with a single qemu
> >> process, then you will have a VERY tough time figuring out how to start
> >> a new qemu process to replace the current one while still keeping the
> >> gui unchanged.  And the work to convert qemu over to managing multiple
> >> VMs itself is rather pointless, when you already have libvirt and
> >> virt-manager and other wrappers that are already good at that.
> >> 
> >> Libvirt also learned that the qemu 'migrate-to-disk' format (used by
> >> 'savevm' or 'migrate') is NOT self-descriptive - in order to fully and
> >> safely revert to an earlier state, you HAVE to store the command line
> >> (or a way to regenerate the command line) that was associated with the
> >> qemu whose state you saved, along with tracking all hotplugs.
> > 
> > Even that is not in fact sufficient - most QEMU command lines do not
> > contain sufficient info to reliably restart the guest with the exact
> > same machine ABI. You have to fully expand and canonicalize the
> > command line so that it includes all the extra bits QEMU would silently
> > expand - eg device addresses, exact versioned machine type, etc. without
> > that, you'll fail to restore the guest on a different version of QEMU,
> > even if you used the exact same command line as before.
> > 
> >> Your idea may be noble, but I think you are going down a rabbit's hole
> >> of unimplementable misery, and advise that you probably won't succeed.
> > 
> > Agreed, it isn't a productive use of resources IMHO
> 
> This feature could be very helpful to many users. It could help others
> to be more productive.

No one is questioning whether the feature is useful or not. The debate
is about whether it makes sense to spend the time implementing it in
QEMU, as opposed to fixing any portability problems in libvirt and/or
virt-manager and the consensus feeling points towards the latter being
a more productive use of time and resources.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|

Re: [Qemu-devel] Adding Save States menu items

[Peter Maydell]

On 7 October 2016 at 15:55, Programmingkid <programmingkidx@gmail.com> wrote:
> This feature could be very helpful to many users. It could help others
> to be more productive.

Yes, it's worth having. But it should be in the VM management
layer, not in QEMU.

> http://wiki.qemu.org/Features/SnapshottingImprovements
> This pages shows that someone is trying to fix several migration issues.

Page last edited in 2011...

thanks
-- PMM