LXD 2.0: Image management [5/12]

This is the fifth blog post in this series about LXD 2.0.

LXD logo

Container images

If you’ve used LXC before, you probably remember those LXC “templates”, basically shell scripts that spit out a container filesystem and a bit of configuration.

Most templates generate the filesystem by doing a full distribution bootstrapping on your local machine. This may take quite a while, won’t work for all distributions and may require significant network bandwidth.

Back in LXC 1.0, I wrote a “download” template which would allow users to download pre-packaged container images, generated on a central server from the usual template scripts and then heavily compressed, signed and distributed over https. A lot of our users switched from the old style container generation to using this new, much faster and much more reliable method of creating a container.

With LXD, we’re taking this one step further by being all-in on the image based workflow. All containers are created from an image and we have advanced image caching and pre-loading support in LXD to keep the image store up to date.

Interacting with LXD images

Before digging deeper into the image format, lets quickly go through what LXD lets you do with those images.

Transparently importing images

All containers are created from an image. The image may have come from a remote image server and have been pulled using its full hash, short hash or an alias, but in the end, every LXD container is created from a local image.

Here are a few examples:

lxc launch ubuntu:14.04 c1
lxc launch ubuntu:75182b1241be475a64e68a518ce853e800e9b50397d2f152816c24f038c94d6e c2
lxc launch ubuntu:75182b1241be c3

All of those refer to the same remote image (at the time of this writing), the first time one of those is run, the remote image will be imported in the local LXD image store as a cached image, then the container will be created from it.

The next time one of those commands are run, LXD will only check that the image is still up to date (when not referring to it by its fingerprint), if it is, it will create the container without downloading anything.

Now that the image is cached in the local image store, you can also just start it from there without even checking if it’s up to date:

lxc launch 75182b1241be c4

And lastly, if you have your own local image under the name “myimage”, you can just do:

lxc launch my-image c5

If you want to change some of that automatic caching and expiration behavior, there are instructions in an earlier post in this series.

Manually importing images

Copying from an image server

If you want to copy some remote image into your local image store but not immediately create a container from it, you can use the “lxc image copy” command. It also lets you tweak some of the image flags, for example:

lxc image copy ubuntu:14.04 local:

This simply copies the remote image into the local image store.

If you want to be able to refer to your copy of the image by something easier to remember than its fingerprint, you can add an alias at the time of the copy:

lxc image copy ubuntu:12.04 local: --alias old-ubuntu
lxc launch old-ubuntu c6

And if you would rather just use the aliases that were set on the source server, you can ask LXD to copy the for you:

lxc image copy ubuntu:15.10 local: --copy-aliases
lxc launch 15.10 c7

All of the copies above were one-shot copy, so copying the current version of the remote image into the local image store. If you want to have LXD keep the image up to date, as it does for the ones stored in its cache, you need to request it with the –auto-update flag:

lxc image copy images:gentoo/current/amd64 local: --alias gentoo --auto-update

Importing a tarball

If someone provides you with a LXD image as a single tarball, you can import it with:

lxc image import <tarball>

If you want to set an alias at import time, you can do it with:

lxc image import <tarball> --alias random-image

Now if you were provided with two tarballs, identify which contains the LXD metadata. Usually the tarball name gives it away, if not, pick the smallest of the two, metadata tarballs are tiny. Then import them both together with:

lxc image import <metadata tarball> <rootfs tarball>

Importing from a URL

“lxc image import” also works with some special URLs. If you have an https web server which serves a path with the LXD-Image-URL and LXD-Image-Hash headers set, then LXD will pull that image into its image store.

For example you can do:

lxc image import https://dl.stgraber.org/lxd --alias busybox-amd64

When pulling the image, LXD also sets some headers which the remote server could check to return an appropriate image. Those are LXD-Server-Architectures and LXD-Server-Version.

This is meant as a poor man’s image server. It can be made to work with any static web server and provides a user friendly way to import your image.

Managing the local image store

Now that we have a bunch of images in our local image store, lets see what we can do with them. We’ve already covered the most obvious, creating containers from them but there are a few more things you can do with the local image store.

Listing images

To get a list of all images in the store, just run “lxc image list”:

stgraber@dakara:~$ lxc image list
|     ALIAS     | FINGERPRINT  | PUBLIC |                     DESCRIPTION                      |  ARCH  |   SIZE   |         UPLOAD DATE          |
| alpine-32     | 6d9c131efab3 | yes    | Alpine edge (i386) (20160329_23:52)                  | i686   | 2.50MB   | Mar 30, 2016 at 4:36am (UTC) |
| busybox-amd64 | 74186c79ca2f | no     | Busybox x86_64                                       | x86_64 | 0.79MB   | Mar 30, 2016 at 4:33am (UTC) |
| gentoo        | 1a134c5951e0 | no     | Gentoo current (amd64) (20160329_14:12)              | x86_64 | 232.50MB | Mar 30, 2016 at 4:34am (UTC) |
| my-image      | c9b6e738fae7 | no     | Scientific Linux 6 x86_64 (default) (20160215_02:36) | x86_64 | 625.34MB | Mar 2, 2016 at 4:56am (UTC)  |
| old-ubuntu    | 4d558b08f22f | no     | ubuntu 12.04 LTS amd64 (release) (20160315)          | x86_64 | 155.09MB | Mar 30, 2016 at 4:30am (UTC) |
| w (11 more)   | d3703a994910 | no     | ubuntu 15.10 amd64 (release) (20160315)              | x86_64 | 153.35MB | Mar 30, 2016 at 4:31am (UTC) |
|               | 75182b1241be | no     | ubuntu 14.04 LTS amd64 (release) (20160314)          | x86_64 | 118.17MB | Mar 30, 2016 at 4:27am (UTC) |

You can filter based on the alias or fingerprint simply by doing:

stgraber@dakara:~$ lxc image list amd64
|     ALIAS     | FINGERPRINT  | PUBLIC |               DESCRIPTION               |  ARCH  |   SIZE   |          UPLOAD DATE         |
| busybox-amd64 | 74186c79ca2f | no     | Busybox x86_64                          | x86_64 | 0.79MB   | Mar 30, 2016 at 4:33am (UTC) |
| w (11 more)   | d3703a994910 | no     | ubuntu 15.10 amd64 (release) (20160315) | x86_64 | 153.35MB | Mar 30, 2016 at 4:31am (UTC) |

Or by specifying a key=value filter of image properties:

stgraber@dakara:~$ lxc image list os=ubuntu
|    ALIAS    | FINGERPRINT  | PUBLIC |                  DESCRIPTION                |  ARCH  |   SIZE   |          UPLOAD DATE         |
| old-ubuntu  | 4d558b08f22f | no     | ubuntu 12.04 LTS amd64 (release) (20160315) | x86_64 | 155.09MB | Mar 30, 2016 at 4:30am (UTC) |
| w (11 more) | d3703a994910 | no     | ubuntu 15.10 amd64 (release) (20160315)     | x86_64 | 153.35MB | Mar 30, 2016 at 4:31am (UTC) |
|             | 75182b1241be | no     | ubuntu 14.04 LTS amd64 (release) (20160314) | x86_64 | 118.17MB | Mar 30, 2016 at 4:27am (UTC) |

To see everything LXD knows about a given image, you can use “lxc image info”:

stgraber@castiana:~$ lxc image info ubuntu
Fingerprint: e8a33ec326ae7dd02331bd72f5d22181ba25401480b8e733c247da5950a7d084
Size: 139.43MB
Architecture: i686
Public: no
 Created: 2016/03/15 00:00 UTC
 Uploaded: 2016/03/16 05:50 UTC
 Expires: 2017/04/26 00:00 UTC
 version: 12.04
 aliases: 12.04,p,precise
 architecture: i386
 description: ubuntu 12.04 LTS i386 (release) (20160315)
 label: release
 os: ubuntu
 release: precise
 serial: 20160315
 - ubuntu
Auto update: enabled
 Server: https://cloud-images.ubuntu.com/releases
 Protocol: simplestreams
 Alias: precise/i386

Editing images

A convenient way to edit image properties and some of the flags is to use:

lxc image edit <alias or fingerprint>

This opens up your default text editor with something like this:

autoupdate: true
 aliases: 14.04,default,lts,t,trusty
 architecture: amd64
 description: ubuntu 14.04 LTS amd64 (release) (20160314)
 label: release
 os: ubuntu
 release: trusty
 serial: "20160314"
 version: "14.04"
public: false

You can change any property you want, turn auto-update on and off or mark an image as publicly available (more on that later).

Deleting images

Remove an image is a simple matter of running:

lxc image delete <alias or fingerprint>

Note that you don’t have to remove cached entries, those will automatically be removed by LXD after they expire (by default, after 10 days since they were last used).

Exporting images

If you want to get image tarballs from images currently in your image store, you can use “lxc image export”, like:

stgraber@dakara:~$ lxc image export old-ubuntu .
Output is in .
stgraber@dakara:~$ ls -lh *.tar.xz
-rw------- 1 stgraber domain admins 656 Mar 30 00:55 meta-ubuntu-12.04-server-cloudimg-amd64-lxd.tar.xz
-rw------- 1 stgraber domain admins 156M Mar 30 00:55 ubuntu-12.04-server-cloudimg-amd64-lxd.tar.xz

Image formats

LXD right now supports two image layouts, unified or split. Both of those are effectively LXD-specific though the latter makes it easier to re-use the filesystem with other container or virtual machine runtimes.

LXD being solely focused on system containers, doesn’t support any of the application container “standard” image formats out there, nor do we plan to.

Our images are pretty simple, they’re made of a container filesystem, a metadata file describing things like when the image was made, when it expires, what architecture its for, … and optionally a bunch of file templates.

See this document for up to date details on the image format.

Unified image (single tarball)

The unified image format is what LXD uses when generating images itself. They are a single big tarball, containing the container filesystem inside a “rootfs” directory, have the metadata.yaml file at the root of the tarball and any template goes into a “templates” directory.

Any compression (or none at all) can be used for that tarball. The image hash is the sha256 of the resulting compressed tarball.

Split image (two tarballs)

This format is most commonly used by anyone rolling their own images and who already have a compressed filesystem tarball.

They are made of two distinct tarball, the first contains just the metadata bits that LXD uses, so the metadata.yaml file at the root and any template in the “templates” directory.

The second tarball contains only the container filesystem directly at its root. Most distributions already produce such tarballs as they are common for bootstrapping new machines. This image format allows re-using them unmodified.

Any compression (or none at all) can be used for either tarball, they can absolutely use different compression algorithms. The image hash is the sha256 of the concatenation of the metadata and rootfs tarballs.

Image metadata

A typical metadata.yaml file looks something like:

architecture: "i686"
creation_date: 1458040200
 architecture: "i686"
 description: "Ubuntu 12.04 LTS server (20160315)"
 os: "ubuntu"
 release: "precise"
   - start
  template: cloud-init-meta.tpl
   - start
  template: cloud-init-user.tpl
   default: |
   - start
  template: cloud-init-vendor.tpl
   default: |
   - create
  template: upstart-override.tpl
   - create
  template: upstart-override.tpl
   - create
  template: upstart-override.tpl
   - create
  template: upstart-override.tpl
   - create
  template: upstart-override.tpl


The two only mandatory fields are the creation date (UNIX EPOCH) and the architecture. Everything else can be left unset and the image will import fine.

The extra properties are mainly there to help the user figure out what the image is about. The “description” property for example is what’s visible in “lxc image list”. The other properties can be used by the user to search for specific images using key/value search.

Those properties can then be edited by the user through “lxc image edit” in contrast, the creation date and architecture fields are immutable.


The template mechanism allows for some files in the container to be generated or re-generated at some point in the container lifecycle.

We use the pongo2 templating engine for those and we export just about everything we know about the container to the template. That way you can have custom images which use user-defined container properties or normal LXD properties to change the content of some specific files.

As you can see in the example above, we’re using those in Ubuntu to seed cloud-init and to turn off some init scripts.

Creating your own images

LXD being focused on running full Linux systems means that we expect most users to just use clean distribution images and not spin their own image.

However there are a few cases where having your own images is useful. Such as having pre-configured images of your production servers or building your own images for a distribution or architecture that we don’t build images for.

Turning a container into an image

The easiest way by far to build an image with LXD is to just turn a container into an image.

This can be done with:

lxc launch ubuntu:14.04 my-container
lxc exec my-container bash
<do whatever change you want>
lxc publish my-container --alias my-new-image

You can even turn a past container snapshot into a new image:

lxc publish my-container/some-snapshot --alias some-image

Manually building an image

Building your own image is also pretty simple.

  1. Generate a container filesystem. This entirely depends on the distribution you’re using. For Ubuntu and Debian, it would be by using debootstrap.
  2. Configure anything that’s needed for the distribution to work properly in a container (if anything is needed).
  3. Make a tarball of that container filesystem, optionally compress it.
  4. Write a new metadata.yaml file based on the one described above.
  5. Create another tarball containing that metadata.yaml file.
  6. Import those two tarballs as a LXD image with:
    lxc image import <metadata tarball> <rootfs tarball> --alias some-name

You will probably need to go through this a few times before everything works, tweaking things here and there, possibly adding some templates and properties.

Publishing your images

All LXD daemons act as image servers. Unless told otherwise all images loaded in the image store are marked as private and so only trusted clients can retrieve those images, but should you want to make a public image server, all you have to do is tag a few images as public and make sure you LXD daemon is listening to the network.

Just running a public LXD server

The easiest way to share LXD images is to run a publicly visible LXD daemon.

You typically do that by running:

lxc config set core.https_address "[::]:8443"

Remote users can then add your server as a public image server with:

lxc remote add <some name> <IP or DNS> --public

They can then use it just as they would any of the default image servers. As the remote server was added with “–public”, no authentication is required and the client is restricted to images which have themselves been marked as public.

To change what images are public, just “lxc image edit” them and set the public flag to true.

Use a static web server

As mentioned above, “lxc image import” supports downloading from a static http server. The requirements are basically:

  • The server must support HTTPs with a valid certificate, TLS1.2 and EC ciphers
  • When hitting the URL provided to “lxc image import”, the server must return an answer including the LXD-Image-Hash and LXD-Image-URL HTTP headers

If you want to make this dynamic, you can have your server look for the LXD-Server-Architectures and LXD-Server-Version HTTP headers which LXD will provide when fetching the image. This allows you to return the right image for the server’s architecture.

Build a simplestreams server

The “ubuntu:” and “ubuntu-daily:” remotes aren’t using the LXD protocol (“images:” is), those are instead using a different protocol called simplestreams.

simplestreams is basically an image server description format, using JSON to describe a list of products and files related to those products.

It is used by a variety of tools like OpenStack, Juju, MAAS, … to find, download or mirror system images and LXD supports it as a native protocol for image retrieval.

While certainly not the easiest way to start providing LXD images, it may be worth considering if your images can also be used by some of those other tools.

More information can be found here.


I hope this gave you a good idea of how LXD manages its images and how to build and distribute your own. The ability to have the exact same image easily available bit for bit on a bunch of globally distributed system is a big step up from the old LXC days and leads the way to more reproducible infrastructure.

Extra information

The main LXD website is at: https://linuxcontainers.org/lxd
Development happens on Github at: https://github.com/lxc/lxd
Mailing-list support happens on: https://lists.linuxcontainers.org
IRC support happens in: #lxcontainers on irc.freenode.net

And if you don’t want or can’t install LXD on your own machine, you can always try it online instead!

About Stéphane Graber

Project leader of Linux Containers, Linux hacker, Ubuntu core developer, conference organizer and speaker.
This entry was posted in Canonical voices, LXD, Planet Ubuntu and tagged . Bookmark the permalink.

26 Responses to LXD 2.0: Image management [5/12]

  1. Antoine says:

    If I understand the “Manually building an image” paragraph correctly, this also allows migrating a lxc 1.0 container into a lxd 2.0 image?

  2. Igor says:

    2 questions:
    1) What are those ‘c[1-7]’ parameters in ‘lxc launch’ command?
    2) “Unless told otherwise all images loaded in the image store are marked as private and so only trusted clients can retrieve those images”:
    So, how can I make some server trusted?

    1. 1) The c[1-7] are container names.
      2) It means that by default your local LXD will not let anyone on your network freely retrieve the images in its store. If you want to change that for a given image, you can “lxc image edit” it and flip the public flag to true, or when importing or copying an image, pass –public.

      1. Igor says:

        1) Still don’t understand. What do you mean by containers? Do you mean, that it will create a name for the container, instead of something, like: ‘unmarrying-whitney’?
        2) No, I didn’t mean to make it public. I thought, that you were saying in that sentence, that “trusted” clients can access private images. So I wanted to know how to just make clients “trusted”, without making images public.

        1. 1) Yes, those names are used instead of the randomly assigned ones, it’s a bit more convenient when writing articles as that means that everyone following the instructions will get the same result.
          2) Your local client is always trusted, remote clients are trusted if they had their certificate imported in the LXD trust store or if they provided the trust password. A remote client can add your server with “lxc remote add –public” in which case they will not be prompted for the trust password and will only be able to pull public images from your server.

  3. Alex says:

    I really love these posts and find LXD really interesting, but there are a couple of things I just don’t get, even after days of googling.

    1. Is there any way to export an image as a split tarball so it can be used without LXD? Or would that just be the same as putting the contents of rootfs from the into a tarball on its own?

    2. The default Xenial image from linuxcontainers.org seems to be working perfectly together with Proxmox VE, but when I try to modify it like described in this post it will no longer function with Proxmox VE (other format), and what I mentioned in question 1 doesn’t work either. Is there any easy way to customize a image and still make sure it works where the default Xenial image from linuxcontainers.org works?

    3. If I want to assign a static public WAN IP to a container on creation, how do I do that? I have created an br0 interface that’s added to the default profile(?) and it seems to be working well, but I cant figure out how to create a container with a specified IP.

    Some of there questions might be stupid, but I really cant find much information on LXD/LXC by googling.

    Keep up the great work you’re doing! 🙂

    1. 1) You are correct, just extract rootfs/ from the unified tarball and that’s the same as the content of the rootfs tarball in a split layout.

      2) LXD doesn’t modify the image itself in any way, so I’m not sure why it stops working for you. It could be some of the changes done by booting or installing stuff into the images that are confusing proxmox.

      3) You’re apparently using the images from images.linuxcontainers.org, those don’t have cloud-init installed so your only real way to push data inside them is with:
      lxc init images:ubuntu/xenial/amd64 container-name
      lxc file push /some/path/on/host container-name/some/path/in/container
      lxc start container-name

      If building your own images, you could modify the template for /etc/network/interfaces and have it use some container configuration variables as its input.

      1. Alex says:

        Ok, thank you so much for clearing that up for me and pointing me in the right direction, I really appreciate it. 🙂

  4. andrea says:

    Dear Stephane,

    is there any way to “clone” a physical linux server (debian jessy) to a container image?
    I could not find any info on the Internet…

    Thank you


    1. a says:

      The process is described abobe, yet it may seem a bit complex

      1. Create a tarball with the whole root filesystem (you have to boot the source physical computer from a live dvd and mount the drives at their normal location correctly).

      Live backup of a running system is possible, yet outside of the scope of this article.

      2. Create the metadata.yaml based on the one described above and archive it into a tarball

      3. Import into lxc
      lxc image import

  5. Anthony K says:

    I’ve had an issue with one LXC image when trying to install packages. The image in question had a hash of 51eb1b0217dc (can’t find it now in the images listing). Is it not safe to assume that containers launched from images: namespace are unsafe?

    Since I’m already here, when I list images and on the alias it says
    ubuntu/xenial (3 more)
    How can I see those (3 more) images?


  6. Anthony K says:

    OK – Nevermind – Figured out how to see additional (3 more) images.

    I guess for the query about the images: namespace, I’ll just get from Ubuntu and ignore all others.


  7. Dan says:

    Great work on this series, Stéphane. I’ve been following it closely.

    I’ve consistently received permission errors when performing “lxd file push”, “lxd file pull”, and now “lxd export” operations. For example:

    error: open d01ccc911c914f6a3f7899b7c8d68b451201ae6eb74c9a885749a0557e7dad37.tar.gz: permission denied

    I’ve been able to work around the “lxd file” issues by using rsh, but the export command has me baffled. There’s not enough info in the error to point me in any particular direction.

    1. Patrick Goetz says:

      Are you in the LXD group?

  8. Dinusha Dilanka says:

    How can i import image file like Cent-OS-7.img to container.

  9. AB says:

    I have a custom linux os built from source (for ARM arch) and i want to distribute it as a base image to few folks. how do i do it?

    Those who get it, will build the app containers of their choice using my linux os base image (and LXD) and we all will run these app containers on a machine which will host our custom linux.

  10. Hi:

    I would to re-secure access between LAN LXD servers. I have previously connected two LXD servers so that I now regularly do things like:

    user@server1:~$ lxc copy container server2:container
    user@server1:~$ lxc exec server2:container bash
    user@server1:~$ lxc {stop/start/delete} etc…

    It works great. Maybe too great…

    How can I force it such that every session that server1: contacts server2: (and vice-versa) that they have to re-authenticate. I want to do this because in the event that one of my servers get compromised, my non-root user account effectively gives access to containers on both my servers, which doubles the damage potential (I like to worry, so it seems…).

    Do I have to delete some of the keys in ~.config/lxc ? (If so, which do you recommend)?

    Side note: I am absolutely LOVING LXD. You have saved me many many hours of wastefully rebuilding servers after I destroy them to where I don’t know what I am doing: lxc restore gives me the power of god (ok, maybe not, but you get my drift). THANK YOU!


  11. Craig Hicks says:

    It’s great for authentication purposes that we can download by fingerprint. This is especially important for new users who no little about what are trustworthy sources of images.

    Unfortunately, it’s not clear where to find trustworthy sources, or how a fingerprint of an already downloaded image’s fingerprint can be authenticated. For example I downloaded a Debian image on Ubuntu, and it appears to come from https://us.images.linuxcontainers.org/,
    but that page states clearly the images are not “official”. Debian’s [page on lxc](https://wiki.debian.org/LXC) refers back to linuxcontainers.

    There’s a [sub-site of linuxcontainers, Jenkins, ](https://jenkins.linuxcontainers.org/) which “looks” authoritative, but offers no advice on how to an “official” download or verify a fingerprint number.

    I’m guessing most people would just trust linuxcontainers, because they have no choice or just don’t know how to verify (like me).

  12. Craig Hicks says:

    Ok, following different instruction I got something that looks authenticated, although there’s description of how to double check that.
    lxc-create -t download -n u1 — -d debian -r stretch -a amd64
    gave back output including
    Setting up the GPG keyring

    Previously I had downloaded via
    lxc launch images:debian/stretch mystretch
    and there was no indication of authentication going on.

  13. Craig Hicks says:

    It seems the image created via
    lxc launch …
    can be viewed via
    lxc image list
    but it doesn’t show the image created via
    lxc-create …
    To see that I need to use

    Both `lcx` and `lcx-create` are version 3.0.3.

    I installed on Ubuntu, first using
    apt install lxc
    which only gave the `lxc` command. Since some manuals suggest using `lxc-create` I installed
    apt install lxc-utils

    I’m guessing `lxc` installed `lxd`, and `lxc-installs` installed some tools lower level than `lxd`. But only `lxc-create` gave any indication that a download might have been authenticated.

    Very confusing.

  14. pooja kulal says:

    1) lxc config set core.https_address “[::]:8443”- what does core.https_address “[::]:8443” mean.
    2) how can i use the application present inside the lxd container(from the imported image )?
    3)how can i get these in the lxdui(facing problem with installation of lxdui)?

  15. Pete Dosch says:

    After setting up a public image server, using it, and then using “lxc remote remove” to remove it from the client, and “lxc config unset core.https_address” on the image server, I still see traffic on port 8443 from the system that was the client to the system that was the server.
    How do I stop that from happening?

  16. Pete Dosch says:

    If this is a duplicate post, I apologize. I couldn’t tell if the first one was successful or not.

    After setting up a public image server, using it, and then using “lxc remote remove” to remove it from the client, and “lxc config unset core.https_address” on the image server, I still see traffic on port 8443 from the system that was the client to the system that was the server.

    How do I stop that from happening?

  17. Hans Kloss says:

    This may be of use for some as spent better part of a day on searching for a reason. There appear to be many bugs and mails in different blogs relating to image copy where there is a proxy behind lxd and place you copy the image from.
    I have tried different things and eventually after some trials on ubuntu18 and lxd 3.0.3 I got to change the proxy settings in a file in /etc/systemd/system/lxd.system.d/
    I got things to work only after the file contained the following:

    Please note that https proxy uses http protocol here! The slash at the end is a must too!

    After the change I have to do the following:
    systemctl daemon-reload
    systemctl restart lxd
    The advice I got is to use ‘systemctl edit lxd’ but for some reason vi is easier to use especially if file already exists.

    Along the way I also met an advice that the folder has to contain something so when the need for variables ceases to exist remove the folder too or lxd stops working. This I have not verified tho.

    As for things I have tried:
    setting core.proxy… settings with lxc config set
    I tried also environement.proxy… and just proxy_… variable names to no avail.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.