[Bug 1214469] Networking Issue After Transactional Update
https://bugzilla.suse.com/show_bug.cgi?id=1214469
https://bugzilla.suse.com/show_bug.cgi?id=1214469#c5
--- Comment #5 from Santiago Zarate
Created attachment 868938 [details] pre-update
Summary: After performing a transactional update on an openSUSE Tumbleweed system, the networking bridges and virtual interfaces were not functioning. As a result, the affected device, which serves as a VM-host for an opnsense firewall, lost its network connectivity. Rolling back to an older snapshot and disabling the transactional-update.timer service was required to restore networking functionality. The issue had significant impact as all devices on the network lost internet connectivity. Manual intervention in the form of a keyboard and monitor connection was needed to perform the rollback.
Description: On [Date], I performed a transactional update on my openSUSE Tumbleweed system. The system was being used as a VM-host for an opnsense firewall, which plays a critical role in managing network traffic for my network. The transactional update was carried out using the standard update procedure.
After the update was applied and the system rebooted, it was immediately apparent that there were issues with the networking configuration. None of the networking bridges or virtual interfaces were functioning as expected. This resulted in a complete loss of network connectivity for all the virtual machines running on the host, as well as the host itself.
Due to the severity of the issue and the impact it had on the network, I decided to manually intervene by connecting a keyboard and monitor to the affected system. After accessing the system locally, I attempted to diagnose the problem. It became evident that the issue was related to the recent transactional update, as rolling back to an older snapshot of the system resulted in the restoration of networking functionality. This process involved using the system's snapshot manager to revert to a state prior to the update.
Additionally, to prevent this issue from occurring again in the future, I disabled the transactional-update.timer service. While this action helped avoid further disruption, it's important to note that transactional updates are a critical part of openSUSE Tumbleweed's update process and should ideally work without causing networking issues.
Impact: The impact of this issue was significant. Due to the loss of networking bridges and virtual interfaces, all the devices on the network, including the virtual machines hosted on the affected system, lost internet connectivity. This disruption lasted until I could manually intervene, rollback to an older snapshot, and disable the transactional update timer. The incident led to downtime, network interruptions, and required manual intervention, which is not ideal for a system that's intended to provide stable and uninterrupted network services.
Steps to Reproduce:
- Install openSUSE Tumbleweed on a system configured as a VM-host. - Set up networking bridges and virtual interfaces. - Perform a transactional update using the standard update procedure. - Reboot the system after the update. - Observe that networking bridges and virtual interfaces are not functioning as expected, resulting in a loss of network connectivity for all devices.
Expected Results: After a transactional update, the system's networking configuration, including bridges and virtual interfaces, should remain intact, and the network connectivity for all devices should not be affected.
Additional Information: - Intel Pentium N6005, 4x Intel i226-V 2.5Gb LAN - Output of relevant commands`ip addr show` see attached
Can you describe the network configuration? I have a personal host that's also a VM host, and is also a VPN (WG) gateway and haven't had issues, despite it having two VMs having bridged networks flowchart TD A[Internet] --> system[host network adapter] system --> bridge{libvirtd-bridged network} bridge --> VM1 bridge --> VM2 bridge --> VM3 (See routed network on hetzner: https://docs.hetzner.com/robot/dedicated-server/ip/additional-ip-adresses/) -- You are receiving this mail because: You are the assignee for the bug.
participants (1)
-
bugzilla_noreply@suse.com