Bug 832011
Summary: | /var/lib/libvirt/qemu access problem cause vdsm vm start failure | ||
---|---|---|---|
Product: | [Community] Virtualization Tools | Reporter: | Royce Lv <lvroyce> |
Component: | libvirt | Assignee: | Martin Kletzander <mkletzan> |
Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | unspecified | CC: | acathrow, dallan, danken |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2013-10-11 09:35:25 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Royce Lv
2012-06-14 09:48:45 UTC
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 Martin, can you have a look? 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? 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? (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 In case there are new data available, feel free to reopen this bug, but for now, I'm closing it as INSUFFICIENT_DATA. |