Re: [Qemu-devel] Re: [PATCH 11/11] QMP: Command-line flag to enable control mode

[Avi Kivity]

On 06/23/2009 02:48 PM, Daniel P. Berrange wrote:
> > > But not for all features, only those libvirt is capable to handle (I
> > > think there are quite a few qemu specifics libvirt does not bother
> > > about) and only as long as there is no proper synchronization. Again,
> > > migration and save/restore will continue to require exclusive access,
> > > but the rest is just a question of proper synchronization IMHO.
> > >
> > >        
> > If libvirt "doesn't bother" about something useful, that's a libvirt
> > bug.  It's wierd to have something controlled by two parallel management
> > channels.
> >      
>
> It is not neccessaryily a 'bug'. The issue is that there is always a
> potential time lag between a feature appearing in QEMU, and it being
> fully supported in libvirt. So it is not a case of "doesnt' bother",
> but rather 'not yet known about'. I think we should make it possible
> for apps to be robust in this scenario, by allowing them to lockdown
> 2ndary monitor channels readonly.
>    

In this case I don't see much of an issue, since the time to implement a 
feature in libvirt is probably much shorter than the time needed to 
implement a proper GUI, database support, etc. that's needed for most 
features.  Short cutting through another interface is likely to cost 
more time than it saves.

--
error compiling committee.c: too many arguments to function