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(a)redhat.com> | larsks @ {freenode,twitter,github}
Cloud Engineering / OpenStack |
http://blog.oddbit.com/