[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