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

[Dor Laor <dor.laor@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3339 bytes --]

Anthony Liguori wrote:
>
> 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.
>
While this is good for home usage, it does not match product needs because
you don't always want to allow the user of the VM to control it. For 
example,
the user might hack memory values from the monitor and comprise his 
permission
within the guest.
>
> Otherwise, you end up with a bunch of temporary sockets for things like
> the monitor, serial devices, parallel devices, etc.
>
Actually this is what we do in Qumranet to run multiple VMs.
We just need to improve/replace the monitor. Maybe enhancing the current 
implementation
as you suggested might be good enough, although library interface might 
be cleaner (no ugly return code
for the user).
Thanks,
Dor.

> Regards,
>
> Anthony Liguori
>
> > Rich.
> >
>
>
>


[-- Attachment #2: Type: text/html, Size: 4760 bytes --]