Re: [Qemu-devel] [Bug 1217339] [PATCH v2] Unix signal to send ACPI-shutdown to Guest

[Simon <qemu.bugs@whitewinterwolf.com>]

Daniel P. Berrange:
> On Sat, Mar 18, 2017 at 02:41:16PM +0100, Simon wrote:
>> Hi,
>> 
>> The patch below adds the new command-line option `-powerdown' which
>> changes the behavior for both SIGHUP and SIGINT signals to cause a 
>> clean
>> power down of the guest using an ACPI shutdown request.
> 
> If you need to add command line arguments IMHO this feature becomes
> much less interesting - just use the QEMU monitor instead of inventing
> an adhoc way to achieve something the monitor already does. The value 
> of
> using a signal handler comes from the fact that it would be 
> unconditionally
> available no matter what command line args were added.

Hi Daniel,

Thank you for taking the time to answer me.

I am currently using the monitor to achieve this functionality, and this
boils down into doing something similar to this:

--------- 8< ----------------
if ! type 'socat' >/dev/null 2>&1
then
     echo "You must install 'socat'." >&2
     exit 1
fi
files=$( ps -e -o args | awk '$1 ~ /qemu-system-/' \
     | sed 's/.* -monitor unix:\([^,]*\).*/\1/;t;s/.*//' )
IFS='
'
for f in $files
do
     echo 'system_powerdown' | socat "UNIX-CONNECT:${f}" -
done
--------- 8< ----------------

In other words I check that required software is properly installed,
parse `ps' output to extract the path to the monitor socket file when it
is available, and pipe the `system_powerdown' command into it to
cleanly shut the VM down.

As a matter of comparison, here the same functionality implemented using
Unix signals instead of the monitor socket files:

--------- 8< ----------------
pkill -HUP qemu-system-
--------- 8< ----------------

Maybe it is just my own opinion, but I find the second approach cleaner
and more reliable.

Regarding the fact that it would require a specific parameter to be
enabled, I already use several parameters on a systematic basis with
Qemu (enable KVM, the USB tablet, set the keyboard layout, etc.).
I don't see the fact of adding a supplementary one to this set as an
annoyance.

On the contrary, I love Qemu's versatility and all these parameters are
here just to let users personalize Qemu behavior to best suit the way
they use it.

Regards,
Simon.