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.
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
dependencies.
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)
commands:
- lxd.benchmark
- lxd.buginfo
- lxd.check-kernel
- lxd.lxc
- lxd.lxc-to-lxd
- lxd
- lxd.migrate
services:
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
channels:
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 -
@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
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.
@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.