I found a upstream commit can fix the bug.
https://www.redhat.com/archives/libvir-list/2014-October/msg00502.html

commit 302720742f6e159af45631475d720cf807e905b9
Author: Maxime Leroy <maxime.leroy>
Date:   Fri Oct 17 18:45:18 2014 +0200

    conf: tests: fix virDomainNetDefFormat for vhost-user in client mode
    
    The mode attribute is required for the source element of vhost-user.
    Thus virDomainNetDefFormat should always generate a xml with it and not
    only when the mode is server.
    
    The commit fixes the issue. And it adds a vhostuser interface in
    'client' mode to qemuxml2argv-net-vhostuser.(args|xml) to test this
    usecase.

I can not reproduce the bug using libvirt-1.2.8-6.el7.x86_64

Version:
libvirt-1.2.8-6.el7.x86_64
qemu-kvm-1.5.3-77.el7.x86_64
kernel-3.10.0-187.el7.x86_64

[root@ibm-x3850x5-06 ~]# virsh dumpxml r7 | grep "/interface" -B5
    <interface type='vhostuser'>
      <mac address='52:54:00:3b:83:1a'/>
      <source type='unix' path='/var/lib/libvirt/qemu/vhost.sock' mode='client'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>

Question:
But the domain can not boot up.
<1> When we have a server which is running
[root@ibm-x3850x5-06 ~]#  virsh dumpxml test | grep "/interface" -B5
    <interface type='vhostuser'>
      <mac address='52:54:00:3b:83:1a'/>
      <source type='unix' path='/var/lib/libvirt/qemu/vhost.sock' mode='server'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>
[root@ibm-x3850x5-06 ~]# virsh start test
      <======The domain is waiting for the client,please refer to Bug 1156267.

[root@ibm-x3850x5-06 ~]# virsh start r7
error: Failed to start domain r7
error: internal error: process exited while connecting to monitor: 2014-11-05T15:11:58.707970Z qemu-kvm: -chardev socket,id=charnet0,path=/var/lib/libvirt/qemu/vhost.sock: Failed to connect to socket: Permission denied
2014-11-05T15:11:58.708122Z qemu-kvm: -chardev socket,id=charnet0,path=/var/lib/libvirt/qemu/vhost.sock: chardev: opening backend "socket" failed

<2> When have no server
[root@ibm-x3850x5-06 ~]# virsh start r7
error: Failed to start domain r7
error: internal error: process exited while connecting to monitor: 2014-11-05T15:24:45.329499Z qemu-kvm: -chardev socket,id=charnet0,path=/var/lib/libvirt/qemu/vhost.sock: Failed to connect to socket: Connection refused
2014-11-05T15:24:45.329642Z qemu-kvm: -chardev socket,id=charnet0,path=/var/lib/libvirt/qemu/vhost.sock: chardev: opening backend "socket" failed

For scenario <1> above, why can not domain start? Is it a bug?
For scenario <2> above, I think it's expected, do you agree?

Full log for scenario <1>:
[root@ibm-x3850x5-06 ~]# cat /var/log/libvirt/qemu/r7.log
2014-11-05 15:13:22.820+0000: starting up
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=spice /usr/libexec/qemu-kvm -name r7 -S -machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off -m 1024 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid a70da21c-ffe1-4dca-b348-62e44035a6b6 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/r7.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device ahci,id=ahci0,bus=pci.0,addr=0x7 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=/var/lib/libvirt/images/r7.img,if=none,id=drive-virtio-disk0,format=raw,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x8,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -chardev socket,id=charnet0,path=/var/lib/libvirt/qemu/vhost.sock -netdev type=vhost-user,id=hostnet0,chardev=charnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:3b:83:1a,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -spice port=5901,addr=127.0.0.1,disable-ticketing,seamless-migration=on -vga qxl -global qxl-vga.ram_size=67108864 -global qxl-vga.vram_size=67108864 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device usb-host,hostbus=6,hostaddr=2,id=hostdev0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 -msg timestamp=on
2014-11-05T15:13:22.864095Z qemu-kvm: -chardev socket,id=charnet0,path=/var/lib/libvirt/qemu/vhost.sock: Failed to connect to socket: Permission denied
2014-11-05T15:13:22.864234Z qemu-kvm: -chardev socket,id=charnet0,path=/var/lib/libvirt/qemu/vhost.sock: chardev: opening backend "socket" failed
2014-11-05 15:13:23.037+0000: shutting down

Yes for the scenario <2> the error is expected.

For the scenario <1> there is a missing selinux policy that allows guest connect to existing unix_socket_stream. I've created a Bug 1161217 to track the issue for selinux-policy component.

(In reply to Pavel Hrdina from comment #6)
> Yes for the scenario <2> the error is expected.
> 
> For the scenario <1> there is a missing selinux policy that allows guest
> connect to existing unix_socket_stream. I've created a Bug 1161217 to track
> the issue for selinux-policy component.

OK, thanks.

According to comment 5 and 6, we can get expected results, so change to Verified.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2015-0323.html