[libvirt-users] libvirtd vs XDG_RUNTIME_DIR

I ran into an odd problem today. I wanted to share it here in the hopes of maybe saving someone else some lost time. When you run libvirtd as an unprivileged user (e.g., if you target qemu:///session from a non-root account), then libvirt will open a unix domain socket in one of two places: - If XDG_RUNTIME_DIR is defined, then inside $XDG_RUNTIME_DIR/libvirt/libvirt-sock - If XDG_RUNTIME_DIR is *not* defined, then inside $HOME/.cache/libvirt/libvirt-sock With a CentOS 7 system, at least, if you ssh directly into an account, XDG_RUNTIME_DIR is set. But! If you `su -` to the account from root, e.g: # su - stack Then XDG_RUNTIME_DIR is *not* set. The problem is a little subtle, because most operations you will perform will work just fine in both cases: you can query for defined but not active guests, storagep pools, volumes, and so forth without a problem and you'll get the same answer. The problem crops up when you start a guest, which results in a persistent libvirtd process. Now, depending on how you got to your account, you will either (a) talk to the persistent process, and you'll be able to see the running guests, or (b) you'll end up spawning a new ephemeral libvirtd process listening in the *other* location, and you won't see anything, and you will wonder why there is a qemu process running for your guest but it's not showing up in "virsh list" and what the heck is going on here. I don't know if there's a good solution to this, but the failure mode is really non-obvious. Cheers, -- Lars Kellogg-Stedman <lars(a)redhat.com&gt; | larsks @ {freenode,twitter,github} Cloud Engineering / OpenStack | http://blog.oddbit.com/