Future mconsole development

The current mconsole client is the simplest possible one - it has a command-line interface, controls a single UML instance, and implements only the commands supported by the mconsole driver.

Future mconsole clients will have a number of client-side enhancements:

• the ability to communicate with and control multiple UMLs
• different interfaces, such as GUIs and HTML, and possibly more specialized interfaces such as emacs, Linuxconf, and IRC
• built-in scripting or programming to allow automated management of UMLs

In addition, there are a number of mconsole protocol enhancements planned in order to provide clients with greater abilities to control and monitor virtual machines.

Notification of UML events

The ability to register for events such as panics and console output and to retrieve configuration information from the virtual machine is intended to support applications which configure, launch, and manage many UMLs. Receiving panic information and console output will allow such an application to monitor the status of the virtual machines under its care and to provide a central point for the administrator to monitor them or for the application itself to filter the console output looking for unusual events.

Ability to retrieve configuration information

The ability to get configuration information will simplify these applications by not requiring them to maintain its own record of how the virtual machines are configured. It also makes it possible to manage a virtual machine which it didn't configure or launch.

Communication over IP sockets

Currently, the mconsole driver communicates through a Unix domain socket. Possibly, this will be extended to allow it to use a Internet domain socket as well. This would allow the mconsole client to transparently manage virtual machines regardless of whether or not they are running on the same host as the client.
The issue that makes this uncertain is authentication. There needs to be some security so that random users can't shut down or reconfigure virtual machines that don't belong to them. Currently, this is handled by passing a set of credentials over the Unix socket. Access is allowed if the user id and group id in the credentials match the UML's user and group ids. This is not possible across Internet sockets, so some other scheme would be necessary. What would probably be done is that a name of a file containing a secret would be passed in on the UML command line or configured later with a local mconsole client. A remote mconsole client would need to present this secret to the virtual machine before being allowed access to it.
However, the secret would not be protected from snooping without the connection being encrypted. So, this would probably involve ssh somehow, and there is already a perfectly good way of using ssh to access a UML's mconsole without adding any extra mechanisms to either UML or the client. That is to run the mconsole client locally with the virtual machine and to have the central administration application communicate with it over ssh. So, unless there turns out to be some good reason not to, my intention is to recommend this scheme for anyone wanting to communicate remotely with UML's mconsole driver.