Error when binding more than 3 volumes

[jheretic]

Hi, if I try and bind more than 3 volumes, msb fails and I get the following message in the log:

sandbox error: VM enter: build error: start: build_microvm: RegisterNetDevice(IrqsExhausted)

This seems to happen for both the cli and the sdk. I am using Arch Linux on x86_64, and trying to use the ghcr.io/anomalyco/opencode image.

[appcypher]

PR superradcompany/libkrun#46 should fix this.

[jheretic]

Hi, I'm trying out v0.4.0 and experiencing the same issue, except now it's if I mount more than two volumes. Did this fix make it into v0.4.0?

[simontang]

use version 0.4.3, there is a same issue, when add 3 named volumes.

logs:
2026-05-02T00:29:38.263537Z INFO microsandbox_runtime::vm: sandbox starting sandbox=ne536bfdd4225c8f8
2026-05-02T00:29:38.263906Z INFO microsandbox_runtime::relay: agent relay listening on /root/.microsandbox/sandboxes/ne536bfdd4225c8f8/runtime/agent.sock
2026-05-02T00:29:38.291145Z INFO microsandbox_runtime::vm: entering VM sandbox=ne536bfdd4225c8f8
sandbox error: VM enter: build error: start: build_microvm: RegisterNetDevice(IrqsExhausted)

[andrewrembrandt]

I also get this problem with v0.4.0 and later.
It seems that the call to increase IRQ limit fix/increase for x86-64 was removed in #579 (due to it causing a kernel panic).
However, I'm on Linux and rolled back to v0.3.14 and don't seem to experience the mentioned kernel panic.

As a temporary workaround for anyone wanting to mount 3 volumes, you can use:
npx -y microsandbox@v0.3.14 [create|run] -v ... -v ... -v ....

However, when I try it with 4 or more volume mounts, it fails with the same IrqsExhausted error, which makes me wonder if the prebuilt binaries actually are missing the split_irqchip(true) call and there's just one less IRQ being used in the older versions....

[appcypher]

I have reopened this issue. I need to take a better look at the problem.

[wreed4]

smolvm has the same issue. I had an agent debug it a while ago and it appears to be a limitation of libkrun. I don't remember the details, but if you point an agent at that you should be able to reproduce the diagnosis.

EDIT: meh, just had it rerun the analysis. pasted below.

[wreed4]

Empirical findings — msb 0.4.5, libkrun on Linux x86_64

Tested the volume mount limit systematically:

Net	Volumes	Result
✅	1	✅
✅	2	✅
✅	3	❌ RegisterNetDevice(IrqsExhausted)
❌ (--no-net)	2	✅
❌ (--no-net)	3	✅
❌ (--no-net)	4	❌ RegisterBlockDevice(IrqsExhausted)

--tmpfs does not consume an IRQ slot (expected — it's guest-side only).

Analysis

The error comes from libkrun's device registration exhausting available GSI (Global System Interrupt) slots. Each virtio device needs one IRQ:

• virtio-console (serial)
• virtio-vsock (host↔guest comms)
• virtio-blk (root filesystem)
• virtio-net (when networking enabled)
• virtiofs × N (one per -v mount)

The IRQ budget appears to be 5 usable slots after whatever base platform reservations exist. With networking that leaves 2 for virtiofs; without networking, 3.

The device that fails depends on registration order — virtiofs mounts are registered first, then net, then blk. Whichever comes last gets the IrqsExhausted error.

Impact

This is a hard blocker for use cases that need multiple bind mounts (e.g., workspace + skill directories + config). Current workaround is to tar | exec files into the guest after boot, losing live sync with the host.

Possible fix direction

libkrun could use MSI/MSI-X for virtio devices instead of legacy IRQ pins, which would remove the slot limit entirely. Alternatively, increasing the GSI table size in the interrupt controller setup would raise the cap.