Current limitations
Rootfs format restrictions
The WSL2 driver imports guests via:
which only accepts filesystem archives (.tar/.tar.gz).
As a result, templates referencing standard .qcow2 or .raw cloud images cannot be used with the WSL2 backend.
Currently it is unclear whether this limitation should be:
- explicitly validated and documented, or
- abstracted by adding conversion/import helpers.
Configuration fields ignored by the backend
validateConfig() currently warns and ignores several standard Lima configuration fields, including:
This makes WSL2 behave differently from other drivers and limits template portability.
Proposed direction
Phase 1: Improve validation and documentation
- Explicitly validate supported image formats for
vmType: wsl2.
- Provide clear error messages when unsupported image types (
qcow2, raw, etc.) are used.
- Document how users can build or provide WSL-compatible rootfs archives.
Phase 2: Support standard Lima mount semantics
Investigate mapping Lima mounts: entries onto WSL's existing host filesystem integration.
Possible approaches:
- translate Windows host paths into their
/mnt/<drive>/... equivalents;
- create symlinks or bind mounts inside the guest to honor
mountPoint;
- generate appropriate
/etc/wsl.conf entries during initialization.
Phase 3: Reduce backend-specific special casing
Where feasible, allow WSL2 instances to consume a broader set of Lima templates without requiring a dedicated experimental template.
Open questions
- Should WSL2 reject unsupported image formats at validation time?
- What level of
mounts: compatibility is desirable for WSL2?
- Is full template portability across drivers a goal for the backend?
I'd be interested in working on this if the direction aligns with the maintainers' vision for WSL2.
Current limitations
Rootfs format restrictions
The WSL2 driver imports guests via:
which only accepts filesystem archives (
.tar/.tar.gz).As a result, templates referencing standard
.qcow2or.rawcloud images cannot be used with the WSL2 backend.Currently it is unclear whether this limitation should be:
Configuration fields ignored by the backend
validateConfig()currently warns and ignores several standard Lima configuration fields, including:mountsnetworksThis makes WSL2 behave differently from other drivers and limits template portability.
Proposed direction
Phase 1: Improve validation and documentation
vmType: wsl2.qcow2,raw, etc.) are used.Phase 2: Support standard Lima mount semantics
Investigate mapping Lima
mounts:entries onto WSL's existing host filesystem integration.Possible approaches:
/mnt/<drive>/...equivalents;mountPoint;/etc/wsl.confentries during initialization.Phase 3: Reduce backend-specific special casing
Where feasible, allow WSL2 instances to consume a broader set of Lima templates without requiring a dedicated experimental template.
Open questions
mounts:compatibility is desirable for WSL2?I'd be interested in working on this if the direction aligns with the maintainers' vision for WSL2.