Bug 832011 - /var/lib/libvirt/qemu access problem cause vdsm vm start failure
/var/lib/libvirt/qemu access problem cause vdsm vm start failure
Status: CLOSED INSUFFICIENT_DATA
Product: Virtualization Tools
Classification: Community
Component: libvirt (Show other bugs)
unspecified
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Martin Kletzander
:
Depends On:
Blocks:
  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:
Environment:
Last Closed: 2013-10-11 05:35:25 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 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):
libvirt-0.9.12-1.fc16.x86_64
HEAD is:
commit 2d98c6866277332ac63b53bb1345787e428bd491
Author: Guido Günther <agx@sigxcpu.org>
Date:   Fri Jun 8 21:24:13 2012 +0200

vdsm:
vdsm-4.10.0-0.19.x86_64

How reproducible:


Steps to Reproduce:
1.
2.
3.
  
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">
        <name>vm17</name>
        <uuid>f7c1b02f-b304-4e68-8565-3659b1214069</uuid>
        <memory>1048576</memory>
        <currentMemory>1048576</currentMemory>
        <vcpu>1</vcpu>
        <devices>
                <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"/>
                </channel>
                <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"/>
                </console>
                <controller index="0" ports="16" type="virtio-serial"/>
                <video>
                        <model heads="1" type="cirrus" vram="65536"/>
                </video>
                <interface type="bridge">
                        <mac address="52:54:00:59:F5:31"/>
                        <model type="virtio"/>
                        <source bridge="virbr0"/>
                </interface>
                <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"/>
                        <serial>87f5f391-5b83-4e7f-9072-7f5026655068</serial>
                        <driver cache="none" error_policy="stop" io="native" name="qemu" type="qcow2"/>
                </disk>
                <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"/>
                        <serial></serial>
                </disk>
        </devices>
        <os>
                <type arch="x86_64" machine="pc">hvm</type>
                <boot dev="hd"/>
                <smbios mode="sysinfo"/>
        </os>
        <sysinfo type="smbios">
                <system>
                        <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>
                </system>
        </sysinfo>
        <clock adjustment="0" offset="variable">
                <timer name="rtc" tickpolicy="catchup"/>
        </clock>
        <features>
                <acpi/>
        </features>
        <cpu match="exact">
                <model>qemu64</model>
                <feature name="svm" policy="disable"/>
        </cpu>
</domain>

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
Hi,

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"/>
  </channel>
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

Thanks
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.