Bug 887556 - [RFE] Consistent handling of libvirt pki artifacts
[RFE] Consistent handling of libvirt pki artifacts
Product: vdsm
Classification: oVirt
Component: RFEs (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified (vote)
: ---
: ---
Assigned To: Alon Bar-Lev
: FutureFeature
Depends On:
  Show dependency treegraph
Reported: 2012-12-16 06:22 EST by Alon Bar-Lev
Modified: 2016-04-18 02:52 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-09-20 18:11:22 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: Infra
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
alonbl: devel_ack?

Attachments (Terms of Use)

  None (edit)
Description Alon Bar-Lev 2012-12-16 06:22:39 EST
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
Comment 2 Martin Kletzander 2012-12-19 11:48:10 EST
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&param2']

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.
Comment 3 RHEL Product and Program Management 2012-12-23 01:47:42 EST
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.
Comment 6 Dan Kenigsberg 2013-03-20 17:00:31 EDT
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.
Comment 7 Alon Bar-Lev 2013-03-20 18:23:49 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.