LXD Image Updates

LXD is sweet. To create a ubuntu xenial container, just do

lxc launch ubuntu:xenial x1

The remote xenial image will be automatically fetched on the first use, and cached for future uses. Nifty. Hmm… but what then?

There are three server settings which guide how images are treated after their initial use. And setting these can make the difference between frequent higher bandwidth use and more uptodate images.

The discussion will be eased if we define a term: a ‘cached’ image is one which is created implicitly as part of a container creation. I.e. the first time that you do

lxc launch ubuntu:trusty t1

lxd will fetch the ubuntu:trusty image, implicitly creating a cached copy on the target remote. In contrast, you can explicitly create a non-cached image using

lxc image copy ubuntu:wily local: –alias wily

As you might expect, these two images are treated a bit differently. The first is cached for a while to save on future bandwidth, but it’s a second class citizen compared to the second image, which the user explicitly requested.

With that in mind, as I said earlier, there are three configuration settings which guide image behavior.

First there is the cached image auto update setting,

lxc config set images.auto_update_cached true

Any cached images which are created while this is set to true will be auto-updated. Note that setting this to true after creating a container will not change that pre-existing cached image’s auto update setting.

For explicitly created images, you can instead specify auto-update manually using

lxc image copy ubuntu:wily local: –alias wily –auto-update

The second setting is remote_cache_expiry:

lxc config set images.remote_cache_expiry 1

This specifies, in days, how long an unused cached image is kept in the cache before it is flushed. If this value is not specified, then it defaults to 10 days. Note that explicitly copied images are not expired.

Finally, auto_update_interval specifies how many hours should pass between lxd’s checks for whether a cached image should be updated. Setting this value to 0 disables the checks. So if you find yourself temporarily on a slow, expensive, 3G router, you may want to

lxc config set images.auto_update_interval 0

to save yourself from accidentally downloading a few hundred megs or more of updated image contents. On the other hand, when back at the datacenter, you might want to

lxc config set images.auto_update_interval 1

to keep as in sync as possible.

This entry was posted in Uncategorized. Bookmark the permalink.

7 Responses to LXD Image Updates

  1. Jeromy Streets says:

    This is really awesome! Any chance of being able to schedule the cache sync? My home uses satellite internet which has a 250MB/day limit, but 3 hours every night is unlimited (that is when my apt-mirror runs). I would love to be able to do a local LXD image cache, as well.

    • s3hh says:

      I’ve looked at those plans 🙂

      Currently there is no built-in way to schedule this. what I would do would be to use cron to schedule a command at the start of the unlimited window to set the auto_update_interval to 1, then at the end of the window set it to 0.

      • Jeromy Streets says:

        After I get my servers and laptops upgraded to Xenial (probably this weekend) I’ll give that, or something like it a try. I saw in https://www.stgraber.org/2016/03/30/lxd-2-0-image-management-512/ that there is a way to create a “poor man’s image server”, so between writing a tiny Go application and scheduling a Cron job, I can probably get something up and running. I’m assuming this update setting would also work for the aforementioned image server implementation? (assuming it would be to keep my laptops up-to-date with my image server, not the image server keeping up-to-date with the official images)

    • If you or anyone is still looking for a solution, as of now (with lxd 3.0.3), running the command `lxc image refresh image_name` would update a particular image, manually. Easy to schedule through cron.

  2. s3hh says:

    Sorry, which go application are you going to write? Note that you can use a regular lxd instance on a public port as an image server. Images which you publish with the –public flag will be visible by anyone who can reach the lxd server’s port.

    • halverneus says:

      I was going to use the Go application as an image server, but that is a great point! My biggest concern is being able to kill the image download if it takes too long (I kill wget and apt-mirror minutes before the unlimited period ends). I know LXD can fetch it’s own images, but my use case (admittedly not typical) seems to require a bit more granular control, so I might need to manually fetch the images, but let LXD serve them. I’ll know more this weekend when I actually start trying some of this stuff out.

  3. Pingback: Things I Didn't Know - Virtual Box Overload: We Moved To LXD - Part 2 - ionCube Blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s