Re: [vdsm] [RFC]about the implement of text-based console

From: "Zhou Zheng Sheng" <zhshzhou(a)linux.vnet.ibm.com&gt; To: "Saggi Mizrahi" <smizrahi(a)redhat.com&gt;, "Adam Litke" <agl(a)us.ibm.com&gt; Cc: "VDSM Project Development" <vdsm-devel(a)lists.fedorahosted.org&gt; 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" <zhshzhou(a)linux.vnet.ibm.com&gt; >> To: "VDSM Project Development" <vdsm-devel(a)lists.fedorahosted.org&gt; >> 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: zhshzhou(a)linux.vnet.ibm.com Telephone: 86-10-82454397