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