[Qemu-devel] [PATCH] Remote console access though socket

[Daniel Veillard]

  Hi,

enclosed is a first version of a patch to allow remote access and control
for QEmu instances, I'm not suggesting to apply it as is (though it seems
to work in my limited testing) but would rather like to get comments back
for choices I'm facing. 
  First a bit of context, I'm working on libvirt (see
http://libvirt.org/) a library providing access to virtualization. I would
like to be able to handle QEmu instance like we do for Xen, the simpler 
would be to be able to list and connect to the console of running QEmu.
In an early mail last month Fabrice expressed interest in exporting the
console though TCP, so I hope I'm not too much off-track.
Enclosed are:
   - qemu-tcpctrl.patch: the patch to the existing code, it add tcpctrl
     as a configure option (on by default except on Windows), it plugs
     in main() of vl.c, add one entry point in console.c, and add a new
     module in the Makefile
   - tcpctrl.c: the C file, it currently use an unix socket
     /tmp/qemu-$pid-socket add a routine to start and stop the access
     and plug in the I/O handler of QEmu to wait for connections on it.
     When connections are accepted they are also plugged in the I/O
     handling, and receive commands. The commands are passed to console.c
     along with a minimal CharDriverState whose grite goes back to
     the associated connection.
   - client.c: a minimal client to send a command and get the output.
     use as './client /tmp/qemu-*-socket quit'

 There is a number of open questions which would need to be resolved before
applying any such patch:
   - First one is the unix socket, we could as easilly start normal port
     based access but:
     + I would really like to be able to list the current running instance
       without checking all process on the OS, and mapping in the file
       system seems the easiest way
     + the permission over the filesystem allows to set up the access policy
       without any special mechanism
     + in a port based access how do you guess the port numbers used by the
       QEmu instances
     the drawback of the file sockets are:
     + security: one need a directory where any user (since qemu isn't
       priviledged) can create a new file, and ensure safety over those
       accesses
     + cleanup: when qemu exits one need to clean up the socket, and 
       currently qemu has no central exit routine for this (and doesn't
       seems to trap signals leading to exit)
   - what about asynchronous events CharDriverState has structures in place
     for those, in general is that okay to keep some of the CharDriverState
     as NULL or should it trap every possible entries not just write()
   - the plug of the socket in the console framework is a bit crude, it just
     replace the global variable monitor_hd during the processing of the 
     request (c.f. monitor_process_command()).
   - the console -> socket code should try to coalesce multiple writes
     from the console into a single packet flushed at the end of the routine,
     and a marker for the end of the output from the command will help
     parsing at the client level.
   - ease of error handling on the client if possible, to generalize a
     bit go from a human targetted interaction to a machine  one.
   - command line configurations, for enabling/disabling the remote access
     and being able to specify the port number if using port, left open
     I didn't tried to address that

 So there is a bit too many open issues but IMHO nothing really hard, I would
just like to get feedback from other interested people.

Daniel

-- 
Daniel Veillard      | Red Hat http://redhat.com/
address@hidden  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

qemu-tcpctrl.patch
Description: Text document

tcpctrl.c
Description: Text document

client.c
Description: Text document