In the tripleo-quickstart project, we're making use of libvirt's unprivileged mode. When run as a non-root user using a qemu:///session uri, libvirt creates files and sockets in subdirectories of $XDG_RUNTIME_DIR (aka /run/user/<uid>). We are seeing situations in which: - A "stack" user is created - Some libvirt resources (a storage pool) are provisioned for that user - The "stack" user is deleted (we first kill off any processes owned by the stack user, then delete the user via ansible which ultimately calls "userdel -r stack"). - The corresponding /run/user/<uid> directory is *not* deleted - A new "stack" user is created, and the stale storage pool from the previous invocation exists in an indeterminate state such at attempts to undefine it fail with: storage pool the_pool exists but directory /home/stack/pool is missing I can work around the problem like this: virsh pool-dumpxml the_pool | virsh pool-define /dev/stdin This ensures that a subsequent pool-undefine operation can successfully delete the pool. I think there are two problems here. Once is clearly a system problem; the /run/user directory should be deleted when the user account is deleted, period. The other problem seems like a libvirt problem: faced with a storage pool in this state, libvirt should permit the pool to be undefined anyway. It's possible this is already fixed in later releases of libvirt, but this is on CentOS 7, so we're stuck with libvirt-1.2.17-13.el7_2.3.x86_64 for now. I'm curious if anyone has seen this behavior or knows whether or not it has been corrected in later releases. Thanks, -- Lars Kellogg-Stedman <lars@redhat.com> | larsks @ {freenode,twitter,github} Cloud Engineering / OpenStack | http://blog.oddbit.com/