Summary
Independent of the parser issues tracked in #818 and #819, there is a usability gap: regardless of the memory value ultimately passed to the VMM, failures caused by insufficient memory are surfaced as opaque VM exits rather than actionable runtime errors.
Observed behavior
Hypervisor-level failure (~2MB)
At approximately 2MB, the guest fails before booting and QEMU reports a generic KVM error:
KVM internal error. Suberror: 1
emulation failure
EAX=2badb002 EBX=00009500 ECX=00287606 EDX=00000511 ...
Nothing in the error indicates that the underlying cause is insufficient guest memory.
Guest panic (approximately 4MB–75MB)
Between roughly 4MB and 75MB, the VM boots far enough for the guest allocator to fail during initialization:
Cannot handle palloc request of order 6: Out of memory
main returned 11, halting system
The guest halts and exits the VM.
urunc / containerd-shim-urunc-v2 correctly handles the VM exit and reports a container exit code instead of crashing itself. However, the reported exit code alone provides no indication that the failure was caused by an insufficient memory limit.
Impact
A user who accidentally configures a memory limit below the minimum required by a unikernel image (e.g. below the measured Redis/Unikraft boot floor described in #819) receives only a generic container failure. Diagnosing the actual cause requires inspecting the guest serial console, making it easy to mistake the problem for an application or runtime bug.
Suggested improvements
Related issues
Note: Addressing #818 and #819 would reduce the likelihood of these failures, but this usability issue could still occur for other resource constraints (e.g., CPU or disk), making it independently worth addressing.
Environment
- urunc commit:
2785749875a1b13f543b6ad4137c68903a9ec87e
- QEMU:
8.2.2 (1:8.2.2+ds-0ubuntu1.17)
- Test image:
harbor.nbfc.io/nubificus/urunc/redis-qemu-unikraft-initrd:latest
Summary
Independent of the parser issues tracked in #818 and #819, there is a usability gap: regardless of the memory value ultimately passed to the VMM, failures caused by insufficient memory are surfaced as opaque VM exits rather than actionable runtime errors.
Observed behavior
Hypervisor-level failure (~2MB)
At approximately 2MB, the guest fails before booting and QEMU reports a generic KVM error:
Nothing in the error indicates that the underlying cause is insufficient guest memory.
Guest panic (approximately 4MB–75MB)
Between roughly 4MB and 75MB, the VM boots far enough for the guest allocator to fail during initialization:
The guest halts and exits the VM.
urunc/containerd-shim-urunc-v2correctly handles the VM exit and reports a container exit code instead of crashing itself. However, the reported exit code alone provides no indication that the failure was caused by an insufficient memory limit.Impact
A user who accidentally configures a memory limit below the minimum required by a unikernel image (e.g. below the measured Redis/Unikraft boot floor described in #819) receives only a generic container failure. Diagnosing the actual cause requires inspecting the guest serial console, making it easy to mistake the problem for an application or runtime bug.
Suggested improvements
Out of memoryorKVM internal error) and surface a more descriptive container exit reason instead of only a generic non-zero exit code.Related issues
Note: Addressing #818 and #819 would reduce the likelihood of these failures, but this usability issue could still occur for other resource constraints (e.g., CPU or disk), making it independently worth addressing.
Environment
2785749875a1b13f543b6ad4137c68903a9ec87e8.2.2(1:8.2.2+ds-0ubuntu1.17)harbor.nbfc.io/nubificus/urunc/redis-qemu-unikraft-initrd:latest