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

[Daniel P. Berrange]

On Tue, Jun 23, 2009 at 02:28:38PM +0300, Avi Kivity wrote:
> On 06/23/2009 01:54 PM, Jan Kiszka wrote:
> >>It would be a nightmare, consider both libvirt and a user hotplugging
> >>something into the same pci slot, or a user starting migration, or
> >>quitting, or ...
> >>     
> >
> >Migration, yes, but hot-plugging is resolvable - given config update 
> >events.
> >   
> 
> I'm not saying it's impossible, just that we don't want to do it.
> 
> >>Having -monitor readonly makes sense.
> >>     
> >
> >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. 

Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|