Skip to content

fix: raise the container memlock limit so QEMU can set up io_uring - #9

Merged
vaggeliskls merged 1 commit into
mainfrom
fix/memlock
Oct 7, 2026
Merged

vaggeliskls merged 1 commit into
mainfrom
fix/memlock

Conversation

@vaggeliskls

Copy link
Copy Markdown
Owner

Current Behaviour

On some hosts the first start ends right after "Booting Windows using QEMU" with

qemu-system-x86_64: Failed to initialize io_uring: Cannot allocate memory
❯ ERROR: QEMU exited unexpectedly!

and restarts in a loop. 2.0.1 and 2.0.2 attributed this to the disk I/O backend (DISK_IO), but QEMU 10.1+ also uses io_uring for its main event loop, so DISK_IO=native did not help. The real limit is the container's locked memory (memlock), a few hundred KB by default, which io_uring's rings exceed.

Expected Behaviour

  • docker-compose.yml sets ulimits.memlock to unlimited for the service, the same setting QEMU and Elasticsearch documentation recommend. It is not a privilege and needs no capability.
  • DISK_IO is removed from the compose file, .env.example and the README; QEMU picks the backend.

Confirmed on the affected host (Ubuntu 20.04, kernel 5.4): with the memlock limit raised QEMU boots and the Windows install proceeds. docker compose config passes.

QEMU 10.1+ uses io_uring for its event loop and, on recent kernels, for
the disk. The rings are locked memory and the container default is a few
hundred KB, so QEMU exited at boot with "Failed to initialize io_uring:
Cannot allocate memory". Unlimited memlock fixes both uses at once.

DISK_IO is removed again: 2.0.1 and 2.0.2 pointed at the disk backend,
which was not the cause.
@vaggeliskls
vaggeliskls merged commit b46f167 into main Oct 7, 2026
1 check passed
@vaggeliskls
vaggeliskls deleted the fix/memlock branch October 7, 2026 12:58
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.

1 participant