[66Ton99]

What changed

• Adds physicalDisks profile configuration for macOS physical partitions.
• Supports physicalDisks[].backend values auto, nbd, and vz; auto stays conservative and resolves to nbd.
• Implements the NBD backend using host qemu-nbd, an SSH tunnel, guest /dev/nbdN, and Linux filesystem mounting.
• Implements guarded native VZ block attachment for vmType: vz by emitting Lima blockDevices and mounting the stable guest path /dev/disk/by-id/virtio-<device>.
• Adds optional host access through guest NFSv4 mounted back on macOS, including for the VZ backend.
• Preserves YAML-only config across colima start flag merges.
• Documents configuration, warnings, troubleshooting, sudo boundaries, native VZ requirements (Lima v2.3.0-beta.1+), E2E testing, and the durability rationale for storing source trees on a physical partition outside the VM disk.
• Adds scripts/physical_disk_vz_e2e.sh for repeatable native VZ smoke coverage with a temporary ext4 disk image surrogate and the root-owned lima-privileged-block-device helper.

Notes

backend: vz requires vmType: vz, macOS 14 or newer, and Lima v2.3.0-beta.1 or newer (which exposes --block-device in limactl create --help and per-device --block-device strings in limactl sudoers --help backed by libexec/lima/privileged/lima-privileged-block-device). If those requirements or host partition readiness checks are not met, Colima rejects the config before limactl start instead of falling back silently.

Host-side sudo is limited to root-only macOS operations. With backend: nbd, that means opening the raw partition with qemu-nbd, mounting/unmounting the NFS export, and cleaning up root-owned qemu-nbd. With backend: vz, Lima handles the privileged disk open through its root-owned lima-privileged-block-device helper during VM startup, and Colima still uses host sudo only for the optional macOS NFS mount/unmount. Guest filesystem setup uses sudo inside the VM.

Validation

• go test ./...
• go build -o /tmp/colima-vz-physical ./cmd/colima
• bash -n scripts/physical_disk_vz_e2e.sh
• git diff --check
• Verified against Lima v2.3.0-beta.1 (lima-vm/lima#5117):
  • Confirmed blockDevices YAML schema and /dev/disk/by-id/virtio-<device> guest identifier compatibility.
  • Verified pre-start CLI rejection with Lima 2.2.0 (requires Lima 2.3.0 or newer with secure macOS VZ block-device support) and pre-start partition readiness check with official Lima 2.3.0-beta.1 binary before limactl start.
• Local NBD smoke with a temporary ext4 disk image attached as /dev/disk4s1//dev/rdisk4s1, mounted in the VM as /dev/nbd0, exported through NFSv4, and verified read/write in both directions.
• Native VZ smoke with secure --block-device support:
  • VM started with the VZ driver.
  • Guest mounted the ext4 partition through the native block path: /mnt/colima/physical/smoke /dev/vdb ext4 rw,relatime.
  • Stable guest ID resolved as expected: /dev/disk/by-id/virtio-disk4s1 ... TYPE="ext4".
  • Guest-to-host and host-to-guest read/write passed through the NFS host-access path.
  • Cleanup audit is clean: no matching hdiutil attachment, no /Volumes/Colima/physical-vz-e2e* mount, no /private/etc/sudoers.d/colima-vz-e2e, no /opt/colima-vz-e2e, no physical-vz-e2e Lima instance, and no stale colima-physical-vz-e2e-*/ssh.sock mux process.

[66Ton99]

Native VZ backend progress update:

• Added explicit physicalDisks[].backend: vz support guarded by vmType: vz, macOS 14+, and Lima capability checks for secure block-device support (limactl create --help and limactl sudoers --help must expose --block-device).
• Colima now emits Lima blockDevices for VZ physical disks and mounts the deterministic guest path /dev/disk/by-id/virtio-<device> after boot.
• NBD remains the default for backend: auto; NBD cleanup and host NFS access are kept separate from the VZ flow.
• Docs and default config now describe NBD vs VZ, sudo requirements, host access via NFS, and the physical-partition rationale.

Validation run locally:

• go test ./...
• go build -o /tmp/colima-vz-physical ./cmd/colima
• git diff --check
• Built Lima PR Secure macOS VZ block-device attachment lima-vm/lima#5117 locally from secure-vz-block-devices; the resulting limactl version 31cfe0f exposes both required secure block-device flags.

Native VZ live E2E status:

• Current installed Lima 2.1.1 does not expose --block-device, so Colima correctly cannot run backend: vz against the installed Lima.
• A real native VZ attach smoke still needs a sudo session to install the custom limactl in a root-owned non-writable path and add a temporary sudoers fragment for sudo-open-block-device. No sudo credential cache was available in the current session, so the live attach/write/NFS roundtrip has not been completed yet.

[66Ton99]

Final VZ validation update:

Native VZ physical disk smoke passed with:

• Colima binary: /tmp/colima-vz-physical
• Lima build: /tmp/lima-5117/_output/bin/limactl rebuilt as v2.2.0, with secure --block-device support available in limactl create --help and limactl sudoers --help
• Script: scripts/physical_disk_vz_e2e.sh

Observed evidence from the smoke run:

• VM started with the VZ driver.
• Guest mounted the ext4 partition through the native block path: /mnt/colima/physical/smoke /dev/vdb ext4 rw,relatime.
• Stable guest ID resolved as expected: /dev/disk/by-id/virtio-disk4s1 ... TYPE="ext4".
• Guest-to-host write/read passed through the macOS NFS mount.
• Host-to-guest write/read passed after creating a writable smoke subdirectory from the guest.

Final local gates after the VZ+NFS state-dir fix:

• go test ./...
• go build -o /tmp/colima-vz-physical ./cmd/colima
• bash -n scripts/physical_disk_vz_e2e.sh
• git diff --check

Cleanup audit is clean after the smoke run: no matching hdiutil attachment, no /Volumes/Colima/physical-vz-e2e* mount, no /private/etc/sudoers.d/colima-vz-e2e, no /opt/colima-vz-e2e, no physical-vz-e2e Lima instance, and no stale colima-physical-vz-e2e-*/ssh.sock mux process.

[reneleonhardt]

Amazing work, thank you! What is needed before review and merging?

[pirate]

Note lots of security fixes were needed to improve my original PR with lima, make sure you pull those in as well from lima-vm/lima#5117! Nvm it looks like you already have that PR mentioned above, nice work!