On Wed, Nov 03, 2010 at 11:19:34AM +0000, Daniel P. Berrange wrote: > On Wed, Nov 03, 2010 at 12:07:07PM +0100, Daniel Veillard wrote: > > On Tue, Nov 02, 2010 at 05:49:07PM +0000, Daniel P. Berrange wrote: > > > This provides an implementation of the virDomainOpenConsole > > > API for the remote driver client and server. > > > > > > * daemon/remote.c: Server side impl > > > * src/remote/remote_driver.c: Client impl > > > * src/remote/remote_protocol.x: Wire definition > > > --- > > > daemon/remote.c | 52 ++++++++++++++++++++++ > > > daemon/remote_dispatch_args.h | 1 + > > > daemon/remote_dispatch_prototypes.h | 8 +++ > > > daemon/remote_dispatch_table.h | 5 ++ > > > src/remote/remote_driver.c | 82 +++++++++++++++++++++++++++-------- > > > src/remote/remote_protocol.c | 13 ++++++ > > > src/remote/remote_protocol.h | 10 ++++ > > > src/remote/remote_protocol.x | 9 +++- > > > src/remote_protocol-structs | 5 ++ > > > 9 files changed, 165 insertions(+), 20 deletions(-) > > > > Okay, ACK > > My main question is actually what happen if the guest emitsa lot of > > console data (let say some program is really flooding the pipe) and > > the remote client doesn't consume the stream. virStream is lossless > > as far as I understand and there will be a limit to the buffering > > on the file descriptor and the network pipe, so as a result the guest > > may stall (assuming a device coming from QEmu, the qemu process > > will block on the console I/O), right ? > > It would be an interesting experiment to try ... > > There's two questions to answer here really right :-) > If the libvirt client doesn't consume from the libvirtd server quickly > enough, then libvirtd will stop consuming frm QEMU. Basically libvirtd > will only allow 1 pending outbound stream packet for transmission > at a time (max 256 kb data). So libvirtd is safe from unbounded mem > usage in buffering here. The behaviour of QEMU i think depends on the > device. A virtio console should block the guest OS from writing data. > IIC, a serial device will either loose data, or block the guest, depending > on whether flow control is properly used in the guest. Okay, we can't make assumptions on the producer behaviour. > If a libvirt application doesn't consume data from the libvirt client > quickly enough, the memory usage *can* balloon up unbounded, because > the virStream on the libvirt client doesn't do any throttling when > reading data from libvirtd. This could be addressed later, but since > it is client side, I'm not too concerned. We could add a virStream opening extra flag to limit buffering, but not urgent. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list