From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Dominik Csapak <d.csapak@proxmox.com>
Cc: qemu-devel@nongnu.org, pbonzini@redhat.com
Subject: Re: [Qemu-devel] [PATCH 0/1] add exit-script option to qemu
Date: Fri, 5 Oct 2018 14:02:02 +0100 [thread overview]
Message-ID: <20181005130202.GL778@redhat.com> (raw)
In-Reply-To: <dc14192a-ad21-d2b3-385a-07b274ad5c59@proxmox.com>
On Fri, Oct 05, 2018 at 02:57:03PM +0200, Dominik Csapak wrote:
> On 10/5/18 10:38 AM, Daniel P. Berrangé wrote:
> > On Fri, Oct 05, 2018 at 08:56:27AM +0200, Dominik Csapak wrote:
> > > On 10/4/18 3:51 PM, Daniel P. Berrangé wrote:
> > > > On Wed, Oct 03, 2018 at 11:13:43AM +0200, Dominik Csapak wrote:
> > > > > this patch aims to execute a script when qemu exits
> > > > > so that one can do cleanups when using --daemonize without
> > > > > having to use the qmp monitor
> > > >
> > > > IMHO the idea of cleanup scripts run by QEMU itself is flawed.
> > > > QEMU will inevitably crash before cleanup scripts can be run,
> > > > so whatever mgmt app is using QEMU needs to be able to do
> > > > cleanup without QEMU's help.
> > > >
> > > > I think this can be done more reliably with a wrapper script,
> > > > that spawns QEMU, waits for it to exit and then calls the
> > > > cleanup script. On Linux at least you can use prctl() with
> > > > PR_SET_CHILD_SUBREAPER so you can detect exit'ing of QEMU
> > > > even after it has daemonized.
> > > >
> > > > Perhaps we could have such a wrapper script put in the
> > > > contrib directory
> > > >
> > > > Regards,
> > > > Daniel
> > > >
> > > Hi,
> > >
> > > for cleaning up after qemu crashes, you are completely right,
> > > (ignoring that the downscript for tap devices also never gets executed
> > > then), but this series has another use.
> > >
> > > With it, a user can determine the reason of a graceful shutdown
> > > (e.g., if it was by a signal, qmp or from inside) of qemu,
> > > especially when using -no-reboot without using qmp
> > >
> > > and using qmp for that is not very practical for everyone,
> > > or is there another way for that which i am missing?
> >
> > Honestly QMP *is* the right answer. We've put alot of effort into QMP
> > and I don't think it is sensible to start adding new mechanisms to
> > provide the same information in an adhoc manner.
> >
> > What makes you think QMP isn't practical to use ? We have client
> > impls that talk to QMP in scripts/qmp that are just a few 100 lines
> > of pretty simple python code.
> >
>
> ok, i just found that having to start an extra program waiting for qmp
> events might be overkill for some users
>
> nonetheless, i just found out that even with qmp, there is no way
> to see if a machine started with '-no-reboot' was trying to reboot
> or just shutting down, in both cases i got a SHUTDOWN event
> with 'guest: true'
>
> would it make sense to send a patch that introduces a new data field
> for the shutdown event that says if it was really a reset?
I had a feeling there was another way to detct it, but I'm not seeing
it in QMP. So yeah, if this can't be determined, then I expect it is
worth extending QMP to report this
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
prev parent reply other threads:[~2018-10-05 13:02 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-03 9:13 [Qemu-devel] [PATCH 0/1] add exit-script option to qemu Dominik Csapak
2018-10-03 9:13 ` [Qemu-devel] [PATCH 1/1] vl.c: call optional script when exiting Dominik Csapak
2018-10-03 10:15 ` Philippe Mathieu-Daudé
2018-10-04 8:11 ` Thomas Huth
2018-10-03 10:15 ` [Qemu-devel] [PATCH 0/1] add exit-script option to qemu Philippe Mathieu-Daudé
2018-10-04 13:51 ` Daniel P. Berrangé
2018-10-05 6:56 ` Dominik Csapak
2018-10-05 8:38 ` Daniel P. Berrangé
2018-10-05 12:57 ` Dominik Csapak
2018-10-05 13:02 ` Daniel P. Berrangé [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181005130202.GL778@redhat.com \
--to=berrange@redhat.com \
--cc=d.csapak@proxmox.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).