qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Providing a mechanism to reopen() file based chardevs


From: Paolo Bonzini
Subject: Re: [Qemu-devel] Providing a mechanism to reopen() file based chardevs
Date: Fri, 05 Dec 2014 23:09:02 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0

-----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 via email to

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