“WSL 迁移”这件事我是被C盘给逼上梁山的。某天Windows右下角弹出低磁盘空间警告一查%LOCALAPPDATA%\Packages\CanonicalGroupLimited.Ubuntu...\LocalState\ext4.vhdx这个文件占了37GB。WSL用起来是真的爽搬起来也是真的痛。后来我把迁移流程完整跑了不下五遍从同机换盘到跨机搬家从普通数据备份到CUDA环境重建该踩的坑一个没落下。这篇就把整个迁移过程、原理、命令和注意事项一次性讲清楚适合那些C盘告急、准备换电脑、或者想把WSL环境搬到别的盘的人参考。1. 迁移需求盘点排在C盘爆满之前的几个理由1.1 你以为你在用Linux其实你养了一只“巨型文件”很多人装上WSL2之后只记得自己在用Linux忘了Windows这边其实多了一个虚拟磁盘文件。WSL2的根文件系统不是文件夹而是一个ext4虚拟磁盘文件vhdx默认躺在C盘的系统目录里。这个文件最大的特点是只涨不缩。你在WSL里删除再多的文件释放的是虚拟磁盘里的空间Windows看到的vhdx文件大小并不会自动降下来。日子一长C盘就被这只“吞金兽”慢慢吃光。想查看它到底多大两种办法文件资源管理器直接定位到上面的路径看文件大小。PowerShell里用命令统计Get-ChildItem -Path $env:LOCALAPPDATA\Packages\*Ubuntu*\LocalState -Recurse | Measure-Object -Property Length -Sum看到那个几十GB的数字迁移的念头就压不住了。1.2 除了空间这些情况同样属于“迁移”换电脑新机器要复现一套编译环境、conda虚拟环境和各种工具链不想一个个重装。发行版升级或替换Ubuntu 20.04用腻了想换22.04但/home下的数据、配置文件不想丢弃。Windows重装重装系统后原来C盘的WSL发行版需要恢复。公司安全策略要求把开发环境统一挪到D盘或E盘。注意热词里频繁出现“python虚拟环境迁移”、“pytorch环境搭建wsl”、“cuda迁移”说明大部分人的真实诉求不只是搬文件而是搬一套能直接跑AI训练的开发环境。迁移的真正交付物不只有磁盘数据还有“到了新环境能立刻跑通”的能力。2. 动手前先摸底你是WSL1还是WSL2家当又在哪里2.1 先分清WSL1和WSL2迁移思路完全不同打开PowerShell或CMD执行wsl -l -v输出里会列出每个发行版的名称、状态和VERSION列。VERSION是1说明是WSL1是2说明是WSL2。WSL1没有虚拟磁盘只是一个系统调用翻译层文件存在Windows文件系统的普通目录里迁移时把对应文件夹拷走就行没那么多弯弯绕绕。但绝大多数人的环境已经是WSL2一个轻量虚拟机涉及vhdx文件的整体搬迁。顺带解释一下热词里“git bash和wsl 2两者区别”git bash是模拟Linux命令行的工具没有内核不能跑Linux二进制程序WSL2是真正的Linux内核跑在轻量虚拟机里能执行完整Linux应用。两者的可迁移性也完全不在一个量级。2.2 盘点发行版里的“家当”别漏了隐身文件迁移前先进入发行版看看大头数据都在哪里du -sh /home/* /opt/* /usr/local/* /etc 2/dev/null | sort -rh | head -20常见的“重量级选手”/home/用户名项目代码、.ssh密钥、.bashrc、.gitconfig、.config等。/opt手动解压安装的软件比如某些IDE、编译器。/usr/local手动编译安装的程序。conda/envs目录如果装了Miniconda环境默认在~/miniconda3/envs动辄几十GB。尤其是.ssh、.gitconfig、.bashrc这类“隐身文件”很多人迁移完才发现忘了SSH的免密登录全部失效。建议先列一个清单按“必须带走、可重建、无所谓”分成三类再开始下一步。2.3 备份是兜底不是走过场迁移前至少做一次完整备份。先关闭所有WSL实例wsl --shutdown然后导出成tar包wsl --export Ubuntu D:\temp\ubuntu-backup.tar导出时间取决于实际数据量。如果vhdx显示37GBtar包可能只有二十几GB因为tar只包含实际文件数据会跳过已删除的块和未使用的空间。这个tar包就是整个迁移的“保险单”后面任何一步出错都可以从它恢复。如果想顺手压缩vhdx备份之后在diskpart里执行select vdisk file你的ext4.vhdx路径 compact vdisk这是“事后瘦身”迁移前做不做不影响大局但能帮C盘挤出一点空间。3. 同机跨盘迁移wsl --export / --import 全流程3.1 导出把整个发行版打包成单个交付物在PowerShell中执行wsl --shutdown wsl --export Ubuntu D:\temp\ubuntu-move.tar导出期间WSL所有实例都会被关闭确认没有正在运行的训练任务或数据库服务。导出完成后这个tar包是自包含的包含了Linux文件系统里的所有内容包括用户、软件、配置、数据。3.2 导入指定目标盘和新的发行版名假设要把环境搬到D:\WSL\Ubuntu-D执行wsl --import Ubuntu-D D:\WSL\Ubuntu-D D:\temp\ubuntu-move.tar --version 2三个关键参数第一个是新的发行版名可以跟原名不同第二个是vhdx存放目录必须是目标盘路径第三个是tar包路径。--version 2明确指定使用WSL2。导入完成后你会踩到第一个经典坑默认用户变成了root。原因很好理解Windows侧对发行版注册的默认用户信息并没有被tar包携带导入机制只会给一个默认的root入口。解法是在WSL内创建/etc/wsl.conf[user] default你的用户名然后回到Windows执行wsl --shutdown再次进入发行版whoami就会变成原用户。注意这个用户名必须真实存在于发行版的/etc/passwd中导入的tar包保留了原来的passwd文件所以原来的用户一般都在。如果是商店安装的Ubuntu还有个备选方案执行Ubuntu.exe config --default-user 用户名。但用tar导入的发行版没有对应的exe启动器wsl.conf是更通用、跨发行版都适用的方案。3.3 清理旧发行版确认新环境没问题前别急着删导入并验证新发行版能正常进入后才轮到删除旧发行版。删除命令wsl --unregister Ubuntu这条命令会把旧发行版的所有数据连同vhdx一起删除不可恢复。所以顺序一定不能反先导入新环境测试关键命令、服务和数据再删旧的。如果不想换名字可以先把旧的unregister再用原名导入到新盘但最好不要这么做万一中途命令写错旧环境就没了。给它一个临时别名跑稳了再清理心理压力小很多。3.4 迁移后的常规验证清单wsl -l -v确认新发行版存在且版本正确。wsl -d Ubuntu-D能够正常进入。whoami pwd ls /home/用户名默认用户是否正确家目录数据是否完整。Windows侧访问路径\\wsl.localhost\Ubuntu-D\home\用户名能否正常打开。VSCode Remote-WSL如果新版发行版名字变了VSCode需要手动选择想让它成为默认执行wsl --set-default Ubuntu-D如果原来跑了SSH、cron、redis等服务需要检查是否正常启动。注意WSL每次启动IP可能变化绑定固定IP的服务配置大概率要重调。热词里还有“系统迁移后一直转圈 mounteddevices”这种情况通常出现在Windows整体迁移或克隆后和WSL迁移不是同一场景但思路一致先看挂载状态再检查注册和驱动。WSL迁移本身不涉及物理磁盘挂载单纯用export/import不会遇到这种问题。4. 跨机器迁移把WSL发行版当“系统镜像”随身带4.1 目标机器怎么接住这份tar包跨机器迁移和同机跨盘的命令几乎一样差别在于目标机器也要有WSL2运行时。先确认目标机器满足条件Windows 10 1903及以上或Windows 11。已经启用“适用于Linux的Windows子系统”和“虚拟机平台”功能。内核更新到最新wsl --update。目标机器不需要预先安装Ubuntu或Debian直接导入tar包即可。用U盘拷贝tar包到目标机器或通过内网传输然后执行wsl --import Ubuntu-D D:\WSL\Ubuntu-D D:\temp\ubuntu-move.tar --version 2导入后同样要配置/etc/wsl.conf设置默认用户。4.2 用脚本和清单实现“半自动搬家”export/import搬的是文件系统还不够“全自动”。更稳妥的做法是让“环境清单”跟着tar包一起走这样即使在导入后发现某个包损坏也能快速重建。我常用的组合是# 在旧机器WSL内生成环境清单 pip freeze requirements.txt conda env export --from-history environment.yml然后把tar包、requirements.txt、environment.yml都放到同一个目录整体拷贝到新机器。导入后再进入WSL执行环境重建。这样即使tar包出问题还有环境清单和pip/conda缓存可以快速恢复。深度依赖Git管理的项目直接git clone后重建虚拟环境比从tar包捞代码更靠谱。把代码和数据分离迁移时心理负担小得多。4.3 跨机器导入后容易忽略的几件事.wslconfig如果旧机器在C:\Users\你\.wslconfig配置过内存、CPU核数限制新机器要手动复制或重写。Windows防火墙原来WSL里暴露过端口比如8080新机器可能被防火墙拦需要重新加放行规则。SSH密钥虽然tar包里有~/.ssh但导入后文件权限可能会变SSH可能报“Permissions too open”。在WSL内执行chmod 700 ~/.ssh chmod 600 ~/.ssh/*。Windows用户名不同不需要改WSL内的用户名因为tar包携带了Linux侧的用户体系目标机器的Windows用户叫啥都无所谓。5. 环境重建才是真坎Python虚拟环境、CUDA与PyTorch的接续5.1 虚拟环境迁移别指望直接拷贝venv目录这是热词里“python虚拟环境迁移”最核心的认知。Python的venv目录不是自包含的里面bin/python写的是创建时的解释器绝对路径pyvenv.cfg也记录了base前缀。直接把venv文件夹拷到新机器activate能执行但实际调用的Python解释器是错的会出现各种诡异的ModuleNotFoundError。正确流程是旧环境导出依赖清单。新机器创建全新的venv。安装依赖。# 旧环境 pip freeze requirements.txt # 新环境 python3 -m venv venv source venv/bin/activate pip install -r requirements.txtConda环境相对好一些用conda env export --from-history environment.yml只导出明确安装的包避免把平台相关的依赖全部锁死。重建时conda env create -f environment.yml--from-history这个参数很关键它只记录你手动装过的包不记录依赖树里的传递性依赖跨平台重建时冲突更少。如果用了uv管理依赖直接保留pyproject.toml或uv.lock新环境执行uv sync就能精确还原。5.2 WSL里装CUDA和PyTorch先理解“驱动在Windows运行时在WSL”热词里有“wsl安装cuda”、“pytorch环境搭建wsl”、“7900xtx pytorch wsl”都说明AI环境是迁移重灾区。先建立一个正确的认知模型Windows安装NVIDIA显卡驱动驱动版本需要足够新。WSL2内不需要重复安装Linux版驱动WSL会通过/usr/lib/wsl/lib/nvidia-smi调用Windows驱动。PyTorch等框架自带CUDA运行时不一定需要安装完整CUDA Toolkit只有源码编译、需要nvcc时才安装cuda-toolkit。迁移后验证GPU是否可见nvidia-smi如果能看到显卡和驱动版本说明GPU直通正常。接着装PyTorchpip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121cu121对应CUDA 12.1具体按你的PyTorch版本选择。安装完跑一下最小验证python -c import torch; print(torch.__version__, torch.cuda.is_available(), torch.cuda.get_device_name(0))输出True和显卡名环境就算活了。AMD显卡方面热词里的7900XTX在WSL2下需要走ROCm兼容性比NVIDIA折腾得多。WSL的ROCm支持这几年有进步但论稳定N卡仍是首选如果坚持A卡建议用ROCm官方的Docker镜像把环境隔离在容器里尽量少动WSL宿主系统。5.3 迁移之后先跑通一个最小用例再清旧环境不要导入完看着能进终端就以为万事大吉。我每次迁移完都会做一个“最小冒烟测试”建一个临时虚拟环境跑一次数据预处理脚本再跑一个几十step的训练循环。确认torch.cuda.is_available()为True、数据加载正常、模型能前向传播才算真的迁移成功。旧环境保留多久我的经验是至少保留一周。等到新环境跑过真实任务不是demo再wsl --unregister旧发行版也不迟。迁移失败的代价远高于多占几天磁盘空间。6. 安装太慢怎么办离线安装与顽固错误码的排查链路6.1 wsl --install为什么能卡到天荒地老“wsl install太慢了怎么解决”、“wsl --install 网速慢被重置”是热词里出现频率很高的问题。原因是wsl --install这条命令一次性要完成好几件事启用Windows功能、下载WSL内核更新包、从商店下载发行版任何一个环节网络不顺畅整体就会卡住甚至重置。我的建议是拆步骤来先手动在“启用或关闭Windows功能”里勾选“适用于Linux的Windows子系统”和“虚拟机平台”。重启后执行wsl --update更新内核。发行版不通过--install安装直接用离线tar导入。坏掉的安装状态不用硬修把残留的发行版wsl --unregister掉再重新导入新发行版即可。反复重试--install不是解决思路拆解步骤后哪步有问题清晰可见。6.2 离线安装的三条路不需要联网也完全可以把WSL装起来尤其是新机器第一次装的时候离线方案反而更可控。第一条微软商店离线包在商店找到Ubuntu的详情页用浏览器抓取离线安装包.appx或.msixbundle下载后管理员PowerShell执行Add-AppxPackage -Path 下载的安装包路径第二条从GitHub Releases下载发行版rootfs tar包然后用wsl --import导入。这种方法最灵活导入的发行版和商店版的差异只在于没有exe启动器但日常使用和VSCode Remote-WSL完全不受影响。wsl --import Ubuntu-E D:\WSL\Ubuntu-E D:\downloads\ubuntu.tar --version 2第三条利用手里的旧机器从旧机器wsl --export出tar包拷到新机器导入。这一条和迁移流程完全重合也是我最喜欢的方式与其在新机器上从零安装加配置不如把旧环境的“成品”直接搬过去。6.3 顽固错误码的排查链路热词里有一串典型的错误码逐个说排查思路。wsl/installdistro/service/registerdistro/createvm/hcs/error_file_n这一串错误的核心是HCSHost Compute Service创建虚拟机失败。排查链路确认Windows版本支持WSL2Windows 10 1903。检查“虚拟机平台”功能是否真的开启。进BIOS确认虚拟化VT-x/AMD-V开启。检查是否有其他虚拟化软件如老版本VirtualBox、Hyper-V冲突等。wsl needs updating your version of windows subsystem for linux (wsl) is too old内核或WSL运行时组件太旧。执行wsl --update。如果这条命令本身报“无法与服务器建立连接”就从官方发布渠道手动下载更新包安装别一直重试同一句命令。wsl --update 无法与服务器建立连接网络问题导致更新失败。先确认系统能正常访问微软的服务能访问的话换这个方式下载WSL更新用的.msu安装包双击安装后重启终端。finalshell 连接本地 wsl debian没有目录显示这是热词里另一个高发问题其实和迁移无关但很多人迁移完就想连着用。FinalShell本质是个SSH客户端它连不上WSL或者连上没有目录通常是WSL里没装SSH服务或者SSH服务没启动。排查顺序WSL内安装并启动sshdsudo apt install openssh-server sudo service ssh start确认ssh localhost能通。检查Windows防火墙是否放行了22端口。如果FinalShell里填的是WSL动态IP注意每次重启IP都会变填localhost走端口转发更省心。7. 我总结的WSL迁移检查单与几条经验7.1 把 WSL 当“系统镜像”管理迁移过几次之后你会发现WSL的真正用法不是“在Windows里装个Linux”而是把它当成一个可打包、可复用的运行环境。热词里“数据中台建设中的数据迁移方案:异构系统整合”、“国产化迁移”这些概念底层思路其实是通的识别交付物、明确目标环境、验证兼容性。WSL迁移也是一样tar包就是交付物目标机器就是新环境验证清单就是兼容性测试。日常维护上我有几个习惯应用尽量跑在Docker容器里WSL只保留Docker Engine和基础工具。这样迁移时只要保证Docker能启动容器里的服务原地复活。Python环境尽量用conda管理并且把environment.yml纳入版本控制。.ssh、.gitconfig、.bashrc这些配置单独放到一个私有备份仓库定期提交。每个项目一个虚拟环境不给系统Python装乱七八糟的包。这样即使迁移后某个环境坏了也只是重装一个venv而已。7.2 可直接抄的迁移检查单阶段命令/操作确认点备份wsl --shutdown后wsl --export Ubuntu D:\temp\ubuntu.tartar包存在且大小合理环境清单pip freeze、conda env export --from-historyrequirements.txt、environment.yml已生成导入wsl --import Ubuntu-D D:\WSL\Ubuntu-D D:\temp\ubuntu.tar --version 2wsl -l -v列表出现新名字和版本2默认用户创建/etc/wsl.conf写[user] default用户名然后wsl --shutdown重新进入后whoami输出原用户默认发行版wsl --set-default Ubuntu-DVSCode Remote-WSL自动识别GPU验证nvidia-smi、python -c import torch; print(torch.cuda.is_available())输出True服务检查ssh、redis、cron各自测试一次能连通、能启动清理旧版确认全部通过后wsl --unregister UbuntuC盘对应vhdx消失空间释放7.3 迁移后第一周留着旧环境最后说点个人体会。我见过不少同学迁移完第一时间就把旧发行版删了结果新环境里某个编译好的老项目跑不起来又得从头折腾。迁移这件事最不缺的就是意外同一个tar包导入到不同机器可能因为内核版本、glibc版本、磁盘挂载方式的差异冒出来各种新问题。所以我的策略是新环境并行跑一周旧环境留着当防火墙。如果新环境有问题随时切回旧环境继续工作不用被迫在“环境坏了”和“工作没法停”之间二选一。等新环境真正经受住真实任务考验再清理旧的心里踏实得多。另外一个小技巧每次迁移完在WSL的/tmp下放一个迁移日志文件记录这次改了哪些配置、哪些服务还没起来、下一步要验证什么。迁移本来不难难的是迁移完了你还记得当时怎么搭的。有日志、有检查单下次再换机器这套流程就是一条命令的事。