qemu-char: add logfile facility to socket backend
RFC PATCH 1/1 qemu-char: add logfile facility to socket backend
Typically a UNIX guest OS will log boot messages to a serial port in addition to any graphical console. An admin user may also wish to use the serial port for an interactive console. A virtualization management system may wish to collect system boot messages by logging the serial port, but also wish to allow admins interactive access.
Currently providing such a feature forces the mgmt app to either provide 2 separate serial ports, one for logging boot messages and one for interactive console login, or to proxy all output via a separate service that can multiplex the two needs onto one serial port. While both are valid approaches, they each have their own downsides. The former causes confusion and extra setup work for VM admins creating disk images. The latter places an extra burden to re-implement much of the QEMU chardev backends logic in libvirt or even higher level mgmt apps and adds extra hops in the data transfer path.
A simpler approach that is satisfactory for many use cases is to allow the QEMU chardev backends to have a "logfile" property associated with them.
$QEMU -chardev socket,host=localhost,port=9000,\
server=on,nowait,id-charserial0,\
logfile=/var/log/libvirt/qemu/test-serial0.log
-device isa-serial,chardev=charserial0,id=serial0--- qapi-schema.json | 4 +++- qemu-char.c | 65 ++++++++++++++++++++++++++++++++++++++++++++++++++------ 2 files changed, 61 insertions(+), 8 deletions(-)
qapi-schema.json +3 -1
@@ -3056,6 +3056,7 @@ # then attempt a reconnect after the given number of seconds. # Setting this to zero disables this function. (default: 0) # (Since: 2.2) +# @logfile: #optional file to log all data output to (since 2.6) # # Since: 1.4 ##
@@ -3064,7 +3065,8 @@ '*wait' : 'bool', '*nodelay' : 'bool', '*telnet' : 'bool', - '*reconnect' : 'int' } } + '*reconnect' : 'int', + '*logfile' : 'str' } } ## # @ChardevUdp:
qemu-char.c +58 -7
139 lines not on this page · raw message
Signature · 1 line
2.5.0
Quoted 19 lines · Daniel P. Berrange
Typically a UNIX guest OS will log boot messages to a serial port in addition to any graphical console. An admin user may also wish to use the serial port for an interactive console. A virtualization management system may wish to collect system boot messages by logging the serial port, but also wish to allow admins interactive access.
Currently providing such a feature forces the mgmt app to either provide 2 separate serial ports, one for logging boot messages and one for interactive console login, or to proxy all output via a separate service that can multiplex the two needs onto one serial port. While both are valid approaches, they each have their own downsides. The former causes confusion and extra setup work for VM admins creating disk images. The latter places an extra burden to re-implement much of the QEMU chardev backends logic in libvirt or even higher level mgmt apps and adds extra hops in the data transfer path.
Quoted 8 lines
A simpler approach that is satisfactory for many use cases is to allow the QEMU chardev backends to have a "logfile" property associated with them.
$QEMU -chardev socket,host=localhost,port=9000,\ server=on,nowait,id-charserial0,\ logfile=/var/log/libvirt/qemu/test-serial0.log -device isa-serial,chardev=charserial0,id=serial0
Why for socket only? It would be very useful for stdio and especially vc.
Paolo
Quoted 26 lines · Paolo Bonzini
Quoted 23 lines · Daniel P. Berrange
Typically a UNIX guest OS will log boot messages to a serial port in addition to any graphical console. An admin user may also wish to use the serial port for an interactive console. A virtualization management system may wish to collect system boot messages by logging the serial port, but also wish to allow admins interactive access.
Currently providing such a feature forces the mgmt app to either provide 2 separate serial ports, one for logging boot messages and one for interactive console login, or to proxy all output via a separate service that can multiplex the two needs onto one serial port. While both are valid approaches, they each have their own downsides. The former causes confusion and extra setup work for VM admins creating disk images. The latter places an extra burden to re-implement much of the QEMU chardev backends logic in libvirt or even higher level mgmt apps and adds extra hops in the data transfer path.
A simpler approach that is satisfactory for many use cases is to allow the QEMU chardev backends to have a "logfile" property associated with them.
Quoted 6 lines
Quoted 4 lines
$QEMU -chardev socket,host=localhost,port=9000,\ server=on,nowait,id-charserial0,\ logfile=/var/log/libvirt/qemu/test-serial0.log -device isa-serial,chardev=charserial0,id=serial0Why for socket only? It would be very useful for stdio and especially vc.
This is just an "RFC" so didn't want to spend the time to wire up all of them until I got positive feedback on the idea :-) If its acceptable, then I think it could make sense to just support optional "logfile" on every single backend, except "file"
Regards,
Daniel
Signature · 4 lines
|: 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 :|
Quoted 9 lines · Daniel P. Berrange
Quoted 7 lines
Quoted 7 lines
Quoted 5 lines
Quoted 5 lines
$QEMU -chardev socket,host=localhost,port=9000,\ server=on,nowait,id-charserial0,\ logfile=/var/log/libvirt/qemu/test-serial0.log -device isa-serial,chardev=charserial0,id=serial0Why for socket only? It would be very useful for stdio and especially vc.
This is just an "RFC" so didn't want to spend the time to wire up all of them until I got positive feedback on the idea :-)
Yes, I think it's fine. I guess one could do weird things with it such as connecting it to a named pipe, but we shouldn't waste time preventing it.
Quoted 2 lines
If its acceptable, then I think it could make sense to just support optional "logfile" on every single backend, except "file"
Yeah, I'd even wire it in qemu_chr_fe_write, and only prevent it for "file" at option parsing time. Or just allow it for all of them.
Paolo
Quoted 9 lines · Paolo Bonzini
Quoted 6 lines · Daniel P. Berrange
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
Quoted 5 lines
$QEMU -chardev socket,host=localhost,port=9000,\ server=on,nowait,id-charserial0,\ logfile=/var/log/libvirt/qemu/test-serial0.log -device isa-serial,chardev=charserial0,id=serial0
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
Quoted 1 line
Why for socket only? It would be very useful for stdio and especially vc.
This is just an "RFC" so didn't want to spend the time to wire up all of them until I got positive feedback on the idea :-)
Yes, I think it's fine. I guess one could do weird things with it such as connecting it to a named pipe, but we shouldn't waste time preventing it.
Great, I'll work on a properly complete patch for this then.
Quoted 5 lines
Quoted 2 lines
If its acceptable, then I think it could make sense to just support optional "logfile" on every single backend, except "file"
Yeah, I'd even wire it in
qemu_chr_fe_write, and only prevent it for "file" at option parsing time. Or just allow it for all of them.
Yeah, doing it above the backend driver layer sounds like a nice simple approach to making it work universally.
Regards,
Daniel
Signature · 4 lines
|: 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 :|