This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 856611 - libvirt configurable paths
libvirt configurable paths
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt (Show other bugs)
6.3
All Unspecified
unspecified Severity medium
: rc
: ---
Assigned To: Libvirt Maintainers
Virtualization Bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-12 08:32 EDT by Saveliev Peter
Modified: 2013-10-31 20:59 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-09-13 04:09:15 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:32:12 EDT
As it seems, there is nothing to prevent us running several libvirt instances — except of hardcoded pathes to the libvirt socket, images directory and so on.

Keeping in mind libvirt driver lock (https://bugzilla.redhat.com/show_bug.cgi?id=856609), it is a serious limitation of libvirt scalability: there is no use of several CPU while creating VMs (and, maybe, not only creating, but we stuck on this with creating).

It would be nice to make such pathes configurable (with default values == what it uses right now). I will allow us to run several libvirtd instances w/o usage of FS namespaces, that is not too trivial.
Comment 1 Daniel Berrange 2012-09-12 08:38:01 EDT
The libvirt design is such that there is 1 instance of libvirt which runs privilege, and optionally 1 instance per non-root user account which run unprivileged. Running multiple privileged libvirtd instances is a non-goal.

What is your use case for having multiple privileges instances of libvirtd ?
Comment 3 Saveliev Peter 2012-09-13 03:54:36 EDT
There is a scalability issue with libvirt on hosts with many CPUs, caused by the driver lock (see bz#856609). It can be solved either on the driver level, or with several libvirtd instances. The former is the better, but one doesn't exclude another.
Comment 4 Daniel Berrange 2012-09-13 04:09:15 EDT
We are not going to support running multiple instances of libvirtd just to hack around that bug. That bug should simply be fixed.
Comment 5 Dave Allan 2012-09-13 10:50:53 EDT
Agreed, we should focus our scalability efforts on improving locking.

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