LXC Windows VMs do not start after latest Ubuntu package updates


About a month ago I was able to get Windows 11 up and running using this guide: How to install a Windows 11 VM using LXD - Tutorials - Ubuntu Community Hub

A couple of days ago, I tried starting it up again but received the following error:

Error: Failed to run: forklimits limit=memlock:unlimited:unlimited fd=3 -- /snap/lxd/23889/bin/qemu-system-x86_64 -S -name win11-newest -uuid 7c906f77-da6f-492e-8c83-417fb4eeea62 -daemonize -cpu host,hv_passthrough -nographic -serial chardev:console -nodefaults -no-user-config -sandbox on,obsolete=deny,elevateprivileges=allow,spawn=allow,resourcecontrol=deny -readconfig /var/snap/lxd/common/lxd/logs/win11-newest/qemu.conf -spice unix=on,disable-ticketing=on,addr=/var/snap/lxd/common/lxd/logs/win11-newest/qemu.spice -pidfile /var/snap/lxd/common/lxd/logs/win11-newest/qemu.pid -D /var/snap/lxd/common/lxd/logs/win11-newest/qemu.log -smbios type=2,manufacturer=Canonical Ltd.,product=LXD -runas lxd: : Process exited with non-zero value 1

Running lxc info --show-log win11-newest gives me:

Name: win11-newest
Type: virtual-machine
Architecture: x86_64
Created: 2022/11/12 15:27 CET
Last Used: 2022/11/12 15:33 CET


qemu-system-x86_64: tpm-emulator: TPM result for CMD_INIT: 0x9 operation failed

I see the following apparmor DENIED msg in dmesg:

[94148.689943] audit: type=1400 audit(1668264910.751:188): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="lxd-win11-newest_</var/snap/lxd/common/lxd>" pid=240779 comm="apparmor_parser"

[94148.699033] audit: type=1400 audit(1668264910.763:189): apparmor="DENIED" operation="open" profile="lxd-win11-newest_</var/snap/lxd/common/lxd>" name="/var/lib/snapd/hostfs/run/systemd/resolve/stub-resolv.conf" pid=240781 comm="lxd" requested_mask="r" denied_mask="r" fsuid=0 ouid=101

I then tried going through the steps again to create a new one, and just as Windows was about to load the setup screen the container died and now gives me the same errors as the other container.

Anyone have any ideas?

what does snap info lxd show?

Here you go:

name:      lxd
summary:   LXD - container and VM manager
publisher: Canonical✓
store-url: https://snapcraft.io/lxd
contact:   https://github.com/lxc/lxd/issues
license:   unset
description: |
  LXD is a system container and virtual machine manager.
  It offers a simple CLI and REST API to manage local or remote instances,
  uses an image based workflow and support for a variety of advanced features.
  Images are available for all Ubuntu releases and architectures as well
  as for a wide number of other Linux distributions. Existing
  integrations with many deployment and operation tools, makes it work
  just like a public cloud, except everything is under your control.
  LXD containers are lightweight, secure by default and a great
  alternative to virtual machines when running Linux on Linux.
  LXD virtual machines are modern and secure, using UEFI and secure-boot
  by default and a great choice when a different kernel or operating
  system is needed.
  With clustering, up to 50 LXD servers can be easily joined and managed
  together with the same tools and APIs and without needing any external
  Supported configuration options for the snap (snap set lxd [<key>=<value>...]):
    - ceph.builtin: Use snap-specific Ceph configuration [default=false]
    - ceph.external: Use the system's ceph tools (ignores ceph.builtin) [default=false]
    - criu.enable: Enable experimental live-migration support [default=false]
    - daemon.debug: Increase logging to debug level [default=false]
    - daemon.group: Set group of users that have full control over LXD [default=lxd]
    - daemon.user.group: Set group of users that have restricted LXD access [default=lxd]
    - daemon.preseed: Pass a YAML configuration to `lxd init` on initial start
    - daemon.syslog: Send LXD log events to syslog [default=false]
    - daemon.verbose: Increase logging to verbose level [default=false]
    - lvm.external: Use the system's LVM tools [default=false]
    - lxcfs.pidfd: Start per-container process tracking [default=false]
    - lxcfs.loadavg: Start tracking per-container load average [default=false]
    - lxcfs.cfs: Consider CPU shares for CPU usage [default=false]
    - openvswitch.builtin: Run a snap-specific OVS daemon [default=false]
    - openvswitch.external: Use the system's OVS tools (ignores openvswitch.builtin) [default=false]
    - ovn.builtin: Use snap-specific OVN configuration [default=false]
    - shiftfs.enable: Enable shiftfs support [default=auto]
  For system-wide configuration of the CLI, place your configuration in
  /var/snap/lxd/common/global-conf/ (config.yml and servercerts)
  - lxd.benchmark
  - lxd.buginfo
  - lxd.check-kernel
  - lxd.lxc
  - lxd.lxc-to-lxd
  - lxd
  - lxd.migrate
  lxd.activate:    oneshot, enabled, inactive
  lxd.daemon:      simple, enabled, active
  lxd.user-daemon: simple, enabled, inactive
snap-id:      J60k4JY0HppjwOjW8dZdYc8obXKxujRu
tracking:     latest/stable
refresh-date: 14 days ago, at 10:49 CET
  latest/stable:    5.7-c62733b   2022-10-29 (23889) 143MB -
  latest/candidate: 5.7-2d1f249   2022-11-01 (23908) 143MB -
  latest/beta:      ↑                                      
  latest/edge:      git-a104178   2022-11-10 (23927) 143MB -
  5.7/stable:       5.7-c62733b   2022-10-29 (23889) 143MB -
  5.7/candidate:    5.7-2d1f249   2022-11-01 (23908) 143MB -
  5.7/beta:         ↑                                      
  5.7/edge:         ↑                                      
  5.6/stable:       5.6-794016a   2022-09-27 (23680) 142MB -
  5.6/candidate:    5.6-794016a   2022-09-23 (23680) 142MB -
  5.6/beta:         ↑                                      
  5.6/edge:         ↑                                      
  5.5/stable:       5.5-37534be   2022-08-27 (23537) 113MB -
  5.5/candidate:    5.5-37534be   2022-08-19 (23537) 113MB -
  5.5/beta:         ↑                                      
  5.5/edge:         ↑                                      
  5.4/stable:       5.4-1ff8d34   2022-08-13 (23367) 108MB -
  5.4/candidate:    5.4-3bf11b7   2022-08-12 (23453) 108MB -
  5.4/beta:         ↑                                      
  5.4/edge:         ↑                                      
  5.3/stable:       5.3-91e042b   2022-07-06 (23270) 107MB -
  5.3/candidate:    5.3-b403e7f   2022-07-05 (23282) 107MB -
  5.3/beta:         ↑                                      
  5.3/edge:         ↑                                      
  5.0/stable:       5.0.1-9dcf35b 2022-08-24 (23541) 107MB -
  5.0/candidate:    5.0.1-9dcf35b 2022-08-19 (23541) 107MB -
  5.0/beta:         ↑                                      
  5.0/edge:         git-13e1e53   2022-08-21 (23564) 113MB -
  4.0/stable:       4.0.9-8e2046b 2022-03-26 (22753)  71MB -
  4.0/candidate:    4.0.9-dea944b 2022-09-27 (23694)  72MB -
  4.0/beta:         ↑                                      
  4.0/edge:         git-407205d   2022-03-31 (22797)  73MB -
  3.0/stable:       3.0.4         2019-10-10 (11348)  55MB -
  3.0/candidate:    3.0.4         2019-10-10 (11348)  55MB -
  3.0/beta:         ↑                                      
  3.0/edge:         git-81b81b9   2019-10-10 (11362)  55MB -
installed:          5.7-c62733b              (23889) 143MB -

thanks, and what is the LXD host OS?

Ubuntu 22.04.1
Linux hostname 5.15.0-52-generic #58-Ubuntu SMP Thu Oct 13 08:03:55 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

@tomp Any ideas? I’ve got a bunch of work that’s stuck because of this and wanted to see if I need to look for another option to get hold of a Windows machine

Please can I see the lxc config show <instance> --expanded and do you have the install ISO you used, as I haven’t used Windows VMs before.

Ah I see I can use How to install a Windows 11 VM using LXD - Tutorials - Ubuntu Community Hub

@monstermunchkin do you have Windows VM capability to hand that you could test and see if you experience this issue also?

Currently not, but I will look into this.

1 Like

Sure. Here you go:

architecture: x86_64
  limits.cpu: "4"
  limits.memory: 8GiB
  volatile.cloud-init.instance-id: 07b8f70a-cfee-4fbf-8d26-0d02f7256534
  volatile.eth0.host_name: tap164fa381
  volatile.eth0.hwaddr: 00:16:3e:dd:ed:e6
  volatile.last_state.power: RUNNING
  volatile.uuid: afb8adde-44fa-49a1-bbf7-630cf79bd849
  volatile.vsock_id: "15"
    name: eth0
    network: lxdbr0
    type: nic
    boot.priority: "10"
    source: /home/win10.lxd.iso
    type: disk
    path: /
    pool: default
    size: 25GiB
    type: disk
ephemeral: false
- default
stateful: false
description: ""

Fairly standard I guess. I followed the instructions in that link - would be interesting to see if someone else can reproduce it. I don’t know enough about Apparmor to understand if those policies are causing the issues.

Thanks for looking into it!

@splotsh I was able to (accidentally) reproduce your error. This is what happened:

I created the VM as described in the Ubuntu forum. A few seconds after the Windows installer started, the VM was killed by the kernel because my machine ran out of memory. This however left the swtpm process running. Trying to start the VM again resulted in

qemu-system-x86_64: tpm-emulator: TPM result for CMD_INIT: 0x9 operation failed

So, if you just kill the correct swtpm process, and start the VM again it should work. I changed the VM config to limits.memory=4GiB, and now everything runs without any issues.


That is exactly what it was. Thanks so much @monstermunchkin