I remember that there was a discussion about it but I don't remember it ever converging. In any case there is a patch upstream [1] that merits discussion outside the scope of the patch and reviewers.
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[2]. 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.
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. 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
I admit I have no idea if migrating SPICE would like being tunneled but I guess there is no practical reason why that would be a problem.
[1] http://gerrit.ovirt.org/#/c/10381 [2] http://en.wikipedia.org/wiki/WebSocket
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[2]. 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 model is not trivial to implement (compared to that existing patch which enables HTTP to forward PTY octet stream in full duplex). Luckily there 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 PTY 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 javascript running in browsers. If VDSM support tunneling the PTY, VNC and Spice in WebSocket, writing a viewers in browsers maybe easier.
A WebSocket proxy can also be implemented to support migration with PTY. The PTY data stream is VDSM<=>proxy<=>client. When migrating, VDSM sends 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 forwarding.
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 in 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.
Good to see my suggestion didn't fall on deaf ears.
----- Original Message -----
From: "Zhou Zheng Sheng" zhshzhou@linux.vnet.ibm.com To: "Saggi Mizrahi" smizrahi@redhat.com Cc: "VDSM Project Development" vdsm-devel@lists.fedorahosted.org, "Adam Litke" agl@us.ibm.com, "Ayal Baron" abaron@redhat.com, "Barak Azulay" bazulay@redhat.com, "Dan Kenigsberg" danken@redhat.com 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[2]. 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 model is not trivial to implement (compared to that existing patch which enables HTTP to forward PTY octet stream in full duplex). Luckily there 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 PTY 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 javascript running in browsers. If VDSM support tunneling the PTY, VNC and Spice in WebSocket, writing a viewers in browsers maybe easier.
A WebSocket proxy can also be implemented to support migration with PTY. The PTY data stream is VDSM<=>proxy<=>client. When migrating, VDSM sends 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 forwarding.
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 in 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 / 周征晟 E-mail:zhshzhou@linux.vnet.ibm.com Telephone: 86-10-82454397
vdsm-devel@lists.stg.fedorahosted.org