Red Hat Bugzilla – Bug 856609
libvirt driver lock is held for too long
Last modified: 2014-04-04 17:00:30 EDT
Description of problem:
Creating VM, libvirt lock the whole driver. It prevents VMs from parallel creation, but moreover: any other request are also waiting on this lock, any statistics and so on.
And while sequential VM creation can be tolerated as a «feature», blocking all other requests definitely is a bug.
Historically the primary reason why we held the driver lock was to prevent other threads creating VMs with clashing name or uuid. We also hold it for various ancillary things like protecting the VNC/SPICE port allocation, but those are very short time periods. We could also use a dedicated mutex just for the VNC/SPICE port db to avoid that issue.
To avoid having to hold the driver lock during actual VM creation, we should probably insert the virDomainObjPtr instance into the VM list immediately, with a shutoff state. Then drop the driver lock and start the VM. If VM start fails, then we can re-acquire the driver lock & remove the virDomainObjPtr. This should avoid holding of the driver lock over a non-negligable time period.
(In reply to comment #0)
> Description of problem:
> Creating VM, libvirt lock the whole driver. It prevents VMs from parallel
> creation, but moreover: any other request are also waiting on this lock, any
> statistics and so on.
> And while sequential VM creation can be tolerated as a «feature», blocking
> all other requests definitely is a bug.
As Daniel said, to hold driver lock should be a very short time periods, we have also test cases to concorrently create VM, but we haven't notice this question, I know we may check dirver lock is held time in libvirtd.log, however, I'm very interested in your test scenario and how to get some statistics data via tool or something like that, thanks.
Proposal upstream for how to properly solve the libvirt concurrency issues long term
Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.