The management console provides the ability to insert and remove devices from a running virtual machine. For example, the command
(mconsole) config eth0=ethertap,tap0,,192.168.0.254
adds the eth0 device to the virtual machine that the mconsole is attached to. New devices are specified to the mconsole in exactly the same way that they are specified on the command line. So, in both cases, the same code in the driver parses and interprets the specification, and creates the new device.
Similarly,
(mconsole) remove eth0
removes the eth0 device from the system.
Only devices that don't already exist may be plugged in at run-time. An attempt to create an eth0 device on a system that already had an eth0 would fail. Also, a device that is to be removed must be ``idle'' according to the driver. The definition of ``idle'' necessarily differs from device to device. The network driver requires that the interface be down, while the block driver requires that the device not be open in any way, either by being mounted or by being directly opened by a process such as dd.
The kernel debugger is considered a ``device'' in this context and can be started and stopped at run-time in a similar manner. At the time of writing, these three devices are the ones that can be plugged and unplugged.
The remainder of the device drivers will have this capability added in the medium future. It is a goal for version 1.0 of UML to have everything pluggable that can be.
The obvious exceptions are the console and serial line drivers. There are also some less-obvious exceptions. Memory should at least be pluggable. It's fairly straightforward to add memory to a machine at runtime. Less obvious is how to remove it. If the new memory region contains kernel data when it is to be removed, then it can't be, since kernel memory is not movable or swappable. Changing this is a problem for the generic kernel. Possibly, the new memory could be declared as being reserved for only process data or a mechanism for moving kernel data structures could be introduced.
I/O memory regions will also be pluggable. These are far easier than regular memory regions. They are owned by a single driver, and would only need to be released by that driver in order to be unplugged.
Another possibility is pluggable processors. Linux already has support for adding and removing processors, so once UML has SMP support, this will come for free. So, the mconsole will use the existing code to allow plugging and unplugging processors.