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

[Avi Kivity <avi@redhat.com>]

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