Nova currently allows a graphical console to be used for virtual instances. The Ironic driver does not implement the VNC console. Nodes often have a graphical console available via IPMI, and Ironic could expose a VNC server to Nova. That would ultimately provide a graphical console in Horizon to end users.
That way, nova get-vnc-console would return a valid response, and would allow a user to have a graphical console on the physical server.
$ nova get-vnc-console 99694c1e-6327-4d58-9466-87f7265958af novnc
+-------+------------------------------------------------------------------------------------------------+
| Type | Url |
+-------+------------------------------------------------------------------------------------------------+
| novnc | https://console.cloud.example.net:443/vnc_auto.html?token=17e1e064-cc66-4772-8d39-299cf13b8972 |
+-------+------------------------------------------------------------------------------------------------+
IPMI graphical consoles don't normally expose a VNC server. Typical implementations provide a native client that does the heavy lifting. The idea is to run the manufacturer's provided client in a X11 server, and run a x11vnc server to offer a VNC endpoint around the manufacturer's graphical console client.
Our current implementation and proposal suggests running these X11 sessions isolated in Docker containers, and leverages different Docker images for each manufacturer's implementation. This is controllable per-node and allows multiple images at the same time.
Additionally, the Ironic console driver uses a secured link between ironic-conductor and the docker host(s). This allows the docker hosts to reside in a network other than the management network, and allow for proper segregation of data flow vs signalling.
Drafting up a spec ATM. It might seem like this is adding fuel to the fire with the already 2 implementations of a serial console, but I think it should help the group take the right decision with relation to the console handling.