上周我在win11上折腾了一件事给WSL里的Ubuntu 24.04再装一个副本并且把两个实例重命名成自己能一眼看懂的名字。起因很简单主力环境已经养得很肥——编译链、CUDA、Python虚拟环境、VSCode Remote-WSL的整套配置全在里面。我想装ROS2 humble、跑binwalk的固件分析、试一下Linux版微信又不想把这些可能互相打架的依赖塞进主力环境。WSL实例之间是互相隔离的完整rootfs比conda/venv那种同一系统下的虚拟环境隔离得更干净所以我决定直接开第二个实例。本以为自己很懂WSL动手才发现安装两个这三个字里全是坑。最大的坑在于WSL的实例名DistributionName是唯一标识直接再次执行wsl --install -d Ubuntu-24.04得到的不是第二个Ubuntu而是已安装的提示。想要两个独立实例必须绕开同名注册的限制。而绕开限制之后又带来一个新问题两个实例名字差不多怎么办于是安装两个和重命名这两件事在我实际折腾里彻底绑到了一起。下面这些内容就是我的完整实操记录包含命令、原理和踩坑过程。如果你也有类似需求——想在WSL里同时维护开发环境和实验环境或者只是想把wsl -l -v里那一堆默认名理顺——可以参考我这套思路。1. 为什么需要同时运行两个Ubuntu 24.04主力环境与实验环境的隔离需求1.1 主力环境的养肥困境用过WSL一段时间的人都会有个共同感受环境越用越值钱。以我为例当前这个Ubuntu 24.04实例是年初从WSL 2.0开始用的里面装了完整的GCC/Clang编译链和CMake构建体系CUDA Toolkit和cuDNN也配好了日常写代码用的Python 3.12环境里顺手装了torch和numpy再加上git、docker、以及一堆调了好久的VSCode Remote-WSL插件配置。这些东西一旦被搞坏重新搭一遍的成本没法估。实验性质的东西恰恰最喜欢污染环境。比如热搜里常见的ubuntu24.04安装ros2humbleROS 2的依赖树非常大安装过程中会把一堆Python包、消息库、可视化工具拷进系统再比如wsl使用binwalkbinwalk是固件分析工具经常要装各种二进制分析依赖有时还配合pip install一堆奇怪的包。这些都该和主力开发环境隔离开不然某天apt upgrade时一个依赖冲突就能让你一整天都耗在修环境上。WSL在这方面的优势是天然的每个实例都有独立的rootfs、独立的用户空间、独立的系统配置。你在实验实例里装坏了什么删掉重来就是完全不碰主力环境。这比conda、venv那种同一系统下隔离的方案要彻底得多因为连内核模块、systemd服务、/etc配置这些底层东西都是分开的。1.2 名字一样造成的实际困惑装第二个实例之前我先用wsl -l -v确认了一下现有实例的完整信息输出长这样NAME STATE VERSION * Ubuntu-24.04 Stopped 2看起来只有一个对吧问题就出在装第二个实例时。WSL不允许出现两个完全同名的发行版当你尝试再装一个Ubuntu-24.04时它会提示名称已存在。我用export/import绕开限制后给新实例起了个临时名字可很多人的做法是找网上的脚本、镜像包强行绕过最终得到Ubuntu-24.04和Ubuntu-24.04_1这种混乱命名。这种状态下用wsl -d切换你根本分不清哪个是主力、哪个是实验区。重命名的需求就是这么冒出来的。后来我把两个实例统一成了Ubuntu2404-Main和Ubuntu2404-Lab一个负责日常开发一个专门跑实验和测试一眼就能看出来该进哪个环境再也不用拿终端记录去猜了。2. 动手前的关键检查WSL版本、系统组件与在线安装的坑2.1 先确认WSL版本再谈操作虽然win11里一般不会出现WSL 1.x这种古董版本但WSL 2.0之后的功能差异很大。比如后面要用的wsl --export --vhd参数就是较新版本才支持的WSL 2.0.9以后的autoMemoryReclaim也是新版本特性。所以正式开始前我建议先看一眼版本wsl --version输出类似这样WSL 版本 2.3.26.0 内核版本 5.15.167.4 WSLg 版本 1.0.51只要WSL版本号是2.x本文的方法基本都能用。如果版本过老可以先wsl --update升级。这里多说一句wsl --update下载很慢是搜索词里高频出现的问题我也遇到过。它卡在正在下载适用于 Linux 的 Windows 子系统的进度条好几分钟不动多半是网络环境的问题换个时段重试、或者关闭占用带宽的下载任务往往就好了。如果你急着用其实完全可以跳过wsl --install的在线安装步骤直接用后面要讲的rootfs导入方式照样能得到完整的Ubuntu 24.04实例而且基本不受这次下载慢的影响。2.2 系统组件和虚拟化检查WSL 2依赖两个Windows功能虚拟机平台VirtualMachinePlatform和适用于Linux的Windows子系统。正常情况下装过WSL的人这两项都是开启的但如果你想在一台没装过WSL的机器上从头搭或者排查启动失败可以这样确认dism.exe /online /get-featureinfo /featurename:Microsoft-Windows-Subsystem-Linux dism.exe /online /get-featureinfo /featurename:VirtualMachinePlatform需要管理员权限的CMD或PowerShell。更直观的方式是打开启用或关闭Windows功能把这两个选项勾上重启。另外虚拟化必须在BIOS/UEFI里打开在任务管理器的性能 - CPU页面能看到虚拟化已启用的字样。这一步常被忽略尤其是老机器从win10升级到win11之后有一小部分主板默认没开启虚拟化WSL 2就会一直报错或者切回WSL 1。2.3 备份等于给自己买保险接下来的操作不管是导出导入还是改注册表都建议先给现有实例做一次快照。WSL没有自带快照功能但导出其实就是快照wsl --shutdown wsl --export Ubuntu-24.04 D:\WSLBackup\ubuntu2404-before-change.tarWSL 2.0以上版本还可以用--vhd参数直接导出为vhdxwsl --export Ubuntu-24.04 D:\WSLBackup\ubuntu2404-before-change.vhdx --vhd这里有个细节wsl --export前必须先wsl --shutdown否则会提示实例正在使用或者导出不完整。导出时间取决于你的rootfs大小我那个装了一堆工具的实例大概导出了10多分钟。备份这一步千万别跳我后来在改注册表之前就吃了以为自己稳结果差点把DistributionName改错的亏还好有备份能退回去。3. 获取第二个Ubuntu 24.04实例导出导入法与rootfs导入法实测3.1 为什么直接执行wsl --install -d不行先说最常见的误区。很多人拿到装第二个Ubuntu这个需求第一反应就是敲wsl --install -d Ubuntu-24.04如果你第一次装Ubuntu 24.04用的就是这条命令那现在再执行一次大概率会得到两种结果一是走Microsoft Store渠道的时候提示该应用已安装二是命令行渠道检测到同名发行版直接拒绝创建。这不是bug是设计如此——DistributionName在WSL里是唯一标识。同一个名字不能注册两次。所以安装两个的正确思路是给第二个实例起一个新名字绕开同名限制。这也是为什么本文的重心会落在导出导入和重命名上——因为在WSL的使用哲学里实例名从创建那一刻起就应该表达用途。3.2 方法一从现有实例导出再导入复制主力环境如果你希望第二个实例里已经带着一部分配置比如apt源、常用工具、开发环境底子就用这条路。我的完整操作是这样wsl --shutdown wsl --export Ubuntu-24.04 D:\WSLBackup\ubuntu2404-template.tar wsl --import Ubuntu2404-Lab D:\WSL\Ubuntu2404-Lab D:\WSLBackup\ubuntu2404-template.tar --version 2逐条解释一下参数Ubuntu2404-Lab新实例的名字可以任意起建议用字母、数字、连字符别用中文和空格。D:\WSL\Ubuntu2404-Lab新实例的根目录ext4.vhdx虚拟磁盘会放到这里。目标目录不要跟旧实例混在一起方便以后单独压缩和迁移。D:\WSLBackup\ubuntu2404-template.tar刚才导出的tar归档文件。--version 2强制指定WSL 2模式。执行完wsl --import后跑一下wsl -l -v此时你已经有了两个Ubuntu 24.04实例原来的Ubuntu-24.04和新的Ubuntu2404-Lab。文件、用户、系统配置都被复制过来了。如果你担心tar导出/导入会丢掉一些WSL 2的新特性可以用--vhd方式wsl --export Ubuntu-24.04 D:\WSLBackup\ubuntu2404-template.vhdx --vhd wsl --import Ubuntu2404-Lab D:\WSL\Ubuntu2404-Lab D:\WSLBackup\ubuntu2404-template.vhdx --vhd --version 2--vhd的好处是导出后的文件就是原始虚拟磁盘导入更快虚拟磁盘的稀疏属性保持得更接近原生缺点是体积大。tar方式更适合归档和跨机器迁移。两种方式导入后的实例在文件系统层面没本质区别主要看你手头场景更适合哪种。3.3 方法二从rootfs直接导入全新环境如果你想要的是一个干净的Ubuntu 24.04不想背着主力环境的历史包袱可以从Ubuntu官方渠道拿rootfs tar.gz比如ubuntu-24.04-minimal-cloudimg-amd64-rootfs.tar.gz这类文件然后wsl --import Ubuntu2404-Dev D:\WSL\Ubuntu2404-Dev D:\Downloads\ubuntu-24.04-minimal-cloudimg-amd64-rootfs.tar.gz --version 2rootfs导入同样能指定任何你喜欢的实例名。而且它不依赖在线商店速度受网络影响小得多——如果你正好卡在wsl --install太慢或wsl --update下载很慢上这招可以绕过那些坑。从cloud image rootfs导入的实例默认用户是root没有走Ubuntu首次启动的OOBE流程。进去之后需要自己建普通用户、配sudo、装基础工具。这反而适合完全自定义的场景。我自己最常用的是方法一因为每次在新实例里重新配置.zshrc、VSCode插件、git config都很烦如果只是给客户做演示、跑一次性实验方法二更符合用完即弃的定位。4. 给WSL实例重命名两种方案与它们的适用边界4.1 路线一export/import强制改名在上一节的操作里我们其实已经通过导入时指定新名字实现了新实例的命名。如果你需要一个旧实例彻底改头换面思路也差不多先导出再以新名字导入最后删除旧实例。命令示例wsl --shutdown wsl --export Ubuntu-24.04 D:\WSLBackup\rename-tmp.tar wsl --import Ubuntu2404-Main D:\WSL\Ubuntu2404-Main D:\WSLBackup\rename-tmp.tar --version 2 wsl --unregister Ubuntu-24.04这套流程的优点是改的是注册信息底层文件系统整体搬过去了系统里的用户、文件、服务都还在。缺点是导入后默认用户变成root需要重新配置默认登录用户迁移期间磁盘占用会膨胀tar导出是对整个rootfs的归档如果实例里配了systemd服务、自启动任务导入后可能需要重新启动一遍。wsl --unregister这个命令要谨慎用它会删除实例的根目录和所有文件。执行前务必确认新实例已经正常启动过里面的文件都完整了。4.2 路线二直接改注册表DistributionName如果不想重建虚拟磁盘只想把显示的实例名改掉注册表是更快的路径。操作分四步第一步彻底停止WSLwsl --shutdown第二步打开注册表编辑器进入计算机\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Lxss第三步这里会有若干个以GUID命名的子键每个子键代表一个WSL发行版。关键字段如下字段含义说明DistributionName实例在wsl -l -v里显示的名字要改的就是它BasePath虚拟磁盘所在路径用于确认哪个GUID对应哪个实例DefaultUid默认用户的UID0表示root建议顺手检查Version2表示WSL2不要随意改通过BasePath可以定位到具体实例。比如BasePath指向某个目录包含LocalState和ext4.vhdx基本就能确认它是哪一个Ubuntu。确认无误后双击DistributionName把值改成你想要的新名字例如Ubuntu2404-Main确定保存。第四步回到终端验证wsl -l -v名字已经变了直接wsl -d Ubuntu2404-Main能正常进入。注意修改注册表前一定要先wsl --shutdown。如果LxssManager还在运行新的DistributionName不会被加载甚至可能出现状态不一致的情况。修改前建议右键Lxss键选择导出留一份备份改错了还能还原。4.3 两种方案怎么选方案路径操作默认用户适用场景风险export/import改名重建实例root彻底搬家、顺便清理老配置耗时较长需重新配置用户注册表改名原地改名保持原状只改显示名、快速落地操作前需做好备份我的做法是混合使用主力实例Ubuntu2404-Main保留原始文件系统只用注册表改名实验实例Ubuntu2404-Lab用export/import创建因为它本来就该是可丢弃的随时可以重新导入。你在实际使用中也可以按这个思路来主环境尽量少动底层结构实验环境大胆造。5. 改名后的连锁反应Terminal、VSCode与默认用户的完整排查5.1 Windows Terminal里的旧配置残留WSL实例改名或者新增之后Windows Terminal会自动为它生成一个新的profile但旧profile不会自动消失。打开Windows Terminal设置你会发现左边多了一个新发行版入口同时旧名字的入口还挂在列表里。点击旧名字最终会启动失败因为wsl.exe -d 旧名字已经找不到目标了。我的处理步骤打开Windows Terminal设置Ctrl,在配置文件里找到旧名字生成的profile手动删除新建配置文件命令行填wsl.exe -d Ubuntu2404-Main启动目录填\wsl$\Ubuntu2404-Main\root给这个profile起一个容易记的名字比如U2404-Main。如果你习惯直接改settings.json也可以在里面找到对应distribution字段的profile删掉。WSL动态生成的profile一般会有source标记清理时不要误删手动配置过的profile。5.2 默认用户从普通用户变成root的问题这是重命名/导入后最容易踩的坑。原本Ubuntu 24.04首次启动时OOBE会创建一个普通用户比如dev带sudo权限。但通过wsl --import导入的实例不执行OOBE启动后默认登录rootwhoami输出root。原因就是导入过程中没有携带默认用户信息也没有写入/etc/wsl.conf的user段。解决方式有两个临时指定用户wsl -d Ubuntu2404-Lab -u dev这样以dev身份进入永久设置默认用户编辑目标实例里的/etc/wsl.conf[user] defaultdev然后wsl --shutdown再启动实例默认用户就变成dev了。注意dev必须已经存在于/etc/passwd里如果rootfs里没有可用用户先手动创建useradd -m -s /bin/bash dev passwd dev usermod -aG sudo dev这一步做完基本就还原了正常Ubuntu的使用体验。如果是注册表改名路线默认用户会沿用原来的DefaultUid通常不会遇到这个问题。5.3 VSCode Remote-WSL连接失败的排查链路改名对VSCode的Remote-WSL影响比较隐蔽。如果你之前在VSCode里打开了\wsl$\Ubuntu-24.04\home\dev\myproject这样的路径改名后旧的WSL目标就失效了Remote Explorer下拉列表还显示旧名字点击连接大概率会卡在正在启动VS Code Server或者直接报错。完整排查链路如下先确认WSL实例本身是否健康在Windows终端执行wsl -d 新名字能进入且whoami是预期用户说明实例没问题再看wsl -l -v里的名字和版本是否正常如果Remote Explorer里没有新名字关掉VSCode重开让它重新扫描WSL发行版如果扫描到了但连接卡住多半是VS Code Server组件需要重装在WSL终端里执行code .VSCode会自动下载server组件到~/.vscode-server等它装完再连如果资源管理器里的\wsl$路径仍指向旧名字重启一次系统或重启Windows Explorer。我实际操作中遇到的是第4种情况重新执行code .之后VSCode右下角弹出重新加载窗口选Reload Window马上就好了。这里有个经验值得分享WSL实例名在VSCode里是作为连接标识的名字变了等于换了台机器旧会话的信任状态、扩展同步都要重新触发一遍。改名前把VSCode里打开的WSL文件夹记录导出一份能省不少事。6. 多实例的日常管理资源分配、空间回收与使用习惯6.1 .wslconfig全局资源配置一台win11机器上跑多个WSL实例资源分配问题迟早会碰到。WSL 2的架构是所有实例共享同一个轻量级虚拟机内存和CPU都在C:\Users\你的用户名.wslconfig里统一配置[wsl2] memory8GB processors6 swap4GB autoMemoryReclaimgradualautoMemoryReclaim是WSL 2.0.9以上版本放出的参数取值有gradual、dropcache、disabled。它能在实例空闲时自动把宿主机内存收回来解决WSL吃满内存不吐的老毛病。如果你经常同时开着Main和Lab两个实例建议加上这一行。要注意.wslconfig是全局配置修改后需要wsl --shutdown再重启WSL会话才生效。目前还不能给单个实例单独分配CPU或内存这是WSL设计理念决定的——实例之间共享资源池而不是每个实例独占一台VM。6.2 删除文件后vhdx空间不释放的压缩方案wsl linux删除文件后空间没释放是很多人都会搜的问题。原因很简单ext4.vhdx是动态扩展的虚拟磁盘你在Linux里rm掉几十GB文件宿主机看到的还是那个胖胖的vhdx文件不会自动瘦身。压缩方法第一步彻底停止WSLwsl --shutdown第二步用管理员身份打开CMD进入diskpartdiskpart select vdisk fileC:\Users\你的用户名\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu24.04LTS_xxxxxx\LocalState\ext4.vhdx attach vdisk readonly compact vdisk detach vdisk exit路径要替换成你自己的实际路径。用wsl --import放到自定义目录的实例直接去那个目录找ext4.vhdx即可。如果装了Hyper-V模块也可以用PowerShellOptimize-VHD -Path D:\WSL\Ubuntu2404-Lab\ext4.vhdx -Mode FullOptimize-VHD的Full模式比diskpart更彻底但耗时也更长。为避免频繁压缩比较好的习惯是定期清理sudo apt clean sudo journalctl --vacuum-time3d清完再压缩文件能小不少。我在实验实例上常用这套组合压缩后vhdx能减掉几个GB。6.3 多实例环境下我养成的几个小习惯技术细节聊完了随手分享几个日常习惯。我现在把WSL实例名当成环境标签来用命名规则统一是Ubuntu2404-用途比如Ubuntu2404-Main、Ubuntu2404-Lab、Ubuntu2404-Build。每天启动实例尽量用显式命令wsl -d Ubuntu2404-Main而不是直接敲wsl——后者一定进入默认实例默认实例经常切换还是显式指定靠谱。给多个实例设置默认入口也有个小技巧wslconfig /s Ubuntu2404-Main这样打开wsl.exe会直接进入Main实例。临时想切到Lab就wsl -d Ubuntu2404-Lab不用改默认配置。还有一点经验是WSL实例变了名字之后Docker在WSL里的配置、systemd服务、自启动脚本都会受到影响需要回到实例内部确认systemctl status是否正常。有一回我给实验实例配了daemon.json改名后docker一直起不来检查才发现忘了在wsl.conf里开systemd[boot] systemdtrue加上这一行再wsl --shutdown重启一切如常。这篇文章里提到的所有命令我自己都用了一遍踩过的坑也都标注出来了。如果你也卡在有两个实例却分不清谁是谁的尴尬里照这个思路把名字理顺、把默认用户配置好日常切换会舒服很多。