qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file


From: Jamie Lokier
Subject: Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file
Date: Wed, 24 Jun 2009 20:01:29 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

Chris Webb wrote:
> Anthony Liguori <address@hidden> writes:
> 
> > There are two questions to resolve.  The first is whether we should  
> > continue with the current direction (line-based protocol) or whether we  
> > should switch to an RPC.  The second question is which RPC we should use.
> >
> > I'm not at all convinced that we should switch to an RPC mechanism in  
> > the first place.  Perhaps someone could summarize the advantages of  
> > doing this because right now, I don't see many.
> >
> > With respect to RPC choice, if we did go that route, I'd be very  
> > concerned about using jsonrpc verses a more well established rpc.  I  
> > would honestly prefer xml-rpc over jsonrpc.
> 
> We are an example of a end user of qemu (or more specifically qemu-kvm) that
> doesn't go via a management layer like libvirt. Our management shell scripts
> directly control the virtual machines using the current line-oriented 'human
> friendly' monitor. This is a bit of a pain, but not too bad in practice.

I do the same.  I even have a QEMU-monitor-multiplexor script, which
accepts multiple monitor connections and issues the commands over the
real monitor.  So that I can have one script managing (basically
insert/remove disk images, trigger reboots etc.), while still having
monitor accesss from the command line for those special extras.

> A more regular and well defined line-based protocol would be a big plus for
> us, whereas something like jsonrpc or xml-rpc would be a complete disaster
> to call from the shell---less useful than the current human oriented monitor
> rather than more so.

It's fine as long as there's a good shell-friendly utility.

Unfortunately my experience of using D-Bus through it's shell utility
was not positive.  You need the utility to do more than just pass the
whole request and response back and forth.  It needs to combine and
extract fields in compound structures, and escape/unescape when you
need that.

-- Jamie






reply via email to

[Prev in Thread] Current Thread [Next in Thread]