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
