krun: implement support for passt networking by slp · Pull Request #1913 · containers/crun

slp · 2025-11-18T18:26:37Z

Introduce a new configuration flag (krun.use_passt) that enables users to request the microVM to use passt based networking instead of TSI.

Right now, the container needs to configure the network by itself, but the next version of libkrun will embed a DHCP client in init.c

sourcery-ai · 2025-11-18T18:26:43Z

Reviewer's Guide

The PR integrates passt-based networking by launching a passt daemon with a UNIX socketpair, attaching a virtio-net interface to the microVM via krun_add_net_unixstream, and extending FD cleanup to preserve passt sockets.

File-Level Changes

Change	Details	Files
Automatically start passt daemon and manage its socketpair	define PASST_FD_PARENT and PASST_FD_CHILD constants add passt_fds array to krun_config implement libkrun_start_passt to socketpair, fork+exec passt, and sync startup invoke libkrun_start_passt in configure_container phase	`src/libcrun/handlers/krun.c`
Attach virtio-net interface via krun_add_net_unixstream	include <sys/socket.h> add krun_add_net_unixstream function pointer and dlsym lookup call krun_add_net_unixstream with parent FD, MAC, features, and flags	`src/libcrun/handlers/krun.c`
Preserve passt FDs during FD cleanup with new close_fds hook	add close_fds callback to custom_handler vtable implement libkrun_close_fds to skip passt socketpair FDs when closing modify container_init to call custom close_fds if available	`src/libcrun/handlers/krun.c` `src/libcrun/container.c` `src/libcrun/custom-handler.h`

Tips and commands

Interacting with Sourcery

Trigger a new review: Comment @sourcery-ai review on the pull request.
Continue discussions: Reply directly to Sourcery's review comments.
Generate a GitHub issue from a review comment: Ask Sourcery to create an
issue from a review comment by replying to it. You can also reply to a
review comment with @sourcery-ai issue to create an issue from it.
Generate a pull request title: Write @sourcery-ai anywhere in the pull
request title to generate a title at any time. You can also comment
@sourcery-ai title on the pull request to (re-)generate the title at any time.
Generate a pull request summary: Write @sourcery-ai summary anywhere in
the pull request body to generate a PR summary at any time exactly where you
want it. You can also comment @sourcery-ai summary on the pull request to
(re-)generate the summary at any time.
Generate reviewer's guide: Comment @sourcery-ai guide on the pull
request to (re-)generate the reviewer's guide at any time.
Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
pull request to resolve all Sourcery comments. Useful if you've already
addressed all the comments and don't want to see them anymore.
Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
request to dismiss all existing Sourcery reviews. Especially useful if you
want to start fresh with a new review - don't forget to comment
@sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

Enable or disable review features such as the Sourcery-generated pull request
summary, the reviewer's guide, and others.
Change the review language.
Add, remove or edit custom review instructions.
Adjust other review settings.

Getting Help

Contact our support team for questions or feedback.
Visit our documentation for detailed guides and information.
Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

slp · 2025-11-18T18:27:43Z

cc/ @sbrivio-rh for awareness

packit-as-a-service · 2025-11-18T18:28:02Z

Ephemeral COPR build failed. @containers/packit-build please check.

sbrivio-rh · 2025-11-18T18:40:51Z

src/libcrun/handlers/krun.c

+  else
+    {
+      /* We need to make sure passt has already started before continuing. A
+         simple way to do it is with a blocking read on its stdout. */


Actually, you can skip this whole dance by not passing -f: passt behaves like usual UNIX daemons and forks into background when it's ready, and if you give -1 / --one-off, it terminates by itself once the guest disconnects.

Conversely, getting something from its stdout doesn't guarantee that it's ready. Which is the only (minor) issue I spotted here, by the way, so if you need to stick to this approach for whatever reason it looks fine to me as well.

Indeed, this looks much better, thanks for the suggestion!

svenstaro · 2025-11-25T11:02:38Z

I think this would be amazing to have in crun! I did apply and run your patch and I can confirm that passt is started along with my container. Inside my container, however, networking doesn't appear to be configured:

2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 5a:94:ef:e4:0c:ee brd ff:ff:ff:ff:ff:ff

and I can't reach the network at all.

I'm launching my container like this:

podman run --net pasta --runtime krun -it --rm archlinux /bin/bash

Do I need some extra stuff?

sbrivio-rh · 2025-11-25T11:35:10Z

I think this would be amazing to have in crun! I did apply and run your patch and I can confirm that passt is started along with my container. Inside my container, however, networking doesn't appear to be configured

With Podman and pasta(1), you get networking automatically configured because Podman passes --config-net.

But there's no such thing in passt(1) as it can't magically enter your VM and do stuff there, so you need to use DHCP or SLAAC/NDP to configure the network in this case (ip link set dev eth0 up should give you IPv6 connectivity, and dhcpcd or dhclient after that should give you IPv4).

Maybe an approach similar to AsahiLinux/muvm#111 (tiny DHCP client embedded in muvm) would make sense here as well.

svenstaro · 2025-11-25T13:05:01Z

Ah right, that makes a lot of sense. Sadly, it doesn't work:

dhclient -v
...
Listening on LPF/eth0/5a:94:ef:e4:0c:ee
Sending on   LPF/eth0/5a:94:ef:e4:0c:ee
Sending on   Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 10
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 15
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 21
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3
No DHCPOFFERS received.
No working leases in persistent database - sleeping.

EDIT:
Ah, huh. On VM/container restart, it now works. Weird. It also keeps working now. No idea what kind of fluke that was!

sbrivio-rh · 2025-11-25T13:53:16Z

Ah, huh. On VM/container restart, it now works. Weird. It also keeps working now. No idea what kind of fluke that was!

It might be that you forgot to bring the interface up first? dhclient won't do it for you.

slp · 2025-11-26T17:17:42Z

Maybe an approach similar to AsahiLinux/muvm#111 (tiny DHCP client embedded in muvm) would make sense here as well.

That's exactly what I was planning to do, basically by translating your Rust implementation into C for init/init.c.

sbrivio-rh · 2025-11-26T20:06:33Z

That's exactly what I was planning to do, basically by translating your Rust implementation into C for init/init.c.

By the way, if you're looking for some quick-and-dirty netlink implementation, without using the full libnl, with pretty much just the parts you need to do that, you can probably draw some inspiration from https://passt.top/passt/tree/netlink.c or https://archives.passt.top/passt-dev/20231206160808.3d312733@elisabeth/.

It's GPL code though, so you can't use it directly in libkrun's init (init/init.c is missing licensing information by the way). But I hope it helps anyway as documentation / how-to. Or maybe it's just more convenient to go with libnl, after all...

eriksjolund · 2026-02-07T07:50:36Z

src/libcrun/container.c

         stop some syscalls used by mark_or_close_fds_ge_than.
      */
-      ret = mark_or_close_fds_ge_than (entrypoint_args->container, entrypoint_args->context->preserve_fds + 3, true, err);
+      if (entrypoint_args->custom_handler->vtable->close_fds)


When the if statement condition evaluates to true, then no error is created.
I think using crun_error_release (err); (in line 1656) requires that we know for sure err is equal to
NULL or pointing to an allocated error. It's not clear at first sight whether that requirement is fulfilled.

One idea is to replace line 897

return mark_or_close_fds_ge_than (first_fd_to_close, true, NULL);

with

return mark_or_close_fds_ge_than (first_fd_to_close, true, err);

and add err as a function argument to libkrun_close_fds()

Good point, fixed now.

Some handlers may need to preserve more fds than those related to stdio. Let's allow them to provide their own hook for doing that. Signed-off-by: Sergio Lopez <slp@redhat.com>

sbrivio-rh · 2026-03-10T18:52:02Z

Unlikely you missed this, but in case you did: containers/libkrun#527 (review) :) libkrun should very soon support passt's vhost-user interface as well. Not fundamental but I guess at some point krun should switch to it.

sbrivio-rh · 2026-03-10T18:54:19Z

src/libcrun/handlers/krun.c

 #define LIBKRUN_DEFAULT_RAM_MIB 1024

+/* The minimum amount of RAM for a viable microVM is 128 MB. */
+#define LIBKRUN_MINIMUM_RAM_MIB 128


Actually I managed to boot muvm guests with 64 MiB: containers/libkrunfw#85 (comment) ...it was saving a couple of milliseconds compared to 256 MiB if I recall correctly. With 32 MiB the kernel would panic pretty early (decompressing initramfs? I don't quite remember). I guess it's not a relevant difference to 128 MiB anyway.

64 MiB boots, but it's pretty much unusable. Realistically speaking, even 128 MiB falls short, but I reckon there's a chance (albeit slim) someone manages to use it knowing what they are actually doing ;-)

slp · 2026-03-10T18:58:43Z

Unlikely you missed this, but in case you did: containers/libkrun#527 (review) :) libkrun should very soon support passt's vhost-user interface as well. Not fundamental but I guess at some point krun should switch to it.

Yes, the thing is we still don't know if vhost-user is 1.x or 2.x material. So it's safer to stay with regular pipe for the moment. Also, confidential computing use cases would likely still require the good ol' pipe.

tylerfanelli · 2026-03-13T00:30:23Z

Running with AWS nitro, I'm met with the following:

docker:
    Error response from daemon:
    failed to create task for container: 
    failed to create shim task:
    OCI runtime create failed:
    failed configuring mounts for handler at phase:
    HANDLER_CONFIGURE_AFTER_MOUNTS:
    start passt:
    File exists: unknown.

eriksjolund · 2026-03-13T06:17:28Z

src/libcrun/handlers/krun.c

+      if (errno == ENOENT)
+        return 0;


crun_error_release (err);

is needed when returning 0

Fixed, thanks!

Some decisions, such as whether we need to start passt or not, need to happen before we switch to the container's mount namespace. With this change we move processing the VM configuration to the HANDLER_CONFIGURE_BEFORE_USERNS phase, so we can have the information early enough. Signed-off-by: Sergio Lopez <slp@redhat.com>

Since the introduction of libkrun_configure_vm, the legacy path was only walked on very exceptional situations. Let's consolidate both configuration mechanisms in libkrun_configure_vm. While there, make GPU a configurable option, instead of relying in heuristics. Signed-off-by: Sergio Lopez <slp@redhat.com>

The minimum viable amount for RAM for a microVM is 128MB, ignore configurations asking for less than that. Signed-off-by: Sergio Lopez <slp@redhat.com>

Introduce a new configuration flag (krun.use_passt) that enables users to request the microVM to use passt based networking instead of TSI. Right now, the container needs to configure the network by itself, but the next version of libkrun will embed a DHCP client in init.c Signed-off-by: Sergio Lopez <slp@redhat.com>

slp · 2026-03-13T11:24:25Z

docker:
Error response from daemon:
failed to create task for container:
failed to create shim task:
OCI runtime create failed:
failed configuring mounts for handler at phase:
HANDLER_CONFIGURE_AFTER_MOUNTS:
start passt:
File exists: unknown.

I'm not sure what's leading to EEXIST, could you please trace it with strace?

sbrivio-rh reviewed Nov 18, 2025

View reviewed changes

eriksjolund reviewed Feb 7, 2026

View reviewed changes

slp force-pushed the krun-passt-net branch from b77f299 to fabde21 Compare February 9, 2026 16:30

slp force-pushed the krun-passt-net branch from fabde21 to 9089428 Compare February 19, 2026 12:51

handlers: add new hook to close fds

52de768

Some handlers may need to preserve more fds than those related to stdio. Let's allow them to provide their own hook for doing that. Signed-off-by: Sergio Lopez <slp@redhat.com>

slp force-pushed the krun-passt-net branch 2 times, most recently from a1d7603 to 94c06c3 Compare March 10, 2026 18:46

slp changed the title ~~krun: switch to passt-based networking~~ krun: implement support for passt networking Mar 10, 2026

slp marked this pull request as ready for review March 10, 2026 18:49

sbrivio-rh reviewed Mar 10, 2026

View reviewed changes

slp force-pushed the krun-passt-net branch from 94c06c3 to 9ad121b Compare March 11, 2026 09:16

eriksjolund reviewed Mar 13, 2026

View reviewed changes

slp added 4 commits March 13, 2026 12:23

krun: ignore RAM configurations below 128MB

675d096

The minimum viable amount for RAM for a microVM is 128MB, ignore configurations asking for less than that. Signed-off-by: Sergio Lopez <slp@redhat.com>

slp force-pushed the krun-passt-net branch from 9ad121b to 51d3b56 Compare March 13, 2026 11:23

Conversation

slp commented Nov 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

sourcery-ai bot commented Nov 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Reviewer's Guide

File-Level Changes

Interacting with Sourcery

Customizing Your Experience

Getting Help

Uh oh!

slp commented Nov 18, 2025

Uh oh!

packit-as-a-service bot commented Nov 18, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

svenstaro commented Nov 25, 2025

Uh oh!

sbrivio-rh commented Nov 25, 2025

Uh oh!

svenstaro commented Nov 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

sbrivio-rh commented Nov 25, 2025

Uh oh!

slp commented Nov 26, 2025

Uh oh!

sbrivio-rh commented Nov 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sbrivio-rh commented Mar 10, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

slp commented Mar 10, 2026

Uh oh!

tylerfanelli commented Mar 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

slp commented Mar 13, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

slp commented Nov 18, 2025 •

edited

Loading

sourcery-ai bot commented Nov 18, 2025 •

edited

Loading

svenstaro commented Nov 25, 2025 •

edited

Loading

sbrivio-rh commented Nov 26, 2025 •

edited

Loading

tylerfanelli commented Mar 13, 2026 •

edited

Loading