[prev in list] [next in list] [prev in thread] [next in thread] 

List:       vdsm-devel
Subject:    Re: [vdsm] remote serial console via HTTP streaming handler
From:       Saggi Mizrahi <smizrahi () redhat ! com>
Date:       2013-01-15 21:02:04
Message-ID: 378954990.2054300.1358283724180.JavaMail.root () redhat ! com
[Download RAW message or body]

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 mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel


[prev in list] [next in list] [prev in thread] [next in thread]