Lack of default MTU customisation support for QEMU on Linux

[jocado]

Describe the bug Describe what your problem is.

I can't seem to find a nice way to set the MTU of the guest interface when using QEMU.

I can set the MTU of the default multipass host bridge interface ok using netplan, and the guest network config has to be done via custom cloud-init. This is is a little cludgy. Also, it seems I can't hook into the actual netplan config at all using cloud-init [ it always get's overwritten by the default ], so I'm having to use bootcmd and hard coding the expected interface name. It would be nice if you could jsut tell multipass your desireded default mtu, and the host bridge and guest netplan config was created to enforce it automatically.

Current cloud init looks like:

#cloud-config

bootcmd:
  - [ ip, l, set, ens3, mtu, 1420 ]

To Reproduce How, and what happened?

1. Install multipass
2. Use local.driver=qemu
3. default network bridge and all guest interfaces are hard coded to an MTU of 1500

Expected behavior What did you expect to happen? Some kind of multipass set command to specify a custom default MTU.

Logs Please provide logs from the daemon, see accessing logs on where to find them on your platform.

Additional info

• Ubuntu 20.04
• 1.12.2
• local.driver=qemu

Additional context Add any other context about the problem here.

[jocado]

Sorry, I used the bug template, but possibly it will be viewed as a feature request.

[jocado]

Also worth noting, setting the MTU on the default bridge interface also does require then any other instance using the default network has to have the MTU set appropriately, or it can fail to pass any traffic. Therefor the above cludgy workaround does not work well for use cases such as snapcraft, or anything else that doesn't allow you to specify a guest instance cloud-init config.

[luis4a0]

Hi @jocado. What if you edit the file /etc/netplan/50-cloud-init.yaml and add mtu: "1420" in the interface configuration section? It would look like this:

    ethernets:
        ens3:
            dhcp4: true
            match:
                macaddress: 52:54:00:5c:c0:da
            set-name: ens3
            mtu: "1420"
    version: 2

In the comments on the file, it says this won't persist across reboots. But it seems it works. You can check by issuing ip a after reboot and see if the MTU is correctly set in the interface. If this doesn't work, there are other methods. Please let me know if this works for you. Thanks!

[jocado]

Hi @luis4a0

I can confirm, that works, but as it's a manual edit that doesn't really help make the solution any more slick. Moreover, I can't seem to change the netplan config directly via cloud-init - as I noted above in the issue, the netplan config from my cloud-init user-data always get's superseded by some kind of other default config from multipass.

But, whether I can use cloud-init or not, is partly secondary only a secondary issue, because I would still have to configure each instance with the custom MTU [ by cloud-init or some other method ], and separately ensure that the bridge interface for the network also has the correct MTU.

What I would really like is for a smooth UX, where I can just tell multipass the MTU I would like to use by default, and it takes care of all that for the bridge interface and instances. Like I mentioned above, if multipass can't take care of all that, then it's not really practical to use a custom MTU for snapcraft or other similar things that could use multipass as a platform/backend provider.

If I compare it to lxd or docker, I can set it for given or default network, and the host and guest interfaces are taken care of.

LXD

lxc network set lxdbr0 bridge.mtu=1420

Docker

cat /etc/docker/daemon.json 
{
  "mtu":1420
}

Can we do something similar in Multipass using the QEMU driver ?

[luis4a0]

Hi @jocado, not at the moment. However, we might consider this as a future improvement, for we are currently adding some network functionalities. I'll mark this as an enhancement, as this is not definitely a bug. Thanks!

Network interfaces are configured via cloud-init at first boot, but that part of the cloud-init file is written by Multipass. What you mention does not work because you are adding a command in the first boot, which will not be run in subsequent boots. And there is no guarantee it is executed after interfaces were configured.

[luis4a0]

Sorry, didn't mean to close the ticket.

[jocado]

No problem - thanks for taking a look and marking as a potential future feature :+1: