Bug 832011 - /var/lib/libvirt/qemu access problem cause vdsm vm start failure
/var/lib/libvirt/qemu access problem cause vdsm vm start failure
Product: Virtualization Tools
Classification: Community
Component: libvirt (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Martin Kletzander
Depends On:
  Show dependency treegraph
Reported: 2012-06-14 05:48 EDT by Royce Lv
Modified: 2013-10-11 05:35 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-10-11 05:35:25 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Royce Lv 2012-06-14 05:48:45 EDT
Description of problem:
when libvirt installed:
[lvroyce@lvroyce-pc log]$ sudo ls /var/lib/libvirt/qemu -ld
drwxr-x---. 3 qemu qemu 4096 Jun 14 17:34 /var/lib/libvirt/qemu
after libvirtd started:
[lvroyce@lvroyce-pc log]$ sudo ls /var/lib/libvirt/qemu -ld
drwxr-x---. 6 root root 4096 Jun 14 17:36 /var/lib/libvirt/qemu

when vdsm using libvirt to start a vm, it needs access of /var/lib/libvirt/qemu/channels/

Version-Release number of selected component (if applicable):
HEAD is:
commit 2d98c6866277332ac63b53bb1345787e428bd491
Author: Guido Günther <agx@sigxcpu.org>
Date:   Fri Jun 8 21:24:13 2012 +0200


How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:
Comment 1 Royce Lv 2012-06-14 06:10:57 EDT
libvirt log:
2012-06-14 10:03:20.277+0000: 22946: debug : virDomainCreateXML:1907 : conn=0x7fabec00df10, xmlDesc=<?xml version="1.0" encoding="utf-8"?>
<domain type="kvm">
                <channel type="unix">
                        <target name="com.redhat.rhevm.vdsm" type="virtio"/>
                        <source mode="bind" path="/var/lib/libvirt/qemu/channels/vm17.com.redhat.rhevm.vdsm"/>
                <input bus="ps2" type="mouse"/>
                <graphics autoport="yes" listen="0" passwd="*****" passwdValidTo="1970-01-01T00:00:01" port="-1" type="vnc"/>
                <console type="pty">
                        <target port="0" type="virtio"/>
                <controller index="0" ports="16" type="virtio-serial"/>
                        <model heads="1" type="cirrus" vram="65536"/>
                <interface type="bridge">
                        <mac address="52:54:00:59:F5:31"/>
                        <model type="virtio"/>
                        <source bridge="virbr0"/>
                <memballoon model="none"/>
                <disk device="disk" snapshot="no" type="block">
                        <source dev="/rhev/data-center/5c84a9d2-be25-49a9-bcb2-2f0f5b906068/1114a9d2-be25-49a9-bcb2-2f0f5b906066/images/87f5f391-5b83-4e7f-9072-7f5026655068/ce73fdd0-2630-40ca-b2df-a0dd90674068"/>
                        <target bus="ide" dev="hda"/>
                        <driver cache="none" error_policy="stop" io="native" name="qemu" type="qcow2"/>
                <disk device="cdrom" snapshot="no" type="file">
                        <source file="/home/lvroyce/pkg/Fedora-16-x86_64-Live-Desktop.iso" startupPolicy="optional"/>
                        <target bus="ide" dev="hdc"/>
                <type arch="x86_64" machine="pc">hvm</type>
                <boot dev="hd"/>
                <smbios mode="sysinfo"/>
        <sysinfo type="smbios">
                        <entry name="manufacturer">Red Hat</entry>
                        <entry name="product">RHEV Hypervisor</entry>
                        <entry name="version">16-1</entry>
                        <entry name="serial">0EA0A181-50B2-11CB-BBE1-DFC7A7500304_00:21:cc:62:a6:07</entry>
                        <entry name="uuid">f7c1b02f-b304-4e68-8565-3659b1214069</entry>
        <clock adjustment="0" offset="variable">
                <timer name="rtc" tickpolicy="catchup"/>
        <cpu match="exact">
                <feature name="svm" policy="disable"/>

2012-06-14 10:03:20.781+0000: 22946: error : virNetClientProgramDispatchError:174 : internal error Process exited while reading console log output: bind(unix:/var/lib/libvirt/qemu/vm17.monitor): Permission denied
chardev: opening backend "socket" failed: Permission denied
Comment 2 Dave Allan 2012-06-14 11:10:55 EDT
Martin, can you have a look?
Comment 3 Martin Kletzander 2012-07-17 08:29:46 EDT

libvirt changes the permissions in order to fit the qemu process (sometimes as tight as possible) because a lot of reasons. My opinion is that VDSM should handle this problem and I see two options how to get to it:
 1) either specify 'user' and 'group' options in /etc/libvirt/qemu.conf to meet the ones vdsm is running as or
 2) create the channel device with source path heading to some other location (/var/lib/vdsm... maybe)

Isn't vdsm already doing something like that, Dan?
Comment 4 Dan Kenigsberg 2012-07-17 09:32:58 EDT
We would like to keep qemu processes running as qemu:qemu.

I do not understand why Vdsm should play with /var/lib/libvirt/qemu/vm17.monitor - it is not using the monitor socket directly, it is a libvirt implementation detail.

We do add
   <channel type="unix">
       <target name="com.redhat.rhevm.vdsm" type="virtio"/>
       <source mode="bind" path="/var/lib/libvirt/qemu/channels/vm17.com.redhat.rhevm.vdsm"/>
and we do hack our way to let vdsm write to it, but the error seems to be related to the monitor socket mentioned above.t all?
Comment 5 Martin Kletzander 2012-07-17 10:03:56 EDT
(In reply to comment #4)
Sorry Dan, I misread the error. In the description there was /var/lib/libvirt/qemu/channels/vm17.com.redhat.rhevm.vdsm and I thought it was the same thing there's permission problem with in the error.

Royce, may I ask you to check the permissions for /var/lib/libvirt/qemu/vm17.monitor with SELinux context as well and check as what user/group the qemu process is being ran? It should be in /etc/libvirt/qemu.conf

Comment 6 Martin Kletzander 2013-10-11 05:35:25 EDT
In case there are new data available, feel free to reopen this bug, but for now, I'm closing it as INSUFFICIENT_DATA.

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