Bug 1597940

Libvirt switched to using FD passing for all UNIX sockets.

Unfortunately it appears QEMU has a bug which causes this to break vhostuser. I've sent a fix for the QEMU bug:

  https://lists.gnu.org/archive/html/qemu-devel/2018-07/msg01147.html

but we'll need to workaround it in libvirt too

(In reply to Daniel Berrange from comment #4)
> Libvirt switched to using FD passing for all UNIX sockets.
> 
> Unfortunately it appears QEMU has a bug which causes this to break
> vhostuser. I've sent a fix for the QEMU bug:
> 
>   https://lists.gnu.org/archive/html/qemu-devel/2018-07/msg01147.html
> 
> but we'll need to workaround it in libvirt too

Thanks Daniel. 

From QE perspective, a BZ in qemu-kvm-rhev component is needed, we file bug[1]  to track this issue:

[1]Bug 1598269 - vhost-user socket path is not recognized by libvirt - [QEMU side] 



Best Regards,
Pei

The libvirt fix is proposed here:

https://www.redhat.com/archives/libvir-list/2018-July/msg00316.html

this is *not* dependent on any QEMU change.

Update:

Versions:
libvirt-4.5.0-2.el7.x86_64


Results:
This bug can not be reproduced anymore with above version. Guest with vhost-user can boot up and works well as expected. 

Thanks Daniel for your efforts.

Verify this bug with libvirt-4.5.0-6.el7.x86_64:

1. install openvswitch + dpdk and set up env

2. prepare vhostuser server and client port:

# ovs-vsctl show
94687455-bb2b-48a1-8842-a68c6c62412b
    Bridge "ovsbr0"
        Port "vhost-user0"
            Interface "vhost-user0"
                type: dpdkvhostuserclient
                options: {vhost-server-path="/var/lib/libvirt/qemu/vhost0.sock"}
        Port "vhost-user2"
            Interface "vhost-user2"
                type: dpdkvhostuser
        Port "ovsbr0"
            Interface "ovsbr0"
                type: internal
        Port "vhost-user1"
            Interface "vhost-user1"
                type: dpdkvhostuser

3. Add vhost-user network in guest xml:

    <interface type='vhostuser'>
      <mac address='18:66:da:5f:dd:22'/>
      <source type='unix' path='/var/lib/libvirt/qemu/vhost0.sock' mode='server'/>
      <model type='virtio'/>
      <driver name='vhost' rx_queue_size='512'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/>
    </interface>
    <interface type='vhostuser'>
      <mac address='52:54:00:89:c3:cf'/>
      <source type='unix' path='/run/openvswitch/vhost-user1' mode='client'/>
      <model type='virtio'/>
      <driver name='vhost' rx_queue_size='512'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/>
    </interface>

4. start guest
# virsh start vm1
Domain vm1 started

5. check qemu cmdline and make sure libvirt use path for vhost-user device chardev:
# ps aux|grep qemu
...-chardev socket,id=charnet1,path=/var/lib/libvirt/qemu/vhost0.sock,server -netdev vhost-user,chardev=charnet1,id=hostnet1 -device virtio-net-pci,rx_queue_size=512,netdev=hostnet1,id=net1,mac=18:66:da:5f:dd:22,bus=pci.0,addr=0x8 -chardev socket,id=charnet2,path=/run/openvswitch/vhost-user1 -netdev vhost-user,chardev=charnet2,id=hostnet2 -device virtio-net-pci,rx_queue_size=512,netdev=hostnet2,id=net2,mac=52:54:00:89:c3:cf,bus=pci.0,addr=0x9

6. start guest with a unix channel (like agent):

    <channel type='unix'>
      <source mode='bind' path='/var/lib/libvirt/qemu/r6.agent'/>
      <target type='virtio' name='org.qemu.guest_agent.0'/>
      <address type='virtio-serial' controller='0' bus='0' port='1'/>
    </channel>

7. check libvirt will use fd instead of path in chardev:

# ps aux|grep qemu
-chardev socket,id=charchannel1,fd=29,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel1,id=channel1,name=org.qemu.guest_agent.0 -device usb-tablet,id=input0,bus=usb.0,port=2

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://access.redhat.com/errata/RHSA-2018:3113