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

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

[Tony Breeds]

[-- Attachment #1: Type: text/plain, Size: 1069 bytes --]

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?

Yours Tony.

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

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

[Paolo Bonzini]

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

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

[Tony Breeds]

[-- Attachment #1: Type: text/plain, Size: 609 bytes --]

On Fri, Dec 05, 2014 at 11:09:02PM +0100, Paolo Bonzini wrote:

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

Thanks for the feedback I'm gald it's something that isn't a clearly terrible idea.

I don't think that's required for my use case, but it's not all about me.  If
that's something people generally feel is desired I'm happy to try and make it
work.
 
> If you want to make it optional, you can add a suboption to -msg.

I'll look at that, based on 5mins of looking I don't think that'll work, but
you know the code much better than me so clearly I wont dismiss it.

Yours Tony.

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

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

[Daniel P. Berrange]

On Sat, Dec 06, 2014 at 08:35:19AM +1100, 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.

My long term desired approach to deal with this problem in OpenStack (and
other libvirt based mgmt apps) is to have a separate log daemon in libvirt
eg a virtlogd daemon. Take QEMU out of the business of writing to files
entirely and instead it would always just be a given a pipe FD which is
connected to the daemon. This avoidis the need to give QEMU permission to
open files at all, which is inline with our general security strategy for
host resources QEMU accesses.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

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

[Tony Breeds]

[-- Attachment #1: Type: text/plain, Size: 1009 bytes --]

On Mon, Dec 08, 2014 at 09:48:12AM +0000, Daniel P. Berrange wrote:
 
> My long term desired approach to deal with this problem in OpenStack (and
> other libvirt based mgmt apps) is to have a separate log daemon in libvirt
> eg a virtlogd daemon. Take QEMU out of the business of writing to files
> entirely and instead it would always just be a given a pipe FD which is
> connected to the daemon. This avoidis the need to give QEMU permission to
> open files at all, which is inline with our general security strategy for
> host resources QEMU accesses.

Hi Daniel,
    that sounds like a good plan and would certainly address the openstack case
but I still feel like hving something in qemu is a good idea as that doesn't stop
an alternate fix in libvirt and it helps users that aren't using libvirt and qemu
together.

Having said that I'm willing to be directed by the qemu community.  If they feel that
a libvirt only fix is best then that's where I'll spend my effort.
 
Yours Tony.

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]