In general, if you can get a tarball'd rootfs of the VM, it should (in theory) be pretty straightforward, although I haven't tried it. The main trick will be getting the rootfs.tar "just right". Considerations:
It will need to include all "normal" filesystems from the VM, but you can, of course, ignore things like /proc, /sys, /dev, etc.
You should include the --xattrs flag to tar to make sure you pick up any extended attributes. This is not the default.
Once you have a valid rootfs tarball, importing in WSL is easy:
wsl --import Ubuntu2110 <directory> <tarball> --version 2
The first argument (distribution name) can be whatever you prefer, although I'd recommend avoiding Ubuntu as this is the name of the default WSL distro and could cause a conflict.
I tend to set up my WSL "directory":
- Somewhere easy to get to from PowerShell, such as
~\Documents\WSL
- Have
~\Documents\WSL\instances\Ubuntu2110 (and others) for my distributions
- Have
~\Documents\WSL\images\Ubuntu2110.tar (and others) for my rootfs images.
Hardware layer has a good chance to differ.
Not really the issue you might think. WSL2 instances are actually more "containers" than VMs. There is a VM running, but you can't access it. The VM itself is what handles the import and running of the distros/instances/containers. All WSL2 instances share the same kernelspace, virtual hardware, network, etc., but each has its own PID namespace, chroot, etc (to oversummarize).
Differences between WSL and your VM
System startup
The biggest difference you are going to find is that the VM does all of its configuration via Systemd, of course. That's not going to happen on WSL2, as Systemd isn't supported. Instead, WSL uses its own /init for bootstrapping the interoperability with the system VM and Windows.
That means that, when you start up the WSL2 instance from the imported VM, pretty much nothing is going to be running.
You'll need to start each service manually. Or use other techniques to start automatically.
Other Systemd issues
While you can start many services in Ubuntu without Systemd, more and more are relying on Systemd. Those can be problematic under WSL. Although there are workarounds to run Systemd in WSL, they tend to be "hacky" at present.
GUI Apps
Also, remember that WSL is primarily a command-line environment. To run GUI apps, you'll need to run either:
- Windows 11
- A third-party X server in Windows
- Or
xrdp
Desktop Environments
Finally, desktop environments can be even more challenging, for a combination of the above reasons and more:
- Some require Systemd
- Running full-screen Linux GUI apps in Windows can present key-binding challenges (e.g. Alt+Tab will be intercepted by Windows and shift away from your DE).
- WSLg in Windows 11 utilizes Weston, which provides its own window manager
