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" <vdsm-devel@lists.fedorahosted.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
> streaming
> API) works, and propose a virtual HTTP server live inside existing
> XMLRPC server with a request router. You can have a look at
> 
> http://gerrit.ovirt.org/9605
> 
> 
> 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,
> this
> 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
> VDSM
> 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
> seems
> that to get the continuous stream data, the client must call
> getConsoleReadStream() again and again. I think it's expensive to
> call
> getConsoleReadStream() very frequently to get the data, and it may
> cause
> 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
> well(POST
> /consoleStream/vmid HTTP/1.0), or forward input and output stream at
> the
> same time in a POST request. This virtual server can be further
> extended
> to serve downloading guest crash core dump, and we can provide
> flexible
> authentication policies in this server. The auth for HTTP requests
> can
> be different from the XMLRPC request.
> 
> The normal XMLRPC requests are always "POST / HTTP/1.0" or "POST
> /RPC2
> 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
> very
> complex. We can multiplex the port 54321, and route the raw HTTP
> request
> to the virtual server while normal XMLRPC request still goes to
> XMLRPC
> handler.
> 
> 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 \
>    https://localhost:54321/console/vmid
> 
> I try to implement a simple request router at
> 
> http://gerrit.ovirt.org/9605
> 
> If interested, you can have a look it. It can pass the recently add
> VDSM
> functional tests, and can serve wget requests at the same time. If we
> do
> not like this idea, I think only the solution of extending spice will
> fulfill our requirements. There are obvious problems in other
> solutions.
> > ----- Original Message -----
> >> From: "Zhou Zheng Sheng" <zhshz...@linux.vnet.ibm.com>
> >> To: "VDSM Project Development" <vdsm-devel@lists.fedorahosted.org>
> >> 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
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to