Here's my failed attempt in case it's of use to anyone or you can spot a quick way to sort the lack of systemd init.
My need is to be able to retrieve a backup of a Proxmox container from a cloud backup and run it on Windows as there are some key containers that it would be useful to have up and running as quickly as possible whilst rebuilding a PVE cluster after a catastrophic disaster (think fire or theft etc).
My method can run ok on WSL v1 or v2, but does have some limitations in that the containers should be unprivileged and not reliant on the original underlying OS at all - so no mountpoints or UID/GID maps, although there are ways to work around those kinds of issues once you have your precious container running again!
So assuming you have
Windows Subsystem for Linux (WSL) and
Virtual Machine Platform both enabled on your Windows PC, then It goes something like this:
1. Retrieve your PVE container backup from your cloud storage on to your Windows PC, let's say "
D:\Data\MyLXC\vzdump-lxc-999.tar.zst"
2. Fire up a Powershell (as administrator) and run:
wsl --install --no-launch -d Ubuntu-22.04
3. Create a local user when prompted, then within the new Ubuntu container run:
sudo -i
apt -y install zstd
cd /mnt/d/Data/MyLXC
unzstd vzdump-lxc-999.tar.zst
When this completes you can close the Ubuntu window - we don't need it any more.
We're really just using this Ubuntu container to unpack the ZST file to a TAR. I chose to do it this way as it seems the ZST tools native to Windows are not yet stable for large archives. If this changes then Steps 2 & 3 above can be skipped by using a suitable Windows tool to extract the tar.
4. Back at (admin) Powershell:
wsl --set-default-version 2
wsl --import MyLXC D:\Data\MyLXC D:\Data\MyLXC\vzdump-lxc-999.tar
Note: I'd rather set the default WSL Version to v1, as WSL v1 has a couple of advantages over v2 relevant to this use case:
- Access to Windows filesystem is faster in v1 than v2
- v1 uses bridged network access rather than just NAT, so the container will have the same IP address as the host and be able to accept incoming connections without any further work (except perhaps allow it through Windows firewall)
However, the import process seems to fail with v1 so v2 it is!
You can check that your new container is there with
wsl -l -v and start it with:
wsl -d MyLXC
After a short wait you'll be inside your running container - except you might find nothing has started due to a lack of SystemD :-/
However, I was able to start the processes I needed manually so not all is lost and this may still be sufficient for my disaster recovery needs!
