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.