Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

machine_virtual: bind multicast to localhost #3717

Merged
merged 1 commit into from
Aug 9, 2022
Merged

machine_virtual: bind multicast to localhost #3717

merged 1 commit into from
Aug 9, 2022

Conversation

allisonkarlitskaya
Copy link
Member

When using socket-based network devices, with the mcast option (but
without an explicitly specified local address), qemu attempts to find a
suitable interface to use by scanning the available "up" interfaces for
ones that have the MULTICAST flag enabled (as per ip link).

The loopback interface doesn't normally have this flag enabled, so if
it's the only one that's up, the search will fail, causing the following
message:

libvirt: QEMU Driver error : internal error: qemu unexpectedly closed the monitor: 2022-08-09T15:52:35.668412Z qemu-system-x86_64: -netdev socket,mcast=230.0.0.1:5600,id=mcast0: can't add socket to multicast group 230.0.0.1: No such device

If we force qemu to use the loopback interface, however, it will
succeed — even without the multicast flag being set. Since we're not
actually interested in communicating between machines, force
127.0.0.1 as the local address.

This allows image-customize, vm-run, and testing in general to work
without the presence of any network connection, and without hacks such
as adding a dummy bridge or veth device.

Fixes cockpit-project/cockpit#12782

When using socket-based network devices, with the `mcast` option (but
without an explicitly specified local address), qemu attempts to find a
suitable interface to use by scanning the available "up" interfaces for
ones that have the MULTICAST flag enabled (as per `ip link`).

The loopback interface doesn't normally have this flag enabled, so if
it's the only one that's up, the search will fail, causing the following
message:

    libvirt: QEMU Driver error : internal error: qemu unexpectedly closed the monitor: 2022-08-09T15:52:35.668412Z qemu-system-x86_64: -netdev socket,mcast=230.0.0.1:5600,id=mcast0: can't add socket to multicast group 230.0.0.1: No such device

If we force qemu to use the loopback interface, however, it will
succeed — even without the multicast flag being set.  Since we're not
actually interested in communicating between machines, force
127.0.0.1 as the local address.

This allows `image-customize`, `vm-run`, and testing in general to work
without the presence of any network connection, and without hacks such
as adding a dummy bridge or veth device.

Fixes cockpit-project/cockpit#12782
@allisonkarlitskaya
Copy link
Member Author

Manually testing on my laptop with no active network interfaces shows that

test/verify/check-system-realms TestKerberos.testNegotiate

runs successfully and passes.

Before this change, it would fail immediately with the "No such device" message.

I can also confirm that posting comments to GitHub doesn't work without an active network interface 🤣

Copy link
Member

@martinpitt martinpitt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very cool!

@martinpitt martinpitt merged commit 146d33c into main Aug 9, 2022
@martinpitt martinpitt deleted the hub branch August 9, 2022 17:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

VMs should run without network and/or default route
2 participants