Unable to launch instances in Multipass

[psuntharanund]

Hi,

I'm new to learning more useful tools to get started on my DevOps career and wanted to get into Multipass as I believe it's a useful tool and will help me learn more about VMs and cloud.

I am currently running Linux Mint 22 on my Thinkpad X1C 6G and was able to successfully install Multipass, however when I try to launch an instance I am constantly getting time out messages and stuck on how to continue forward. I've tried restarting Multipass a few times through:

sudo snap restart multipass

I noticed this message pop up when I looked into the logs (journalctl -fu 'snap.multipass*'):

dnsmasq[10639]: error binding DHCP socket to device mpqemubr0 multipassd[11382]: Unable to determine subnet for the mpqemubr0 subnet

I suspect this may be the issue with why I am unable to launch my VMs but I am not too sure. I will provide logs of what I usually have been seeing when trying to launch the VM:

Oct 02 04:54:22 multipassd[10542]: process state changed to Starting Oct 02 04:54:22 multipassd[10542]: process state changed to Running Oct 02 04:54:22 multipassd[10542]: [10914] started: qemu-system-x86_64 -bios OVMF.fd --enable-kvm -cpu host -nic tap,ifname=tap-324c4d7e6cc,script=no,downscript=no,model=virtio-net-pci,mac=52:54:00:3e:3d:35 -device virtio-scsi-pci,id=scsi0 -drive file=/var/snap/multipass/common/data/multipassd/vault/instances/controlnode/ubuntu-24.04-server-cloudimg-amd64.img,if=none,format=qcow2,discard=unmap,id=hda -device scsi-hd,drive=hda,bus=scsi0.0 -smp 2 -m 2048M -qmp stdio -chardev null,id=char0 -serial chardev:char0 -nographic -cdrom /var/snap/multipass/common/data/multipassd/vault/instances/controlnode/cloud-init-config.iso Oct 02 04:54:22 multipassd[10542]: process started Oct 02 04:54:22 multipassd[10542]: Waiting for SSH to be up Oct 02 04:54:22 multipassd[10542]: QMP: {"QMP": {"version": {"qemu": {"micro": 1, "minor": 2, "major": 8}, "package": ""}, "capabilities": ["oob"]}} Oct 02 04:54:22 multipassd[10542]: QMP: {"return": {}} Oct 02 04:54:25 multipassd[10542]: QMP: {"timestamp": {"seconds": 1727816065, "microseconds": 802488}, "event": "RTC_CHANGE", "data": {"offset": -1, "qom-path": "/machine/unattached/device[5]/rtc"}} Oct 02 04:54:26 multipassd[10542]: QMP: {"timestamp": {"seconds": 1727816065, "microseconds": 914582}, "event": "RTC_CHANGE", "data": {"offset": 0, "qom-path": "/machine/unattached/device[5]/rtc"}} Oct 02 04:54:40 multipassd[10542]: QMP: {"timestamp": {"seconds": 1727816080, "microseconds": 756694}, "event": "NIC_RX_FILTER_CHANGED", "data": {"path": "/machine/unattached/device[23]/virtio-backend"}}

I see this same message every time I try to start the VM and am at my wit's end on how to troubleshoot this issue. If anyone could help provide some direction as to how to resolve this issue that would be greatly appreciated. Thanks!

[ricab]

Hi @psuntharanund, as you highlighted, the problem is indicated by those dnsmasq messages:

dnsmasq[10639]: error binding DHCP socket to device mpqemubr0 multipassd[11382]: Unable to determine subnet for the mpqemubr0 subnet

For some reason, dnsmasq can't bind to the bridge we setup for Multipass. I don't suppose you did anything to that bridge, like removing it or using it for something else? What does ip link say? Do you have AppArmor or something analogous that could be blocking dnsmasq from binding to it?

[psuntharanund]

Hi @ricab I typed in ip link to my terminal and go the following results:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN mode DEFAULT group default qlen 1000 link/ether 8c:16:45:ee:2b:fa brd ff:ff:ff:ff:ff:ff 3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DORMANT group default qlen 1000 link/ether 64:5d:86:56:bc:5b brd ff:ff:ff:ff:ff:ff 4: mpqemubr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000 link/ether 52:54:00:20:02:10 brd ff:ff:ff:ff:ff:ff 5: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default link/ether 02:42:eb:69:00:ac brd ff:ff:ff:ff:ff:ff 12: wg0-mullvad: <POINTOPOINT,UP,LOWER_UP> mtu 1380 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/none

I'm not too sur ewhat to make of it as I haven't come across using this command yet in my studies, but I do see the device name that has been throwing up the errors in the list (#4)

[ricab]

Hi @psuntharanund, I see you have mpqemubr0 in there. The state is DOWN, but that is expected when there are no instances running. If you have no instances that you need to preserve, could you try to uninstall and reinstall multipass and attach the logs from the new install? There are a number of things that multipass needs to do to configure that bridge device that could have failed. And it would be interesting to see also the output of ip addr show mpqemubr0 after you try to launch an instance on a fresh install.

Finally, I see you have Docker and Mullvad installed. VPNs are known to interfere with the networking setup that Multipass needs. Docker configures its own network and there could also be some interference. If you could try disabling/removing those tools and try again, we'd be interested in the results.

[ricab]

For our own reference, this is related to #3700, in that code to setup QEMU networking on Linux uses the outdated utility functions mentioned there and fails to check returns (so we're kind of blind to at least some possible failures).