On Fri, Apr 23, 2010 at 08:48:51AM -0500, Anthony Liguori wrote:
On 04/23/2010 07:48 AM, Avi Kivity wrote:
On 04/22/2010 09:49 PM, Anthony Liguori wrote:
real API. Say, adding a device libvirt doesn't know about or stopping the VM while libvirt thinks it's still running or anything like that. Another problem is issuing Monitor commands that could confuse libvirt's
We need to make libvirt and qemu smarter.
We already face this problem today with multiple libvirt users. This is why sophisticated management mechanisms (like LDAP) have mechanisms to do transactions or at least a series of atomic operations.
And people said qmp/json was overengineered...
But seriously, transactions won't help anything. qemu maintains state, and when you have two updaters touching a shared variable not excepting each other to, things break, no matter how much locking there is.
Let's consider some concrete examples. I'm using libvirt and QMP and in QMP, I want to hot unplug a device.
Today, I do this by listing the pci devices, and issuing a pci_del that takes a PCI address. This is intrinsically racy though because in the worst case scenario, in between when I enumerate pci devices and do the pci_del in QMP, in libvirt, I've done a pci_del and then a pci_add within libvirt of a completely different device.
This is what already happens with any QEMU >= 0.12, where libvirt uses the new -device syntax with its 'id' parameter for all devices, and then uses 'device_id $ID' for unplug. The app still has to be careful it doesn't try to add a device using the same naming scheme as a device libvirt uses. This is easy enough though if they prepend some random string to all device IDs thy use, that won't clash with libvirt device ID names. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|