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.

Sign up for GitHub

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

Jump to bottom

VMs should run without network and/or default route #12782

Closed
allisonkarlitskaya opened this issue Sep 12, 2019 · 2 comments · Fixed by cockpit-project/bots#3717
Closed

VMs should run without network and/or default route #12782

allisonkarlitskaya opened this issue Sep 12, 2019 · 2 comments · Fixed by cockpit-project/bots#3717
Labels
enhancement

Comments

@allisonkarlitskaya
Copy link
Member

Trying to run verify tests or any of the related stuff will fail if there is no interface with a default route. We should see if we can fix that.
@martinpitt
Copy link
Member

This annoyed me several times while I was working in the train. But I gave up after half an hour, I didn't find a way to make the QEMU socket networking deal with just the loopback address. As a local hack I used a veth device -- it doesn't need to actually work, it just needs to have some non-localhost address.

@martinpitt
Copy link
Member

No progress, but this is still valid (and annoying)

@martinpitt martinpitt changed the title The bots should run without network and/or default route VMs should run without network and/or default route Mar 3, 2021
allisonkarlitskaya added a commit to cockpit-project/bots that referenced this issue Aug 9, 2022
@allisonkarlitskaya
machine_virtual: bind multicast to localhost
4fb49b2 
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 allisonkarlitskaya mentioned this issue Aug 9, 2022
Merged
martinpitt pushed a commit to cockpit-project/bots that referenced this issue Aug 9, 2022
@allisonkarlitskaya @martinpitt
machine_virtual: bind multicast to localhost
146d33c 
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

machine_virtual: bind multicast to localhost cockpit-project/bots
3 participants
@martinpitt @KKoukiou @allisonkarlitskaya