qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Providing a mechanism to reopen() file based chardevs
Date: Fri, 05 Dec 2014 23:09:02 +0100	[thread overview]
Message-ID: <54822CFE.5040506@redhat.com> (raw)
In-Reply-To: <20141205213518.GD84915@thor.bakeyournoodle.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 05/12/2014 22:35, Tony Breeds wrote:
> Hi All, Openstcak (Nova) has had an issue for a longish time where
> a running instance (qemu via libvirt) which has a file based
> console can fill the disk of the hypervisor causing all guests to
> stall.
> 
> I'm looking at ways to fix this.  Clearly it can be done in
> openstack wothout changing qemu but it seems to be that a better
> idea would be to teach qemu to reopen() these files when it
> recieves a sighup and/or something in the monitor.
> 
> I like the idea of sighup as it allows systems administrators to
> use logrotate thereby avoiding baking policy into qemu.
> 
> My initial thoughts are that I'd need to add a flag to the chardev
> (perhaps allowreopen?) and upon reciept of the reopen request I'd I
> iterate over the open chardevs and reopen them if they have this
> flag set.
> 
> The main target of this would be a console log.
> 
> So my main question is would that be something that would be
> considered for 2.3.0?  If so any high level design points I shoudl
> consider?
> 
> - Is the chardev flag a good/bad idea? - Is it okay to change the
> action taken by sighup?

I think so.  Should it reopen stdout/stderr too?

If you want to make it optional, you can add a suboption to -msg.

Paolo

  reply	other threads:[~2014-12-05 22:09 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-05 21:35 [Qemu-devel] Providing a mechanism to reopen() file based chardevs Tony Breeds
2014-12-05 22:09 ` Paolo Bonzini [this message]
2014-12-06  4:32   ` Tony Breeds
2014-12-08  9:48 ` Daniel P. Berrange
2014-12-09  1:30   ` Tony Breeds

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=54822CFE.5040506@redhat.com \
    --to=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).