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
vdsm-devel mailing list

Reply via email to