The post Universal access: An early prototype for graphical VNC console in Ironic appeared first on Mirantis | Pure Play Open Cloud.
Ideally, users should be able to have a universal experience when it comes to accessing their nova instances, but when integrated as part of OpenStack deployment, nova instances deployed on Ironic baremetal nodes have certain limitations compared to standard virtual machines created by nova. In particular, it is not currently possible to access the graphical VNC console of these instances via the Horizon Dashboard.
To fix this problem, the ironic community has started to work on introducing a framework for graphical console access for baremetal nodes. Because each hardware vendor implements a different way of providing graphical console access, the framework is planned to be quite generic, leaving details of the actual graphical console configuration and enablement to a proposed GraphicalConsole interface of an ironic driver.
One interesting type of hardware to consider in this regard is Dell servers supporting iDRACv7 or newer (PDF). The iDRAC firmware on such servers supports native access to the server’s graphical console over the OpenVNC-compatible protocol directly, without the need for proprietary VNC proxies or clients. An administrator who has appropriate access to the iDRAC configuration can enable this built-in VNC server and set the password, connection timeout and SSL encryption options.
In order to test the VNC capabilities of such hardware, I have implemented a prototype of a graphical console interface for the DRAC driver. It uses the WS-MAN HTTP API (as do the rest of the DRAC-specific driver interfaces) to toggle the VNC server feature on and off and set its properties. I have also created a prototype of get_vnc_console method for the Ironic virt-driver in Nova. As a result, I was able to get access to the graphical console in the Horizon Dashboard for the nova instance deployed on top of a Dell R630 server managed by Ironic.
Of course, no prototype is complete without any bugs/problems discovered during testing. Here is what I’ve been hitting my head against and hacking around while making this to work:
This prototype was done prior to the generic graphical console framework implementation done in ironic. Thus the prototype implementation is, for now, overriding the existing serial console interface in an Ironic driver that was specifically created for this purpose. That means that currently it is not possible to have both a serial console and graphical console.
Conveniently though, the proposed base GraphicalConsole interface will have the same API as the current Console (SerialConsole in the future) interface. This means that once the generic framework for the graphical console interfaces is implemented in Ironic, this prototype can be plugged in as graphical console interface basically as-is.
The interface implementation is using the low-level WS-MAN Python client calls for now, because support for managing the iDracCardService is yet lacking from python-dracclient. The work to enable this functionality is already ongoing in the community, though.
The ironic virt-driver changes are rather specific for this particular case are meant exclusively to let me quickly test this functionality. After the generic graphical console is implemented in Ironic and the required complementary functionality is available in python-ironicclient, this will change.
The OpenVNC implementation in iDRAC does not seem to be complete, as noVNC can not properly connect to it. The result is an apparently connected console with no graphical output (issue##712). Resolving this problem involves disabling a single passed encoding parameter in the noVNC code. For now, I have had to patch noVNC, but I have not yet determined the implications of these changes on access to a standard VM graphical console.
In order for noVNC to connect, you must set the password on the VNC server, because noVNC cannot accept an empty password in its password prompt, and setting the password for the iDRAC VNC server to None/empty string still results in the VNC server requesting a password on connection. I am not sure if this should be considered a bug in the iDRAC VNC server or in noVNC.
I have not tested yet how the iDRAC VNC server works with noVNC when SSL is enabled in iDRAC VNC Server.
The iDRAC VNC server is limited to a single VNC session at a time, so it is not really suitable for a multi-user setup. On the other hand, this still might suffice for undercloud-like use cases such as TripleO.
Note that in the current prototype, all nodes running the nova-novncproxy service (or the single one specified as “vncserver_proxyclient_address” in the config for nova-compute with the Ironic virt-driver) must effectively have access to the BMC network, as the built-in iDRAC VNC server is serving from its own BMC IP address. Take care to set up such proxying securely in a clustered nova deployment.
As you can see, there’s still a ways to go before this functionality is available in a production capacity. Nevertheless, this seems like an interesting and promising development in the hardware market. I consider it as yet another small step on the way forward to close the gap between baremetal and virtual servers in OpenStack, and to enable a unified user experience for the compute service.
The post Universal access: An early prototype for graphical VNC console in Ironic appeared first on Mirantis | Pure Play Open Cloud.
Quelle: Mirantis
Published by