qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Simon
Subject: Re: [Qemu-devel] [Bug 1217339] [PATCH v2] Unix signal to send ACPI-shutdown to Guest
Date: Tue, 21 Mar 2017 13:30:56 +0100
User-agent: Roundcube Webmail/1.1.2

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]