Bug 856609 - libvirt driver lock is held for too long
libvirt driver lock is held for too long
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt (Show other bugs)
6.3
All Unspecified
unspecified Severity high
: rc
: ---
Assigned To: Martin Kletzander
Virtualization Bugs
: Rebase, Upstream
Depends On:
Blocks: 781975 861918
  Show dependency treegraph
 
Reported: 2012-09-12 08:18 EDT by Saveliev Peter
Modified: 2014-04-04 17:00 EDT (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Rebase: Bug Fixes and Enhancements
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-04-04 17:00:30 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Saveliev Peter 2012-09-12 08:18:16 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.
Comment 2 Daniel Berrange 2012-09-13 05:50:20 EDT
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.
Comment 5 Alex Jia 2012-09-18 04:29:34 EDT
(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.

Hi Saveliev,

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.

Regards,
Alex
Comment 10 Daniel Berrange 2012-12-12 10:57:41 EST
Proposal upstream for how to properly solve the libvirt concurrency issues long term

https://www.redhat.com/archives/libvir-list/2012-December/msg00717.html
Comment 18 RHEL Product and Program Management 2014-04-04 17:00:30 EDT
Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.

Note You need to log in before you can comment on or make changes to this bug.