Bug 1402507

Summary: [RFE] Support external libvirt for DNS/DHCP proxy providers
Product: Red Hat Satellite Reporter: Peter Tselios <tselios.petros>
Component: CapsuleAssignee: Lukas Zapletal <lzap>
Status: CLOSED UPSTREAM QA Contact: Perry Gagne <pgagne>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.2.4CC: bbuckingham, cwelton, jcallaha, lzap, mhulan, sbream, stbenjam
Target Milestone: UnspecifiedKeywords: FutureFeature
Target Release: Unused   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Release Note
Doc Text:
This feature (External libvirt DNS/DHCP proxy provider) is experimental, untested, and not supported by Red Hat.
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-02-12 19:11:53 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Peter Tselios 2016-12-07 17:22:11 UTC
Description of problem:
I am not absolutely sure if it's a bug, or simply a missing feature. Anyway, here it is:

Satellite 6.2.4 server on my test environment is installed as a KVM virtual machine. I have configured the KVM of the host as a Compute Resource and host provisioning (without any Capsule/Foreman Proxy) works just fine. However, I want to use the DHCP/DNS provided by libvirt itself in order to control the IPs/hostnames of my new boxes. 

I have installed Satellite 6 with the following options:

satellite-installer -S satellite  --foreman-proxy-dhcp-provider virsh --foreman-proxy-dhcp-server kvmbox.testenv --foreman-proxy-dns-server kvmbox.testenv --foreman-proxy-dns-provider virsh --foreman-proxy-dns true --foreman-proxy-dhcp true --foreman-proxy-dhcp-interface eth0

The relevant configuration files are:

---
# Enable DHCP management
# Can be true, false, or http/https to enable just one of the protocols
:enabled: https

# valid providers:
#   - dhcp_isc (ISC dhcp server)
#   - dhcp_native_ms (Microsoft native implementation)
#   - dhcp_virsh (simple implementation for libvirt)
:use_provider: dhcp_virsh
:server: kvmbox.testenv
# subnets restricts the subnets queried to a subset, to reduce the query time.
#:subnets: [192.168.205.0/255.255.255.128, 192.168.205.128/255.255.255.128]

---
# DNS management

:enabled: https
# valid providers:
#   dns_dnscmd (Microsoft Windows native implementation)
#   dns_nsupdate
#   dns_nsupdate_gss (for GSS-TSIG support)
#   dns_virsh (simple implementation for libvirt)
:use_provider: dns_virsh
# use this setting if you want to override default TTL setting (86400)
:dns_ttl: 86400

In the Capsules tab, I see the server correctly configured in the subdomains. 
However, when I try to provision a new host, the DHCP/DNS host is ignored!

The /var/log/foreman-proxy/proxy.log has the following entry:

DHCP virsh provider > error: unable to retrive virsh info: virsh provider error: virsh call > failed (pid 32091 exit 1) - error: failed to connect to the hypervisor error: Failed to connect socket to '/var/run/libvirt/libvirt-sock': No such file or directory

So, from this, I guess that either virsh communication in 6.2.x is limited to a local KVM, or that the server I configured in the installer is ignored. In which case, the installer should, at least, raise a WARNING that this functionality is not implemented. 

Suffice to say, from the foreman-proxy user I can issue virsh commands (like eg sudo virsh qemu://kvmbox.testenv/system list)

Version-Release number of selected component (if applicable):
6.2.4

How reproducible:
100%

Steps to Reproduce:
1. Follow the aforementioned installation

Actual results:
DHCP cannot register the assigned by Satellite IP.

Expected results:
DHCP lease should be recorded in libvirtd. 

Additional info:

Comment 2 Stephen Benjamin 2016-12-09 17:35:15 UTC
The libvirt providers that manage DNS and DHCP are really only intended to be run on the capsule's own local libvirt.  There's no server option. This feature is mostly used by developers and for simple testing.


I can turn this into an RFE for support for external libvirt. But, given the way they work I'm not sure if you could really manage it externally since I think they're editing local files for some things.

Comment 3 Peter Tselios 2016-12-09 17:40:36 UTC
In upstream Foreman, at least in version 1.13 (if I am not mistaken) they have added the following options:

# Libvirt connection. Make sure proxy effective user have permission to connect.
:url: qemu:///system

I don't know the internals though.

Comment 4 Stephen Benjamin 2016-12-09 20:53:33 UTC
Ah, thanks - didn't notice that upstream. That's pretty new.  Those are libvirt providers upstream that are using the native bindings.  It's not in 6.2, which still uses the old virsh backend which is local only.

The new providers should end up in 6.3 when we rebase on a new Foreman release.

Comment 6 Bryan Kearney 2016-12-09 21:20:44 UTC
Upstream bug assigned to lzap

Comment 7 Bryan Kearney 2016-12-09 21:20:47 UTC
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/13761 has been resolved.

Comment 8 Lukas Zapletal 2017-08-09 08:56:38 UTC
QA NOTES: Configure virsh, create host via libvirt, provosion it, delete it.

I believe there are issues with host deletion in virsh provider, it was meant only for development and I do not actively maintain it anymore. If this turns to be problem, I will remove the code and provider as this was never meant to be used by customers. It has many limitations (e.g. reverse DNS is not possible via libvirt API).

Comment 14 Steve Bream 2018-02-12 18:42:47 UTC
I think the correct resolution is to call it out in the release notes - we don't really document unsupported features because if we document it, customers expect that it's supported (even when there's a note saying that it's not).

Ideally I'd make it a tech preview, but it might be too late for that.

Either way, if you set the doctext flag and include the feature and the admonition, we'll get it into the release notes.