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

[Daniel Veillard]

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 at veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/