Description of problem: Something prevents the ebtable_nat module from being autoloaded. A rules on the ebtables nat chain fails to apply: Oct 18 14:50:39 mac5254002a783e journal: internal error: Failed to apply firewall rules /usr/sbin/ebtables --concurrent -t nat -N libvirt-J-vnet0: The kernel doesn't support the ebtables 'nat' table. Iptables got stopped: Oct 18 14:50:39 mac5254002a783e kernel: ip_tables: (C) 2000-2006 Netfilter Core Team Oct 18 14:50:39 mac5254002a783e iptables.init: iptables: Unloading modules: [ OK ] Oct 18 14:50:39 mac5254002a783e systemd: Stopped IPv4 firewall with iptables. And so the management bridge and so the RHHEV engine VM: Oct 18 14:50:39 mac5254002a783e kernel: ovirtmgmt: port 2(vnet0) entered disabled state Oct 18 14:50:39 mac5254002a783e kernel: device vnet0 left promiscuous mode Oct 18 14:50:39 mac5254002a783e kernel: ovirtmgmt: port 2(vnet0) entered disabled state Oct 18 14:50:39 mac5254002a783e systemd: Starting IPv4 firewall with iptables... Oct 18 14:50:39 mac5254002a783e kvm: 0 guests now active Oct 18 14:50:39 mac5254002a783e kernel: nf_conntrack version 0.5.0 (65536 buckets, 262144 max) Oct 18 14:50:39 mac5254002a783e systemd-machined: Machine qemu-1-HostedEngine terminated. Version-Release number of selected component (if applicable): How reproducible: It seams specific just to hosts deployed from satellite and it seams pretty reproducible. Steps to Reproduce: 1. 2. 3. Actual results: The RHEV engine VM got terminated and so the hosted-engine setup got stuck. Expected results: It will be possible to deploy hosted-engine. Additional info: It affects QCI.
We saw it also on an host which hasn't been deployed from the satellite template. Closing this one and opening a new one on libvirt for the interaction with ebtables.