RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 684655 - virsh doesnt work as an unprivileged user
Summary: virsh doesnt work as an unprivileged user
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt
Version: 6.1
Hardware: x86_64
OS: All
high
high
Target Milestone: rc
: 6.1
Assignee: Eric Blake
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On: 675698
Blocks: 684385 684848
TreeView+ depends on / blocked
 
Reported: 2011-03-14 06:51 UTC by IBM Bug Proxy
Modified: 2011-05-19 13:28 UTC (History)
8 users (show)

Fixed In Version: libvirt-0.8.7-14.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-05-19 13:28:56 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
IBM Linux Technology Center 70630 0 None None None Never
Red Hat Product Errata RHBA-2011:0596 0 normal SHIPPED_LIVE libvirt bug fix and enhancement update 2011-05-18 17:56:36 UTC

Description IBM Bug Proxy 2011-03-14 06:51:06 UTC 
---Problem Description---
virsh doesnt work if we login to host as an unprivileged user.

Error message:

$ virsh
error: cannot recv data: : Connection reset by peer
error: failed to connect to the hypervisor
 
---uname output---
2.6.32-118.el6.x86_64
 
Machine Type = hs22 
 
---Debugger---
A debugger is not configured
 
---Steps to Reproduce---
 1. Bootup 6.1 host and login as unprivileged user
2. just "virsh" command fails. 


Kernel version: 
2.6.32-118.el6.x86_64

Qemu version: 
qemu-kvm-0.12.1.2-2.148.el6.x86_64

Host Machine Type: HS22

Test Type:  manual. 

dmesg: havent noticed any


cat /proc/cpuinfo

Total : 8 cpus
-------
processor       : 7
vendor_id       : GenuineIntel
cpu family      : 6
model           : 26
model name      : Intel(R) Xeon(R) CPU           X5570  @ 2.93GHz
stepping        : 5
cpu MHz         : 1596.000
cache size      : 8192 KB
physical id     : 0
siblings        : 8
core id         : 3
cpu cores       : 4
apicid          : 7
initial apicid  : 7
fpu             : yes
fpu_exception   : yes
cpuid level     : 11
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm
constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf
pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 sse4_2
popcnt lahf_lm tpr_shadow vnmi flexpriority ept vpid
bogomips        : 5865.76
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management:
-----------------

 
=Comment: #2=================================================
PRADEEP K. SURISETTY <pradeepkumars.com> - 
1.Server architecture(s) (please list all effected) (x86/POWER6/Z/etc.):
x86

2.Server type (9117-MMA/HS20/s390/etc.): 
HS22

3.General component (desktop/kernel/base OS/dev tools/etc.):

virsh

4.Other components involved (ixgbe/java/emulex/etc.):

nope

5.Does the server have the latest GA firmware? 

yep

6.Has the problem been shown to occur on more than one system? 

yes

7.Is a tested patch available? 

nope

  If yes to the above, has it been approved upstream? 
8.What is the latest official Red Hat build on which this bug has been
seen? 6.1 Alpha
Comment 2 Eric Blake 2011-03-14 20:45:09 UTC 
As pointed out in bug 684848:

This appears to be the real regression - virsh is trying to auto-starting the session daemon, but that fails:

$ /usr/sbin/libvirtd --timeout=30
13:06:02.502: 24377: info : libvirt version: 0.8.7, package: 10.el6 (Red Hat,
Inc. <http://bugzilla.redhat.com/bugzilla>, 2011-03-07-14:14:56,
x86-003.build.bos.redhat.com)
13:06:02.502: 24377: error : virStateInitialize:1022 : Initialization of udev
state driver failed
13:06:02.520: 24377: warning : qemudStartup:1733 : Unable to create cgroup for
driver: Permission denied
13:06:02.771: 24377: error : main:3305 : Driver state initialization failed
13:06:02.771: 24379: warning : qemudDispatchSignalEvent:403 : Shutting down on
signal 3
Comment 3 Eric Blake 2011-03-16 19:41:33 UTC 
It appears that the problem is that pci_system_init() fails when run as non-root, which in turn fails node_device_udev.c:udevDeviceMonitorStartup, which in turn makes the libvirtd startup code assume that it must abort.

This function call lived in udevTranslatePCIIds for RHEL 6.0; it was moved into udevDeviceMonitorStartup during upstream commit 2215050edd:

commit 2215050edd8adefbf0ff21c5cbf09685877492d6
Author: Daniel P. Berrange <berrange>
Date:   Mon Feb 7 17:04:35 2011 +0000

    Only initialize/cleanup libpciaccess once
    
    libpciaccess has many bugs in its pci_system_init/cleanup
    functions that makes calling them multiple times unwise.
    eg it will double close() FDs, and leak other FDs.
    
    * src/node_device/node_device_udev.c: Only initialize
      libpciaccess once

which was backported into libvirt-0.8.7-12.el6 as patch102 in order to fix 675698, thus this qualifies as a regression.

It looks like the fix might be to ignore pci_system_init failure for non-privileged users.
Comment 4 Eric Blake 2011-03-16 21:49:58 UTC 
Upstream patch proposed:
https://www.redhat.com/archives/libvir-list/2011-March/msg00769.html
Comment 5 Eric Blake 2011-03-21 17:06:15 UTC 
In POST:
http://post-office.corp.redhat.com/archives/rhvirt-patches/2011-March/msg00511.html
Comment 7 zhanghaiyan 2011-03-23 01:44:49 UTC 
Verified this bug PASS with libvirt-0.8.7-14.el6.x86_64
[test@dhcp-65-132 ~]$ virsh
Welcome to virsh, the virtualization interactive terminal.

Type:  'help' for help with commands
       'quit' to quit

virsh # list --all
 Id Name                 State
----------------------------------

virsh # nodedev-list --tree
computer
 |
  +- net_lo_00_00_00_00_00_00
  +- net_virbr0_nic_52_54_00_e0_db_11
  +- net_vnet0_fe_54_00_b7_bc_20
  +- net_vnet1_fe_54_00_21_be_6a
  +- pci_0000_00_00_0
....
Comment 8 IBM Bug Proxy 2011-03-23 04:40:45 UTC 
------- Comment From pradeepkumars.com 2011-03-23 00:32 EDT-------
Hello yoyzhang

can we expect libvirt-0.8.7-14.el6.x86_64 in snap1.

--Pradeep
Comment 9 zhanghaiyan 2011-03-23 05:46:56 UTC 
Hi, Pradeep

IMHO, we could get libvirt-0.8.7-14.el6.x86_64 or newer version in snap1. 
Anything unsure, please let me know.

- Yoyo

(In reply to comment #8)
> ------- Comment From pradeepkumars.com 2011-03-23 00:32 EDT-------
> Hello yoyzhang
> 
> can we expect libvirt-0.8.7-14.el6.x86_64 in snap1.
> 
> --Pradeep
Comment 10 IBM Bug Proxy 2011-04-07 16:33:39 UTC 
------- Comment From pradeepkumars.com 2011-04-07 12:27 EDT-------
its fixed. can close this bug

--Pradeep
Comment 13 errata-xmlrpc 2011-05-19 13:28:56 UTC 
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0596.html
Note You need to log in before you can comment on or make changes to this bug.