WSL Import-in-Place: Registering an Existing ext4.vhdx Without Repacking It

wsl --import-in-place registers an already-existing, ext4-formatted VHDX file directly as a WSL distribution, rather than extracting a tar archive into a newly created virtual disk the way an ordinary wsl --import does. It’s a genuinely useful shortcut for a specific migration scenario, and a genuinely risky one if you don’t understand exactly what “in place” means for the file you’re pointing it at.

When this is the right tool, versus ordinary import

Ordinary wsl --import takes a tar archive and unpacks its contents into a fresh virtual disk WSL creates for you — portable across storage layouts, but requiring a full extract-and-repack pass. import-in-place skips that entirely: if you already have a compatible ext4.vhdx (from a previous WSL installation, a cloned disk, or a disk image produced by another compatible tool), registering it directly avoids the time and disk-space cost of repacking its entire contents into a new file. This is the more efficient path specifically for VHDX-to-VHDX migration; a tar archive remains the more portable and generally recommended path when you don’t already have a compatible virtual disk file sitting ready to register.

The critical difference: the registered disk becomes live, mutable state

The single most important thing to understand before running this command: once registered, that VHDX file is no longer a static, unchanging artifact — it becomes the actual live storage the running distribution reads from and writes to, exactly as any other WSL distribution’s disk would. Point import-in-place at your only existing copy of important data, and every subsequent write, update, and package installation modifies that same file directly, with no separate original left untouched to fall back on. Always work from a verified, separate copy — never the sole existing instance of a disk you can’t afford to lose.

Checking current command syntax before running it

WSL’s command surface has evolved across versions, and import-in-place’s exact required flags and supported options can differ by installed version. Confirm current syntax against Microsoft’s documentation and your installed version before running it:

wsl --version
wsl --import-in-place <DistributionName> <PathToVhdx>

Choose a distribution name that’s clearly unique and doesn’t collide with an existing registered distribution — a name collision is exactly the kind of mistake that’s easy to make when migrating multiple disks in sequence and easy to regret afterward.

Verifying the registration actually worked before relying on it

wsl -l -v
wsl -d <DistributionName>

Inside the freshly registered distribution, verify the things that actually matter for your use case rather than assuming a clean registration implies everything inside is correct: confirm expected user accounts exist, check /etc/wsl.conf reflects the configuration you expect, confirm networking works, confirm package management functions normally, and — if the original disk had a specific filesystem health state — run a basic filesystem check rather than assuming the disk survived its prior life and this registration process without issue.

The default-user surprise

A distribution imported this way may start as root by default until a proper default user is configured through the distribution’s own supported mechanism (often a .wslconfig-adjacent per-distribution setting, or a distribution-specific configuration tool), rather than automatically inheriting whatever default user the disk had when it was originally created elsewhere. Don’t assume the login experience will match the original system’s without checking first.

Keep the original disk untouched until the migration is proven

Resist the temptation to immediately delete or overwrite wherever the original VHDX came from. Keep it fully offline and untouched until the newly registered distribution has survived a realistic amount of real use — at least one full Windows and WSL update cycle, and ideally a restart of the specific applications or services that matter most for your use case — since a subtle migration problem that only surfaces after a system update or a restart is exactly the kind of failure a same-day verification wouldn’t have caught.

Why tar export/import remains the safer default recommendation

For anyone not already holding a ready-made compatible VHDX, a standard tar export and import remains the more broadly recommended migration path — it’s portable across different storage configurations and doesn’t carry the same “you’re now live-editing your only copy” risk that import-in-place does by its very nature. Reach for import-in-place specifically when you already have the VHDX in hand and the efficiency gain of skipping a full repack genuinely matters for your situation, not as a default first choice for every migration.

Related:

Sources: