From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DFcuW-0007Lr-9j for qemu-devel@nongnu.org; Sun, 27 Mar 2005 13:54:57 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DFcuN-0007Eg-8Q for qemu-devel@nongnu.org; Sun, 27 Mar 2005 13:54:48 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DFcuM-0007CI-M5 for qemu-devel@nongnu.org; Sun, 27 Mar 2005 13:54:46 -0500 Received: from [217.204.41.189] (helo=kula.newsnow.net) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1DFcXa-00084w-0U for qemu-devel@nongnu.org; Sun, 27 Mar 2005 13:31:14 -0500 Message-ID: <4246FBD8.7000403@praguespringpeople.org> Date: Sun, 27 Mar 2005 20:30:48 +0200 From: Struan Bartlett MIME-Version: 1.0 Subject: Re: [Qemu-devel] Suggestion - trap window-close of VM References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030105060900010906000904" Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ryan Rempel , qemu-devel@nongnu.org This is a multi-part message in MIME format. --------------030105060900010906000904 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Ryan Rempel wrote: >On Mon, Nov 29, 2004 at 21:46:54 +0100, Lennert Buytenhek wrote > > >>On Mon, Nov 29, 2004 at 08:43:56PM +0000, Richard Neill wrote: >> >> >>>A thought that occurred to me. If one is running a virtual machine (eg >>>copy of WinXP), then simply closing the qemu window is a really bad >>>idea, since it will effectively crash the guest. >>> >>> >>Related thought -- it would be way cool if we could make killing qemu >>do exactly happens when you press the power button on an ACPI-capable >>machine with any recent OS on it (auto shutdown.) >> >> >I was wondering if anyone has followed up on this suggestion. I'm >putting together a Qemu-based setup for some relatively naive users, >and ideally I'd like to be able to deal with this in a reasonable >elegant way (the ACPI hook sounds very elegant indeed). > >Alternatively, how do people deal with the problem of naive users who >might just close the Qemu window without shutting down the guest >properly? I'm working in a KDE environment -- perhaps there is a way >in KDE to prevent the close button from appearing? But that wouldn't >catch every case either (for instance, if the user were to shut down >the host). > This sounds like a good idea. An alternative solution, that might be more straightforward to implement if Qemu doesn't implement ACPI yet, would be for the kill signal to simply cause Qemu to do the equivalent of entering 'stop' and 'savevm ' into the monitor. --------------030105060900010906000904 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Ryan Rempel wrote: 
On Mon, Nov 29, 2004 at 21:46:54 +0100, Lennert Buytenhek wrote
  
On Mon, Nov 29, 2004 at 08:43:56PM +0000, Richard Neill wrote:
    
A thought that occurred to me. If one is running a virtual machine (eg 
copy of WinXP), then simply closing the qemu window is a really bad 
idea, since it will effectively crash the guest.
      
Related thought -- it would be way cool if we could make killing qemu
do exactly happens when you press the power button on an ACPI-capable
machine with any recent OS on it (auto shutdown.)
    
I was wondering if anyone has followed up on this suggestion. I'm
putting together a Qemu-based setup for some relatively naive users,
and ideally I'd like to be able to deal with this in a reasonable
elegant way (the ACPI hook sounds very elegant indeed).

Alternatively, how do people deal with the problem of naive users who
might just close the Qemu window without shutting down the guest
properly? I'm working in a KDE environment -- perhaps there is a way
in KDE to prevent the close button from appearing? But that wouldn't
catch every case either (for instance, if the user were to shut down
the host).
This sounds like a good idea. An alternative solution, that might be more straightforward to implement if Qemu doesn't implement ACPI yet, would be for the kill signal to simply cause Qemu to do the equivalent of entering 'stop' and 'savevm <somefilepath>' into the monitor.
--------------030105060900010906000904--