Hide Forgot
---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
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
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.
Upstream patch proposed: https://www.redhat.com/archives/libvir-list/2011-March/msg00769.html
In POST: http://post-office.corp.redhat.com/archives/rhvirt-patches/2011-March/msg00511.html
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 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
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 From pradeepkumars.com 2011-04-07 12:27 EDT------- its fixed. can close this bug --Pradeep
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