Hide Forgot
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:
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.
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.
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.
Upstream bug assigned to lzap
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/13761 has been resolved.
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).
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.