Open icequbes1 opened 3 years ago
Ouch, that sounds like a Xen upstream issue. But lets keep it tracked here anyway, since it ease correctly including the fix (whoever it will develop - likely me...).
Looks like I ran into a GitHub bug: if two users edit the list of labels concurrently, the changes made by one can be overwritten.
Qubes OS version
R4.1
Names and locations of enabled testing repos
Testing repos are enabled in dom0, but the qube in question is not a Qubes-aware OS, so there are no relevant VM repos. Unsure if issue is specific to packages in 'test'.
Names of affected testing repo packages
Unsure, but dom0 networking-related packages
Affected component(s) or functionality
Networking of a VM that is not Qubes-aware
Brief summary
In R4.1, the qube in question is an OS that does not have any qubes packages and runs as an HVM qube with its own kernel.
Switching the NetVM (hotswap) showed that traffic was still being routed to the original NetVM even though the GUI and prefs indicate the switch worked.
How reproducible
Reproducible without an difficulty.
Steps to reproduce
Expected behavior
Traffic from the qube is observed in sys-firewall-2.
Actual behavior
Traffic from the qube is still directed to sys-firewall-1.
Solutions you've tried
Shutting down the qube and restarting it is not an issue and the traffic goes to the expected NetVM.
Additional context
A brief look at
ifconfig
in sys-firewall-1 when traffic was expected to be going to sys-firewall-2 still showed that a vif interface that corresponded to the stubdomain of the qube in question was still connected to sys-firewall-1.In sys-firewall-2, a vif interface corresponding to the qube itself (not the stubdomain) was observed.
It appears two vif interfaces for an HVM qube are created when attached to a NetVM. Only the stubdomain vif interface matters. But changing the NetVM seems to only affect the not-stubdomain vif interface, which doesn't have any effect.
Relevant documentation you've consulted
None
Related, non-duplicate issues
None found