Re: [Qemu-devel] [PATCH RFC] qemu-char: add an "overlay" backend type

[Daniel P. Berrange]

On Wed, Dec 16, 2015 at 07:13:08PM +0100, Paolo Bonzini wrote:
> 
> 
> On 16/12/2015 18:56, Daniel P. Berrange wrote:
> > Introduce a new QEMU chardev backend called "overlay" which
> > allows you to splice together a pair of chardev backends into
> > one combined backend. The master backend permits full input/output
> > but the slave backend is output only.
> > 
> > The primary use case for this is to allow arbitrary backends to
> > have their data logged to a file, eg a 'file' backend would be
> > setup as the slave.
> > 
> >  $ qemu-system-x86_64 \
> >      -chardev 
> > socket,host=localhost,port=9000,server=on,nowait,id=char0master \
> >      -chardev file,path=/some/log/file.log,id=char0slave \
> >      -chardev overlay,id=char0,master=char0master,slave=char0slave  \
> >      -device isa-serial,chardev=char0 \
> >      ...other args...
> > ---
> > 
> > This idea was suggsted in
> > 
> >   https://lists.gnu.org/archive/html/qemu-devel/2015-12/msg01256.html
> > 
> > this patch is a very quick proof of concept impl to illustrate the
> > idea.
> 
> Hmm, I was a fan of the "do it outside QEMU" idea... It would also fix
> the issue you have with qemu_chr_fe_write_all...

I did more work on the "do it outside QEMU" idea in libvirt, but it
quickly became apparent that I'd basically end up re-implementing
all the QEMU chardev backends in libvirt, which seems sub-optimal
to me, when all I really want is a logfile added :-(

At the same time I'm also not a huge fan of this overlay backend
now that I've thought about this overnight. Aside from the issue
mentioned in the code, the other downside of this proposed patch
is that it makes life significantly more complicated for libvirt,
as when configuring QEMU we now have to create 3 chardevs instead
of just one. THis is quite alot of extra pain just for the goal
of supporting. I think this also opens a can of worms, because
I realized this allows us to stack up chardevs arbitrarily deep
by creating an overlay on an overlay on an overlay on an overlay....
which will probably come back to bite us later.

So I've sent another alternative, which simply directly adds a
"logfile" parameter to the "socket" backend, which is directly
addressing the core need that OpenStack has here (they want to
have TCP / UNIX socket for interactive console + a logfile to
capture all output on the same serial port concurrently).

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