The problem is that you are attempting to create the sockets in the directory which libvirt uses to create the sockets. The naming convention of a new VM thus follows the path which libvirt would use.

If you attempt to create the sockets in path other than /var/lib/libvirt/qemu/channel/target it should work as expected.

Since the path is indented to use by libvirt's internal files, user specified paths should not lead here.

Technical note:

The following function clears the path if it's in the libvirt's channel directory:

/*
 * Clear auto generated unix socket path, i.e., the one which starts with our
 * channel directory.
 */
static void
qemuDomainChrDefDropDefaultPath(virDomainChrDefPtr chr,
                                virQEMUDriverPtr driver)
{
    virQEMUDriverConfigPtr cfg = virQEMUDriverGetConfig(driver);

    if (chr->deviceType == VIR_DOMAIN_CHR_DEVICE_TYPE_CHANNEL &&
        chr->targetType == VIR_DOMAIN_CHR_CHANNEL_TARGET_TYPE_VIRTIO &&
        chr->source->type == VIR_DOMAIN_CHR_TYPE_UNIX &&
        chr->source->data.nix.path &&
        STRPREFIX(chr->source->data.nix.path, cfg->channelTargetDir)) {
        VIR_FREE(chr->source->data.nix.path);
    }

    virObjectUnref(cfg);
}

Peter, may I ask whether and where this behaviour is documented (aside from
the code itself)?

Hmm, this aspect is not documented in the libvirt docs. On the other hand, according to the linux filesystem hierarchy standard ([1], man 7 hier) there's a reasonable expectation that the data in /var/lib belongs to the application and thus users should not touch it.

[1] https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard :

/var/lib - State information. Persistent data modified by programs as they run, e.g., databases, packaging system metadata, etc. [1]

Regardless of what the FHS says, we've been recommending that people use /var/lib/libvirt/qemu for VM channel sockets whenever anyone has asked, since that's the directory which works reliably out of the box wrt SELinux labelling. So blowing away the user's data in this way is not desirable.

That way it's hard to guarantee that the user does not mess up their configuration by using a path that would be generated automatically by libvirtd for new VMs, where the new VM would fail to start.

The key issue is that this was a valid XML configuration the user had, and we're silently changing their data which is liable to break their app usage. The reason libvirt changed its own autogenerated paths was sensible, to fix problem with SELinux labelling in some particular scenarios, but that's not enough justification to break user specified paths which were previously working fine.

The only thing we can do is to improve the pattern that is used to detect whether the path was auto-generated or not.

These are the patterns that we've ever used:

  $CHANNEL_TARGET_DIR/$DOM_NAME.$TARGET_NAME                      (1.2.18 and older)
  $CHANNEL_TARGET_DIR/domain-$DOM_NAME/$TARGET_NAME               (1.2.19 - 1.3.2)
  $CHANNEL_TARGET_DIR/domain-%ID-%DOM_NAME_SHORT/$TARGET_NAME     (1.3.3 and newer)

where $CHANNEL_TARGET_DIR on most systems is:

  /var/lib/libvirt/qemu/channel/target         (for system libvirtd)
  /home/$USER/.config/qemu/channel/target      (for session libvirtd)

For automatically generated paths Libvirt creates required directories in order to create the UNIX socket and that changed in past.  Historically we've stored the automatically generated paths in the config XML, but since 1.3.1 Libvirt we generate the paths while starting domain and store the path only in the active XML.

For config XML created by Libvirt older than 1.3.1 there is no way how to determine whether the path was auto-generated or not if it matches the pattern that we used.

Improving the pattern would fix this bug because the path doesn't match any of our automatically generated path, however if user would specify path, that matches one of the mentioned patterns we still remove that path from config XML and generate a new one while starting a domain.

Upstream commit:

commit ed996604464ab1652ad8d2de3ac446f460dd2ab1
Author: Pavel Hrdina <phrdina>
Date:   Thu May 11 14:09:35 2017 +0200

    qemu: improve detection of UNIX path generated by libvirt

Cool, thank you! :) Could you add the patterns in comment #8 to the libvirt
documentation as well? That also would make clear which paths should be not
used to avoid clashes with generated ones.

Verified with libvirt-3.2.0-7.el7.x86_64 & libvirt-3.2.0-7.virtcov.el7.x86_64. 
1. Created /var/lib/libvirt/qemu/channel/target/tux directory and chown qemu:qemu  tux. 
2. Use below configuration which described in bug:

    <channel type='unix'>
      <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/tux/org.qemu.guest_agent.0'/>
      <target type='virtio' name='org.qemu.guest_agent.0'/>
      <address type='virtio-serial' controller='0' bus='0' port='2'/>
    </channel>
    <channel type='unix'>
      <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/tux/com.redhat.rhevm.vdsm'/>
      <target type='virtio' name='com.redhat.rhevm.vdsm'/>
      <address type='virtio-serial' controller='0' bus='0' port='3'/>
    </channel>

Start the VM.

3.The /var/lib/libvirt/qemu/channel/target/tux/org.qemu.guest_agent.0
and /var/lib/libvirt/qemu/channel/target/tux/com.redhat.rhevm.vdsm were created as expected.

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/RHEA-2017:1846

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/RHEA-2017:1846