Skip to content

fix: use annotation for MirageOS net device name#690

Open
pocopepe wants to merge 2 commits into
urunc-dev:mainfrom
pocopepe:fix/315-mirage-net-annotation
Open

fix: use annotation for MirageOS net device name#690
pocopepe wants to merge 2 commits into
urunc-dev:mainfrom
pocopepe:fix/315-mirage-net-annotation

Conversation

@pocopepe
Copy link
Copy Markdown

Description

mirageos unikernels declare their network device names at build time through the solo5 manifest. the problem was urunc always hardcoded "service" as the device name, so if you built a unikernel with a different name it would just fail.
i added a new annotation com.urunc.unikernel.netDev so image builders can set the name at build time and urunc picks it up at runtime. if the annotation isn't there it falls back to "service" so existing images still work.

block device naming and multi network support i left for follow up prs as discussed.

Related issues

How was this tested?

go test ./pkg/unikontainers/unikernels/... -v -run TestMirageNetDevName

=== RUN   TestMirageNetDevName
=== RUN   TestMirageNetDevName/uses_net_device_name_from_annotation
=== PAUSE TestMirageNetDevName/uses_net_device_name_from_annotation
=== RUN   TestMirageNetDevName/falls_back_to_service_when_annotation_is_absent
=== PAUSE TestMirageNetDevName/falls_back_to_service_when_annotation_is_absent
=== CONT  TestMirageNetDevName/uses_net_device_name_from_annotation
=== CONT  TestMirageNetDevName/falls_back_to_service_when_annotation_is_absent
--- PASS: TestMirageNetDevName (0.00s)
    --- PASS: TestMirageNetDevName/uses_net_device_name_from_annotation (0.00s)
    --- PASS: TestMirageNetDevName/falls_back_to_service_when_annotation_is_absent (0.00s)
PASS
ok      github.com/urunc-dev/urunc/pkg/unikontainers/unikernels (cached)

LLM usage

Claude Sonnet 4.6

Checklist

  • I have read the contribution guide.
  • The linter passes locally (make lint).
  • The e2e tests of at least one tool pass locally (make test_ctr, make test_nerdctl, make test_docker, make test_crictl).
  • If LLMs were used: I have read the llm policy.

@netlify
Copy link
Copy Markdown

netlify Bot commented May 16, 2026

Deploy Preview for urunc canceled.

Name Link
🔨 Latest commit 8d4d5c8
🔍 Latest deploy log https://app.netlify.com/projects/urunc/deploys/6a0db990c2373a0008a825fa

@cmainas
Copy link
Copy Markdown
Contributor

cmainas commented May 18, 2026

Hello @pocopepe ,

this is not enough testing for such PR. You need to build a mirage unikernel with multiple network interfaces and then spawn it with urunc again with multiple network interfaces.

@pocopepe
Copy link
Copy Markdown
Author

My bad, I just tested it with a mirage unikernel built to declare a non default net device name being eth0 being neteth0:fix and another with no annotation specified neteth0:bug.

With the annotation:

$ sudo nerdctl run --rm --runtime io.containerd.urunc.v2 neteth0:fix
WARN[0000] cannot set cgroup manager to "systemd" for runtime "io.containerd.urunc.v2"
            |      ___|
  __|  _ \  |  _ \ __ \
\__ \ (   | | (   |  ) |
____/\___/ _|\___/____/
Solo5: Bindings version v0.10.1
Solo5: Memory map: 268 MB addressable:
...
Usage: neteth0 [--help] [OPTION]…
neteth0: unknown option '--ipv4' unknown option '--ipv4-gateway'
Solo5: solo5_exit(64) called

solo5 accepts --net:eth0=... and boots

Without the annotation:

$ sudo nerdctl run --rm --runtime io.containerd.urunc.v2 neteth0:bug
WARN[0000] cannot set cgroup manager to "systemd" for runtime "io.containerd.urunc.v2"
solo5-hvt: Resource not declared in manifest: 'service'
solo5-hvt: Resource not declared in manifest: 'service'
solo5-hvt: Invalid option: `--net:service=tap0_urunc'

urunc defaults to the old hardcoded service and solo5 rejects since the manifest only declares eth0. That's exactly the bug this PR fixes.
Also the pr only focuses on task 1 as mentioned in the description. If this works for you, I'm happy to extend it for block scope and multi interface handling

@cmainas
Copy link
Copy Markdown
Contributor

cmainas commented May 18, 2026

Thank you @pocopepe for the test. Would it be possible to share the image you built? Also, a small note: If the PR does not entirely fix an issue, you can mention the issue as related, but do not use "Fixes".

@pocopepe
Copy link
Copy Markdown
Author

@cmainas sorry, I assumed Fixes was part of the default template, new to the repo conventions. happy to amend the commit and update the pr description to use Related instead, want me to do that now?

Pushed images:

Comment on lines 103 to 106
if data.Net.Mask != "" {
m.Net.Address = "--ipv4=" + data.Net.IP + "/24"
m.Net.Gateway = "--ipv4-gateway=" + data.Net.Gateway
}
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In Mirage you can "group" parameters to network devices. What this effectively means is that you can add a prefix to the command line options (often the interface name). An example is for an interface management you'd often add a group management and this would produce command line options --management-ipv4, --management-ipv4-gateway etc. Now, since a recent release of Mirage interfaces will by default use DHCP to acquire this information if it was not presented at boot time (or statically configured) instead of using a silly default of 10.0.0.2/24 and 10.0.0.1 as ipv4 and ipv4-gateway respectively.

So to configure extra interfaces there's no good way to do it, but I think a decent heuristic is for each interface that is not called "service" to use data.NetDevName as the group.

Finally, you can construct unikernels in whatever way you want so you are never guaranteed that the unikernel accepts these options.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah makes sense, pushed it as a new commit

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Support multiple block and network devices over Solo5/MirageOS

3 participants