Good to see my suggestion didn't fall on deaf ears.
----- Original Message -----
> From: "Zhou Zheng Sheng" <zhshz...@linux.vnet.ibm.com>
> To: "Saggi Mizrahi" <smizr...@redhat.com>
> Cc: "VDSM Project Development" <firstname.lastname@example.org>, "Adam
> Litke" <a...@us.ibm.com>, "Ayal Baron"
> <aba...@redhat.com>, "Barak Azulay" <bazu...@redhat.com>, "Dan Kenigsberg"
> Sent: Tuesday, January 15, 2013 4:30:03 AM
> Subject: Re: remote serial console via HTTP streaming handler
> on 01/08/2013 04:10, Saggi Mizrahi wrote:
> > The solution is somewhat elegant (and only ~150 LOC).
> > That being said I still have some 2 major problems with it:
> > The simpler one is that it uses HTTP in a very non-standard manner,
> > this
> > can be easily solved by using websockets. This is very close
> > to what the patch already does and will make it follow some sort of
> > a
> > standard. This will also enable console on the Web UI to expose
> > this on
> > newer browsers.
> Using WebSocket is a good idea. I have a look at its standard
> (http://tools.ietf.org/html/rfc6455). The framing and the security
> is not trivial to implement (compared to that existing patch which
> enables HTTP to forward PTY octet stream in full duplex). Luckily
> are some open-source WebSocket implementations.
> > The second and the real reason I didn't put it just as a comment on
> > the
> > patch is that that using HTTP and POST %PATH to have only one
> > listening
> > socket for all VMs is completely different from the way we do VNC
> > or SPICE.
> > This means it kind of bypasses ticketing and any other mechanism we
> > want
> > to put on VM interfaces.
> I think HTTP digest authentication may be implemented in the current
> forwarding patch to enable ticketing.
> > The thing is, I really like it. I was suggesting that we extend
> > this idiom
> > to use for SPICE and VNC and tunneling it through a single
> > http\websocket
> > listener. So instead of making this work with the current methods
> > make this
> > the way to go.
> > Using headers like:
> > GET /VM/<VM_ID>/control HTTP/1.1
> > Host: server.example.com
> > Upgrade: websocket
> > Ticket: <TICKET>
> > Connection: Upgrade
> > Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
> > Sec-WebSocket-Protocol: [pty, vnc, spice]
> > Sec-WebSocket-Version: 13
> > Origin:http://example.com
> In the Spice official site, I see a demo project spice-html5 uses a
> WebSocket-Spice gateway to get the data. The Spice is tunneled in
> WebSocket between the client and the gateway. This is good for
> and Spice in WebSocket, writing a viewers in browsers maybe easier.
> A WebSocket proxy can also be implemented to support migration with
> The PTY data stream is VDSM<=>proxy<=>client. When migrating, VDSM
> this event to proxy via AMQP, then shuts down the current WebSocket
> connection. The proxy can keep the connection with the client. After
> migration, another VDSM sends this event to proxy via AMQP, then the
> proxy establish the WebSocket connection with VDSM and continue the
> We can also connect two guests' serial port by forwarding the data
> stream via this proxy back and forth with support for migration as
> explained above. Furthermore, the proxy can exposes the data stream
> various plug-in protocols such as SOCKS, HTTP, SSH, telnet to various
> client. For example the proxy provide SOCKS support, then we can use
> socat as a SOCKS client to connect to guest serial port and pipe the
> data to FD 0 and 1 to a process running in the host.
Also, I don't think it's such a problem to have the client change
"servers" usually even if websockets are invovled. It just means that
client needs to be aware of the possibility of an extra layer.
> Thanks and best regards!
> Zhou Zheng Sheng / 周征晟
> Telephone: 86-10-82454397
vdsm-devel mailing list