Currently we configure libvirtd and qemu to access pki artifacts located at /etc/pki/vdsm. This is <somewhat> well behaved, as we put our own artiacts at our own trust store. However, we do modify the entire machine configuration by altering libvirt. I would expect we could execute our own instance of libvirtd with our configuration located at /etc/vdsm... but this is a different issue. There is one exception, the libvirt client. We do not configure it, so it accesses the default libvirt pki artifacts. So we end up in hybrid solution, some artifacts are configured to use our trust stores, and some are used at libvirt default trust store. We should be more coherent, either we use libvirt while it access its default trust store for all artifacts, or we configure it to use our own trust store for all interfaces. Thanks for Dan who pointed me, the solution for configuration of the client is at[1], by using the pkipath, so it should be trivial to support. However, as we modify /etc/libvirt at a machine wide, there is no real difference between configuring libvirt to use our own resources or putting resources at libvirt default location. So both options are valid and trivial, while allowing libvirt to access its default store for all resources removes some lines of code... [1] http://libvirt.org/remote.html#Remote_URI_parameters
All the clients can be configured as well and I think by fair amount of "granularity". The configuration is system-wide in /etc/libvirt/libvirt.conf and user-wide in ~/.config/libvirt/libvirt.conf. In both these places you can either configure a default URI (with those parameters) or (and this I see as a better option) an 'alias', for example: uri_aliases = ['vdsm=qemu+tls://user@server/system?param1¶m2'] This would mean that whenever vdsm wants runs any libvirt client, it would supply this uri (e.g. virsh -c vdsm <command>) and that would have the configuration inside. You can use this alias even in API calls from all the bindings available. The second approach would mean that potential user can use any clients (virt-manager, virsh, etc.) without having to override the default address and configuration, whether vdsm would just use this alias to specify all those options needed and the certificates can thus be in any location you want without interfering with the user.
This request was not resolved in time for the current release. Red Hat invites you to ask your support representative to propose this request, if still desired, for consideration in the next release of Red Hat Enterprise Linux.
Vdsm does not use the pkipath-in-URI tricks only because they did not exist when vdsm was integrated with libvirt (see bug 629510). Now is a good time as any to clean up this mess.
If we can avoid the vdsmd reconfigure, it would be super! I guess there is more than pki artifacts to provide to libvirt at runtime.