On Thu, Jan 26, 2017 at 05:07:16PM -0800, Ed Swierk wrote:
Interactive access to a guest serial console can be enabled by hooking the serial device to a pty backend, e.g. -device isa-serial,chardev=cs0 -chardev pty,id=cs0. With libvirt this can be configured via <console type='pty'><target type='serial' port='0'/></console>.
Output from the same serial device can also be logged to a file by adding logfile=/somefile to the -chardev option (<log file=/somefile/> in libvirt).
Unfortunately output gets logged only when a client like virsh console is connected to the pty; otherwise qemu drops it on the floor. This makes chardev logging much less useful than it could be for debugging guest problems after the fact.
Currently qemu_chr_fe_write() calls qemu_chr_fe_write_log() only for data consumed by the backend chr_write function. With the pty backend, pty_chr_write() returns 0 indicating that the data was not consumed when the pty is disconnected. Simply changing it to return len instead of 0 tricks the caller into logging the data even when the pty is disconnected. I don't know what problems this might cause, but one data point is that tcp_chr_write() already happens to work this way.
Alternatively, qemu_chr_fe_write() could be modified to log everything passed to it, regardless of how much data chr_write claims to have consumed. The trouble is that the serial device retries writing unconsumed data, so when the pty is disconnected you'd see every character duplicated 4 times in the log file.
Any opinions on either approach, or other suggestions? If there are no objections to the first one, I'll prepare a patch.
If the pty backend intends to just drop data into a blackhole when no client is connected, then its chr_write() impl should return the length of the data discarded, not zero. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|