Bug 887556

Summary:	[RFE] Consistent handling of libvirt pki artifacts
Product:	[oVirt] vdsm	Reporter:	Alon Bar-Lev <alonbl>
Component:	RFEs	Assignee:	Alon Bar-Lev <alonbl>
Status:	CLOSED DEFERRED	QA Contact:	yeylon <yeylon>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	4.14.0	CC:	bazulay, bsettle, bugs, danken, dougsland, iheim, lpeer, mkletzan, rbalakri, srevivo, yeylon
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---	Flags:	alonbl: devel_ack?
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	infra
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-09-20 22:11:22 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Infra	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Alon Bar-Lev 2012-12-16 11:22:39 UTC

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 16:48:10 UTC

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 Program Management 2012-12-23 06:47:42 UTC

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 21:00:31 UTC

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 22:23:49 UTC

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.