Status of LXD on WSL2

Update 17 June 2019:

WSL2 is the new subsystem on Windows to run the Ubuntu runtime.
Compared to WSL1, WSL2 actually uses the Linux kernel running inside a lightweight version of Hyper-V.
Therefore, it should be possible to get LXD running in there.

I just tried getting LXD to work on WSL2 and here are the results.
The short story is that I could not make it work.


  1. The Ubuntu image for WSL1 and WSL2 does not support systemd yet, therefore you cannot get the snap package of LXD to install. There is some ongoing work and workarounds at (see towards the end), however I could not make them work.

  2. The Ubuntu image for WSL1 and WSL2 does come with LXD pre-installed (apt package). As a service it is not running by default, therefore, you need to start it. Remember those commands?

    sudo service lxd start
  3. You then need to run sudo lxd init to initialize LXD.
    3.1. By default, LXD is happy to use brtfs, and manages to initialize it. All good regarding the storage driver.
    3.2. LXD fails to create lxdbr0 with the following error. If you retry without networking, then sudo lxd init completes successfully.

    Error: Failed to create network 'lxdbr0': Failed to run: iptables -w -t filter -I INPUT -i lxdbr0 -p udp --dport 67 -j ACCEPT -m comment --comment generated for LXD network lxdbr0: iptables: No chain/target/match by that name.
  4. When you try to launch a container, you get the following error (was trying to get macvlan to work at the same time, hence the networking error):

lxc mycontainer 20190614081018.500 ERROR    utils - utils.c:safe_mount:1179 - Operation not permitted - Failed to mount "sysfs" onto "/usr/lib/x86_64-linux-gnu/lxc/sys"
lxc mycontainer 20190614081018.500 ERROR    conf - conf.c:lxc_mount_auto_mounts:724 - Operation not permitted - Failed to mount "sysfs" on "/usr/lib/x86_64-linux-gnu/lxc/sys" with flags 0
lxc mycontainer 20190614081018.500 ERROR    conf - conf.c:lxc_setup:3539 - Failed to setup first automatic mounts
lxc mycontainer 20190614081018.500 ERROR    start - start.c:do_start:1263 - Failed to setup container "mycontainer"
lxc mycontainer 20190614081018.500 ERROR    sync - sync.c:__sync_wait:62 - An error occurred in another process (expected sequence number 5)
lxc mycontainer 20190614081018.500 WARN     network - network.c:lxc_delete_network_priv:2589 - Operation not permitted - Failed to remove interface "eth0" with index 7
lxc mycontainer 20190614081018.500 ERROR    lxccontainer - lxccontainer.c:wait_on_daemonized_start:842 - Received container state "ABORTING" instead of "RUNNING"
lxc mycontainer 20190614081018.501 ERROR    start - start.c:__lxc_start:1939 - Failed to spawn container "mycontainer"
lxc 20190614081018.506 WARN     commands - commands.c:lxc_cmd_rsp_recv:132 - Connection reset by peer - Failed to receive response for command "get_state"

It seems like things are moving now at least.


More generally speaking, for those you want to know the current state of WSL2 (about performances and a bit about debugging):

There’s still a way before it can be used seriously. But it’s underway.



I wrote a post on getting LXD running on WSL2. It is mostly a tutorial on LXD proxy devices :-).
Here it is,

1 Like

Great work.

What is performance like?

I’m going to wait until things settle down before I give this a try.

I did not test the performance. In terms of potential bottlenecks, I think that I/O should be acceptable (btrfs over a loop file). Regarding the networking, it uses proxy devices.

Currently, to get WSL2, you need to switch your Windows 10 to Windows Insider and on top of that select the fast ring (most frequent updates). This is not for production use.

So, I have made some progress in this direction in various ways, most notably genie - - which lets you run systemd as pid 1 under WSL 2, and by recompiling the WSL 2 kernel to include various needed options, as documented in .

These two have been enough to get snapd up and running, and the lxd snap installed and inited, networking/lxdbr0 included. Still having some trouble launching containers (the operation not permitted trying to mount sysfs error), though.

As per Cannot start container (sysfs mount problem) , I can now run containers using the workaround for the sysfs mounting issue, so I can confirm that the networking works in practice, as well as in theory. :sunglasses:

1 Like