Re: [libvirt-users] libvirtd vs XDG_RUNTIME_DIR
Lars Kellogg-Stedman <lars(a)redhat.com>
writes:
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,
I've run into the same problem, while trying to inspect the VM that
users have made using qemu:///session on a shared shell server.
I reached the conclusion that the ultimate problem was, as is suggested
elsewhere in this thread, with PAM, and how su does not register a new
session with PAM/logind/systemd. As far as I know, there is no widely
used way for an administrator to get a shell as some user, registered
with PAM, without first authenticating specifically as that user.
(There is machinectl shell, but that is pretty new, and also rather
inflexible.)
I solved this problem by writing a small Kerberos plugin to allow
administrator principals in our domain to authenticate as any Unix user;
then to use qemu:///session, they can simply ssh in. This also allows
administrators to use qemu+ssh://someuser@host/session on remote hosts.