Re: [Qemu-devel] Adding Save States menu items
On 6 October 2016 at 15:22, 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. 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
On Oct 6, 2016, at 10:28 AM, Peter Maydell wrote: > On 6 October 2016 at 15:22, 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. > > 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
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 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
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 >>> 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
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 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
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 > 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- - 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
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- - 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
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- - 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
On 6 October 2016 at 18:43, Programmingkid 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
On Oct 6, 2016, at 1:49 PM, Peter Maydell wrote: > On 6 October 2016 at 18:43, Programmingkid 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
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 signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] Adding Save States menu items
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- - 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 signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] Adding Save States menu items
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
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 signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] Adding Save States menu items
On 6 October 2016 at 12:59, Eric Blake 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
On Oct 6, 2016, at 4:47 PM, Peter Maydell wrote: > On 6 October 2016 at 12:59, Eric Blake 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
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
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 pgp9FIC3449sD.pgp Description: PGP signature
Re: [Qemu-devel] Adding Save States menu items
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
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
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
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
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
On 7 October 2016 at 15:55, Programmingkid 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