[libvirt] [PATCH 03/11] Remote driver client and server for virDomainOpenConsole

[Daniel P. Berrange]

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

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.

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.


Daniel
-- 
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org        -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|