net: support multiple network interfaces by slp · Pull Request #367 · containers/libkrun

slp · 2025-07-01T14:15:57Z

So far, we were assuming the microVM will have a single network interface. But we have at least one new usecase (namely, running Android), that requires having multiple interfaces.

Refactor the API to support adding mulitple interfaces, while we keep compatibility with the old API.

While there, also allow the user to set up the network device flags.

nirs

So much nicer with generic names!

nirs · 2025-07-03T14:36:12Z

+    };
+
+    if fd >= 0 && path.is_some() {
+        return -libc::EINVAL;


EINVAL without an error message is hard to work with. We have 4 different EINVAL errors for this function. How the user can tell what is the issue?

Can we have libkrun_error() to get the last error message? Probably not in the scope of this change, and I did not check the rest of the code.

Can we have libkrun_error() to get the last error message? Probably not in the scope of this change, and I did not check the rest of the code.

Yeah, so our error reporting is not great and unfortunately we don't have anything like libkrun_error(), nor do we define our own error codes which would help here. Currently the only way to see what went wrong for example with krun_start_enter is to check the log (which has to be enabled). Not great I know, but that is really something we need to change in v2 API more globally (otherwise it would get really confusing how errors work).

nirs · 2025-07-05T17:16:52Z

+#define NET_FLAG_VFKIT 1 << 0
+
+/* Taken from uapi/linux/virtio_net.h */
+#define NET_VFLAG_CSUM 1 << 0


If we go with 2 flag arguments let's make the constants and the flags names more clear using "features" and "flags".

#define NET_FEATURE_CSUM 1<<0 ... * "features" - virtio-net features for the network interface. * "flags" - generic flags for the network interface.

Switching the order because the virtio features are more important and flags are usually the last argument.

Sounds reasonable to me, I've just changed it.

So far, we were assuming the microVM will have a single network interface. But we have at least one new usecase (namely, running Android), that requires having multiple interfaces. Refactor the API to support adding mulitple interfaces, while we keep compatibility with the old API. While there, also allow the user to set up the network device flags. Signed-off-by: Sergio Lopez <slp@redhat.com>

Update examples to use the new network config API and avoid use of deprecated functions. Signed-off-by: Sergio Lopez <slp@redhat.com>

slp · 2025-07-08T09:04:21Z

@mtjhrc could you please take another look?

mtjhrc · 2025-07-08T16:21:24Z

 #define MAX_PATH 4096
 #endif

+#define COMPAT_NET_FLAGS NET_CSUM | NET_GUEST_CSUM | NET_GUEST_TSO4 | NET_GUEST_UFO | NET_HOST_TSO4 | NET_HOST_UFO


You forgot to update this to the new constant names

mtjhrc · 2025-07-08T16:21:46Z

-      perror("Error configuring net mode");
-      return -1;
+    uint8_t mac[] = {0x5a, 0x94, 0xef, 0xe4, 0x0c, 0xee};
+    if (err = krun_add_net_passt(ctx_id, passt_fd, &mac[0], COMPAT_NET_FLAGS)) {


You forgot to update this to the new function name and signature

mtjhrc

Please fix the boot_efi example to not refer to non-existant functions/constants.
Otherwise everything looks good.

slp · 2025-07-09T11:18:21Z

Please fix the boot_efi example to not refer to non-existant functions/constants. Otherwise everything looks good.

Good catch, thanks. I've fixed that and also moved COMPAT_NET_FEATURES to libkrun.h, which seems like a better place for it.

With new libkrun if we set the mac address after setting gvproxy path, the network device is created using a default mac address: let mac = cfg.mac.unwrap_or([0x5a, 0x94, 0xef, 0xe4, 0x0c, 0xee]); create_virtio_net( cfg, VirtioNetBackend::UnixgramPath(path, true), mac, NET_COMPAT_FEATURES, ); This breaks programs like vment-helper tests and minikube, assuming that the device will use the mac address set by the tool. This also breaks krunkit networking when using vment-helper with offloading. I'm not sure why this happens. With this change we can build with libkrun main and run a vm with vment-helper example script or minikube krunkit driver. I think this should be fixed in libkrun. This seems to be a regression introduced by containers/libkrun#367. But the fix in krunki is easy and safe.

With new libkrun if we set the mac address after setting gvproxy path, the network device is created using a default mac address: let mac = cfg.mac.unwrap_or([0x5a, 0x94, 0xef, 0xe4, 0x0c, 0xee]); create_virtio_net( cfg, VirtioNetBackend::UnixgramPath(path, true), mac, NET_COMPAT_FEATURES, ); This breaks programs like vment-helper tests and minikube, assuming that the device will use the mac address set by the tool. This also breaks krunkit networking when using vment-helper with offloading. I'm not sure why this happens. With this change we can build with libkrun main and run a vm with vment-helper example script or minikube krunkit driver. I think this should be fixed in libkrun. This seems to be a regression introduced by containers/libkrun#367. But the fix in krunki is easy and safe. Signed-off-by: Nir Soffer <nirsof@gmail.com>

slp requested review from MatiasVara, jakecorrenti, mtjhrc and tylerfanelli as code owners July 1, 2025 14:15

slp mentioned this pull request Jul 1, 2025

virtio-net enables features without checking if the peer supports them #264

Closed

nirs reviewed Jul 1, 2025

View reviewed changes

Comment thread include/libkrun.h Outdated

Comment thread include/libkrun.h Outdated

Comment thread include/libkrun.h Outdated

Comment thread include/libkrun.h Outdated

Comment thread src/devices/src/virtio/net/device.rs Outdated

Comment thread src/libkrun/src/lib.rs Outdated

mtjhrc reviewed Jul 1, 2025

View reviewed changes

Comment thread include/libkrun.h Outdated

slp force-pushed the multiple-network branch 3 times, most recently from 613db39 to ae78de2 Compare July 2, 2025 11:17

cfergeau mentioned this pull request Jul 2, 2025

vfkit: Try again to use MSG_PEEK instead of relying on a magic "VFKT" packet containers/gvisor-tap-vsock#520

Closed

slp force-pushed the multiple-network branch from ae78de2 to f106bd2 Compare July 2, 2025 15:11

mtjhrc reviewed Jul 2, 2025

View reviewed changes

Comment thread include/libkrun.h Outdated

Comment thread include/libkrun.h Outdated

slp force-pushed the multiple-network branch 2 times, most recently from 99a268f to 992fda3 Compare July 3, 2025 13:47

nirs reviewed Jul 3, 2025

View reviewed changes

slp force-pushed the multiple-network branch from 992fda3 to 08d3eed Compare July 4, 2025 07:57

nirs reviewed Jul 5, 2025

View reviewed changes

nirs mentioned this pull request Jul 5, 2025

Support libkrun (mostly for Virtio-GPU Venus), maybe via krunkit lima-vm/lima#2277

Closed

slp force-pushed the multiple-network branch 2 times, most recently from d5a1281 to 9bd1af1 Compare July 7, 2025 12:29

nirs approved these changes Jul 7, 2025

View reviewed changes

slp added 2 commits July 8, 2025 04:37

examples: make use of the new network config API

184f58c

Update examples to use the new network config API and avoid use of deprecated functions. Signed-off-by: Sergio Lopez <slp@redhat.com>

mtjhrc reviewed Jul 8, 2025

View reviewed changes

mtjhrc requested changes Jul 8, 2025

View reviewed changes

slp force-pushed the multiple-network branch from 9bd1af1 to 184f58c Compare July 9, 2025 11:16

mtjhrc approved these changes Jul 9, 2025

View reviewed changes

slp merged commit 0ce4b28 into containers:main Jul 9, 2025
6 checks passed

nirs mentioned this pull request Aug 15, 2025

Release supporting multiple network interfaces (krun_add_net_unixgram, krun_add_net_unixstream) #391

Closed

This was referenced Aug 15, 2025

Set mac address before gvproxy path containers/krunkit#66

Closed

krun_set_gvproxy_path broken #392

Closed

nirs mentioned this pull request Aug 30, 2025

krun_add_net_unixgram broken when using fd #403

Closed

Conversation

slp commented Jul 1, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

nirs left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

nirs Jul 3, 2025

Choose a reason for hiding this comment

Uh oh!

mtjhrc Jul 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

nirs Jul 5, 2025

Choose a reason for hiding this comment

Uh oh!

slp Jul 7, 2025

Choose a reason for hiding this comment

Uh oh!

slp commented Jul 8, 2025

Uh oh!

mtjhrc Jul 8, 2025

Choose a reason for hiding this comment

Uh oh!

mtjhrc Jul 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mtjhrc left a comment

Choose a reason for hiding this comment

Uh oh!

slp commented Jul 9, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

mtjhrc Jul 3, 2025 •

edited

Loading

mtjhrc Jul 8, 2025 •

edited

Loading