qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 0/1] add exit-script option to qemu


From: Daniel P . Berrangé
Subject: Re: [Qemu-devel] [PATCH 0/1] add exit-script option to qemu
Date: Fri, 5 Oct 2018 14:02:02 +0100
User-agent: Mutt/1.10.1 (2018-07-13)

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 :|



reply via email to

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