Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API

[Anthony Liguori]

Richard W.M. Jones wrote:
> Anthony Liguori wrote:
> > Daniel P. Berrange wrote:
> > > Or have 2 monitor interaction modes. One mode uses the command line 
> > > style
> > > suitable for people / scripting languages. The other umode ses a 
> > > binary XDR
> > > protocol for serializing the args & returns values for formal control
> > > APIs to use in a easy manner. It ought to be reasonably 
> > > straightforward to
> > > add a binary serialization format for all existing commands
> > >   
> >
> > I don't think binary is inherently easier to parse than text provided 
> > that some thought is put into the format of the textual output.
>
> XDR (aka RFC 1014 & RFC 4506) does let you generate complex interfaces 
> with relative ease.  For example, here's the description of the remote 
> protocol used by libvirt:
>
> http://git.et.redhat.com/?p=libvirt.git;a=blob;f=qemud/remote_protocol.x;h=d409c74387c2642651896136aba9bc1e2b62b621;hb=HEAD 
>
>
> "Parsing" is done for you by stubs that are generated from the above 
> file.
>
> On the downside it turns out that it's not very well supported under 
> Windows.  For libvirt I had to basically port an XDR implementation by 
> hand to MinGW and add extra functions from glibc to it.
>
> > I think we just want to levels of verbosity.
>
> This would work too.
>
> On the point of controlling multiple qemu instances on a machine from 
> a single place: Easiest way to do this would be to direct all the 
> monitor sockets into a single known directory.  Something along the 
> lines of:
>
>   qemu -monitor unix:/var/lib/qemu-monitors/`uuidgen`,nowait
>
> A control process can then just keep an eye on entries under that 
> directory, and (unlike libvirtd) it's robust against the control 
> process restarting.

Actually, this was the original intention of the -name parameter.  What 
a management tool would want to do is:

1) if -name is specified by user, generate one with uuidgen
2) pass -name <name> and -pidfile /path/to/well/known/location/name.pid

This will ensure uniqueness of name without requiring the creation tool 
to maintain any state (so no daemon is required).  Right now, you would 
also have to store a monitor socket in that well known path.  However, 
I'm working on a VNC tunnels patch right now that would allow the 
monitor to be tunneled through a VNC session.  The idea here is that a 
management tool could just store a hint about the VNC location and then 
you can get at the rest of the character devices through the VNC session.

Otherwise, you end up with a bunch of temporary sockets for things like 
the monitor, serial devices, parallel devices, etc.

Regards,

Anthony Liguori

> Rich.