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

Daniel Veillard veillard at redhat.com
Wed Nov 3 11:07:07 UTC 2010


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 ...

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/




More information about the libvir-list mailing list