Univention Bugzilla – Bug 56205
UCR network configuration too inflexible for modern cloud infrastructure with multiple hot-plug interfaces
Last modified: 2023-10-26 12:03:42 CEST
In UCS the network configuration is still stored in UCR: # ucr search --brief --non-empty gateway ^interfaces/ ^nameserver ^dns/forward dns/forwarder1: 192.168.0.124 dns/forwarder2: 192.168.0.97 gateway: 10.200.17.1 interfaces/eth0/address: 10.200.17.20 interfaces/eth0/broadcast: 10.200.17.255 interfaces/eth0/ipv6/acceptRA: false interfaces/eth0/netmask: 24 interfaces/eth0/network: 10.200.17.0 interfaces/eth0/start: true interfaces/eth0/type: static interfaces/primary: eth0 nameserver/external: false nameserver/option/timeout: 2 nameserver1: 10.200.17.20 This is quiet inflexible for modern cloud work loads where multiple interfaces are the norm and may be added and removed on-the-fly. Even with a single interface this is already an issue with our internal and external QCOW2-images as they assume the 1st interface to be named "eth0", while the name depends on the PCI slot number of the interface when the VM is defined. Currently we work-around this issue by setting the Linux kernel command line parameter `net.ifnames=0` to force the old naming schema, but that has issues when multiple interfaces are used. Also this is not set by default but only by some internal scripts used to generate those QCOW2 files. For cloud work loads using DHCP or cloud-init is the norm. But that clashes with UCR as interfaces must be enabled explicitly for DHCP or UCR must be hacked to not undo any static configuration done by cloud-init. (See Bug #47271) In Debian "ifupdown" is deprecated. There's a replacement "ifupdown2", but most other distributions have switched to either "systemd-networkd" for servers or "NetworkManager" for desktop systems: They are much more flexible and support hot-plug interfaces out-of-the-box. This is also fueled by the deprecation of ISC-DHCP (Bug #54393) which requires a change anyway. On a site note: In cloud scenarios DHCP is provided by the cloud provider, which often announces public DNS servers to be used. But UCS requires them to be used only as "forwarders" and requires the UCS Primary/Backups/Replicaes to be used as "nameservers". The logic to handle this discrepancy is currently fragile, see Bug #53679. 1. UCS should better support VMs with multiple interfaces and automatically default to DHCP. 2. Configuring network settings via UCR should be optional. 3. UCS should replace "ifupdown" with a modern alternative.