RL10 KVM install

Rocky Linux Help & Support
1

Hello,

I want to install KVM on an RL10 host to run an Alpine Linux guest VM. I have successfully created a similar installation on a CentOS 7 host. It worked out of the box using the KVM ‘default’ NAT network. However, this is not working on RL10. The first thing I ran into was dnsmasq competing with Bind9 to listen on 192.168.122.1:53:

$ virsh net-start default
error: Failed to start network default
error: internal error: Child process (VIR_BRIDGE_NAME=virbr0 /usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro --dhcp-script=/usr/libexec/libvirt_l
easeshelper) unexpected exit status 2:
dnsmasq: failed to create listening socket for 192.168.122.1: Address already in use

This was fixed by getting Bind9 to exclude the NAT network:

listen-on port 53 { !192.168.122.0/24; any; };

The guest installation was initiated on the host this way:

virt-install
–virt-type kvm
–name ddfilter
–memory 256
–vcpus 1
–cdrom /var/lib/libvirt/boot/alpine-standard-3.22.2-x86_64.iso
–network network=default
–disk /var/lib/libvirt/images/ddfilter.raw,format=raw,size=0.75
–os-variant alpinelinux3.22
–graphics none

The installing process was unable to get an IP from the ‘default’ network:

Which one do you want to initialize? (or ‘?’ or ‘done’) [eth0]
Ip address for eth0? (or ‘dhcp’, ‘none’, ‘?’) [dhcp]
Do you want to do any manual network configuration? (y/n) [n]
udhcpc: started, v1.37.0
udhcpc: broadcasting discover
udhcpc: broadcasting discover
udhcpc: broadcasting discover
udhcpc: broadcasting discover
udhcpc: broadcasting discover
udhcpc failed to get a DHCP lease
udhcpc: no lease, forking to background

The install failed because there wouldn’t be a working network for the guest. The interface in the guest was:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 52:54:00:52:09:37 brd ff:ff:ff:ff:ff:ff
inet6 fe80::5054:ff:fe52:937/64 scope link
valid_lft forever preferred_lft forever

The ‘default’ network interface (address 192.168.122.1) could be pinged on the host, and it appeared active and normal:

$ virsh net-list --all
Name State Autostart Persistent
default active yes yes

Can anyone please advise how this can be fixed?

2

On Rocky 9.x there’s a different “default network”, depending on whether you are running virsh commands as ‘root’ or as standard user, also show

nmcli device status

on the host.

3

I use the root account for everything.

On the RL10:

$ nmcli device status
DEVICE TYPE STATE CONNECTION
ens3 ethernet connected Ethernet connection 1
lo loopback connected (externally) lo
virbr0 bridge connected (externally) virbr0
vnet0 tun connected (externally) vnet0

For comparison, on the working CentOS 7:

DEVICE TYPE STATE CONNECTION
eth0 ethernet connected System eth0
virbr0 bridge connected virbr0
vnet1 tun connected vnet1
lo loopback unmanaged –
virbr0-nic tun unmanaged –

4

Another difference is the way the default network is handled. This could account for the reason why it isn’t working on RL10.

RL10

Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 192.168.122.1:53 0.0.0.0:* LISTEN 10549/dnsmasq
udp 0 0 192.168.122.1:53 0.0.0.0:* 10549/dnsmasq

CentOS 7

tcp 0 0 192.168.122.1:53 0.0.0.0:* LISTEN 1009/named
udp 0 0 192.168.122.1:53 0.0.0.0:* 103367/dnsmasq

5

Turned out Libvirt couldn’t work out what firewall I had and didn’t create the necessary rules. The following did the trick. The config file did not exist on CentOS7.

vi /etc/libvirt/network.conf
firewall_backend = “iptables”

Then start/restart libvirt.

6

That’s because the default backend is nftables:

# firewall_backend:
#
#   determines which subsystem to use to setup firewall packet
#   filtering rules for virtual networks.
#
#   Supported settings:
#
#     iptables - use iptables commands to construct the firewall
#     nftables - use nft commands to construct the firewall
#
#   If firewall_backend isn't configured, libvirt will choose the
#   first available backend from the following list:
#
#     [nftables, iptables]
#
#   If no backend is available on the host, then the network driver
#   will fail to start, and an error will be logged.
#
#   (NB: switching from one backend to another while there are active
#   virtual networks *is* supported. The change will take place the
#   next time that libvirtd/virtnetworkd is restarted - all existing
#   virtual networks will have their old firewalls removed, and then
#   reloaded using the new backend.)
#
#firewall_backend = "nftables"

therefore something with your configuration was most likely wrong in the first place. I don’t have hardware currently to run a Rocky 10 KVM host, but I expect that it would work fine with nftables.

IPTables has been deprecated in FirewallD since RHEL9/Rocky 9, and whilst KVM was defaulting to iptables in RHEL9/Rocky 9, it has now since changed. Whilst changing it back to iptables solves your problem for now, it may disappear entirely in for example RHEL11 and then you’ll need to figure out a new solution on what to use with libvirt/kvm.

Please also do not compare Rocky 8, 9 or 10 with CentOS 7. All are fundamentally different. Also, you never copy config files from an older server to a newer one. Therefore if you are using config files from CentOS 7 on any of your new servers then that would explain all the problems you have. You should manually configure your system with the changes you require, or use something like ansible to automate the configuration.

Either way, Rocky 10 should work with KVM and nftables, so we still don’t know what you did on your server in that it doesn’t work. Most likely you tried changing config files to match your CentOS 7 installation which is wrong. But we can only speculate.

7

Not sure what you are trying to show here, but there is no difference here in CentOS and Rocky - both have dnsmasq listening on port 53 on address 192.168.122.1 is normal. Obviously if you run additional services on your server like Bind, then you expect port conflicts. This would also happen if you were to additionally install Unbound as well, since that’s yet another app/service for DNS. Usually you don’t put all services on a single server to conflict with each other, and you would give each server a purpose. A web server being a web server, a DNS server being a DNS server. Obviously in a home lab people will run everything on a single machine but then you have to make sure there are no conflicts. In this case, you would configure Bind so that it doesn’t attempt to listen on any 192.168.122.x address since that was the cause of your problem.

Also, you don’t need to use the 192.168.122.x NAT addresses that is the default configuration. Sure it’s fine if you just want your VM to have the ability to download packages from the internet, but it won’t be routable for your home network to access these VM’s unless it knows where to find these servers. If you want normal network connectivity, that is when you change from the default NAT network and create a bridged network to use your LAN IP addresses. In such a situation there is inbound and outbound access to the machines from any computer on your LAN network. But this entirely depends on what you are trying to achieve, and how you wish to use it.

8

Nothing wrong with my installation. I like iptables because RL10 allows me to have it. When RL10 stops me having it, perhaps I will switch to something else or keep running the old stuff. No distro is going to lock me down and I am not scared of security threats and back doors, because of monitoring and other mitigating techniques. It is a failure of RL10 to not work out-of-the-box with a feature, namely iptables, that is currently supported.

NAT serves my purpose of an internet appliance fine. It is easy because it is the default. Also I don’t have to buy IP addresses for VM appliances. The largely unidirectional nature of it adds protection.