|
From: | Avi Kivity |
Subject: | [Qemu-devel] Re: [PATCH 11/11] QMP: Command-line flag to enable control mode |
Date: | Tue, 23 Jun 2009 14:28:38 +0300 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Lightning/1.0pre Thunderbird/3.0b2 |
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.
See, I don't want to kill my management app just because I attached to a guest via gdb and start injecting reconfiguration events for testing purposes (e.g. attach/detach a USB device for which I develop a driver).
You're talking about a usb developer, not a qemu developer, working in some virtual lab environment? In that case, libvirt and the management app should certainly support usb. A random usb developer shouldn't need to ever talk to the qemu monitor.
-- error compiling committee.c: too many arguments to function
[Prev in Thread] | Current Thread | [Next in Thread] |