Sorry, it's probably the fact that I don't have enough time to go into the code
but I still don't get what you are trying to do.
Having it in HTTP and XML-RPC is a bad idea but I imagine that the theoretical
solution doesn't depend on any of them.
Could you just show some pseudo code of a client using the stream?
----- Original Message -----
> From: "Zhou Zheng Sheng" <zhshz...@linux.vnet.ibm.com>
> To: "Saggi Mizrahi" <smizr...@redhat.com>, "Adam Litke" <a...@us.ibm.com>
> Cc: "VDSM Project Development" <firstname.lastname@example.org>
> Sent: Friday, November 30, 2012 10:12:19 PM
> Subject: Re: [vdsm] [RFC]about the implement of text-based console
> Hi all, in this mail I further explain how solution 5 (console
> API) works, and propose a virtual HTTP server live inside existing
> XMLRPC server with a request router. You can have a look at
> on 11/28/2012 01:09, Adam Litke wrote:
> > One issue that was raised is console buffering. What happens if a
> > client does
> > not call getConsoleReadStream() fast enough? Will characters be
> > dropped? This
> > could create a reliability problem and would make scripting against
> > this
> > interface risky at best.
> on 11/28/2012 01:45, Saggi Mizrahi wrote:
> > I don't really understand 5. What does those methods return the
> > virtio dev path?
> As I know, HTTP supports persistent connection and data streaming,
> is popular for AJAX applications and live video broadcasting servers.
> The client sends one GET request to server, and server returns a data
> stream, then the client reads the stream continuously.
> XMLRPC and REST calls relies on HTTP, so I was considering
> getConsoleReadStream() can utilize streaming feature in HTTP, and
> just forwards the console data when it is called. Unfortunately I can
> not find out how XMLRPC and REST supports data streaming, because XML
> and JSON do not support containing a continuous stream object. It
> that to get the continuous stream data, the client must call
> getConsoleReadStream() again and again. I think it's expensive to
> getConsoleReadStream() very frequently to get the data, and it may
> a notable delay, which is not acceptable for interactive console.
> I am thinking of providing console stream through HTTP(s) directly. A
> virtual server can forward the data from guest serial console by
> traditional HTTP streaming method (GET /consoleStream/vmid HTTP/1.0),
> and can forward the input data from the user by POST method as
> /consoleStream/vmid HTTP/1.0), or forward input and output stream at
> same time in a POST request. This virtual server can be further
> to serve downloading guest crash core dump, and we can provide
> authentication policies in this server. The auth for HTTP requests
> be different from the XMLRPC request.
> The normal XMLRPC requests are always "POST / HTTP/1.0" or "POST
> HTTP/1.0". So this virtual server can live inside the existing XMLRPC
> server, just with a request router. I read the code implementing the
> XMLRPC binding and find that implementing a request router is not
> complex. We can multiplex the port 54321, and route the raw HTTP
> to the virtual server while normal XMLRPC request still goes to
> This means it can serve XMLRPC request as
> vdsClient -s localhost getVdsCaps
> at the same time it can serve a wget client as
> wget --no-check-certificate \
> --certificate=/etc/pki/vdsm/certs/vdsmcert.pem \
> --private-key=/etc/pki/vdsm/keys/vdsmkey.pem \
> --ca-certificate=/etc/pki/vdsm/certs/cacert.pem \
> I try to implement a simple request router at
> If interested, you can have a look it. It can pass the recently add
> functional tests, and can serve wget requests at the same time. If we
> not like this idea, I think only the solution of extending spice will
> fulfill our requirements. There are obvious problems in other
> > ----- Original Message -----
> >> From: "Zhou Zheng Sheng" <zhshz...@linux.vnet.ibm.com>
> >> To: "VDSM Project Development" <email@example.com>
> >> Sent: Tuesday, November 27, 2012 4:22:20 AM
> >> Subject: Re: [vdsm] [RFC]about the implement of text-based console
> >> Hi all,
> >> For now in there is no agreement on the remote guest console
> >> solution,
> >> so I decide to do some investigation continue the discussion.
> >> Our goal
> >> VM serial console remote access in CLI mode. That means the
> >> client
> >> runs without X environment.
> > Do you mean like running qemu with -curses?
> I mean like "virsh console"
> Thanks and best regards!
> Zhou Zheng Sheng / 周征晟
> E-mail: zhshz...@linux.vnet.ibm.com
> Telephone: 86-10-82454397
vdsm-devel mailing list