Trying to setup qemu+tls here and I'm running into a few oddities (well that I feel are oddities) that I wanted clarification on before I submitted patches. The documentation I am following is: [1] http://libvirt.org/remote.html#Remote_certificates [2] http://wiki.libvirt.org/page/TLSSetup [3] http://wiki.libvirt.org/page/VNCTLSSetup All my storage is on iSCSI. I have 3 VM servers. 2 which every user can access and 1 which only a subset of users can access via the "tls_allowed_dn_list" parameter. Now how I envision this is that each of the 3 machines have their server certs & client certs in /etc/pki/libvirt, while each of the clients have their certs in $HOME/.pki/libvirt. That way a user, who doesn't have root or sudo access on the machine they are on could access the 2 VM servers they are allowed to access. However, if you look at the code, the only time $HOME/.pki/libvirt is used is when getuid() != 0 (this is correct) but the user either had to not specify a server to connect to and is using /session or you're auto-probing the local auto-spawned daemon for the remote URI. Effectively this means my approach can't happen. To complicate matters further, the documentation tells you to chown the client cert & key as root:root and set the permissions to 400. Which effectively means users can never use qemu+tls. I propose that we change the code for getuid() != 0 to always try $HOME/.pki/libvirt/ first and then try the system certificate. If everyone agrees, then I'll submit patches shortly. Additionally I wanted to note that as per [3], the default path for libvirt's user keys in $HOME differs from all other applications out there so I would also make it check $HOME/.pki/libvirt/private/clientkey.pem as well as $HOME/.pki/libvirt/clientkey.pem so that we'd match other application configurations. -- Doug Goldstein