I've installed lxd on two ubuntu hosts that can only communicate via an intermediate server (on which I don't have su privileges). I've created a container on my localhost and now wish to load the container on the remote server.

I consulted the basic.sh test script in the lxc/lxd repo to confirm that I'm using the correct approach (I discovered along the way that I was misunderstanding images vs containers).

I've created a container test on my localhost, installed all the necessary goodies within it, stopped it, published it, and executed the following commands:

lxc image export test

This gives me a tarball 42cf01c53cb9e...83e3c48.tar.gz (shortened here), as described in the documentation (I'm running lxc and lxd versions 2.0.0.beta3). Attempting to import that image on the same host via

lxc image import 42cf01c53cb9e...83e3c48.tar.gz --alias testimage

yields the error:

exit status 2 (tar: metadata.yaml: Not found in archive)

The basic.sh script leads me to believe that I was following the correct route though (except for the tar.gz vs tar.xz descrepancY). I'm able to export standard images and obtain an .xz file (when I obtain them using lxd-images). For example,

lxd-images import ubuntu --alias ubuntu
lxc image export ubuntu

produces a meta-ubuntu...tar.xz and ubuntu...tar.xz file, which can be imported (on a different server) with

lxc image import meta...tar.xz rootfs ubuntu...tar.xz --alias imported_ubuntu

How do I copy containers between hosts?


Edit: I've investigated further and have published my test container, which creates an image of it. Then I get the .gz file though (without the meta-data) when I export it. If I hijack metadata from the original image, then I can't get the container started although import no longer crashes on me --- I obviously don't know what I'm doing. Pulling the image over to a second host using lxd's remote: approach (after adding the host using the lxd config) does not result in it appearing in lxc images list.


The later release (non-beta) of lxd (v2.0) seems to have resolved my issue. The steps, which may be found in the excellent documentation here, are:

  1. Publish an image (without stopping the container) on host A;

    $ lxc publish --force container_name --alias image_name
    Container published with fingerprint: d2fd708361...a125d0d5885
  2. Export the image to a file;

    $ lxc image export image_name 
    Output is in dd2fd708361...a125d0d5885.tar.gz
  3. Copy the file to host B, and import;

    $ lxc image import dd2fd708361...a125d0d5885.tar.gz --alias image_name
    Transferring image: 100%
  4. Launch the container (from the image) on host B;

    $ lxc launch image_name container_name
    Creating container_name
    Starting container_name

In some instances the publish command may lead to a split xz tar-ball --- but both formats are supported. Simply import the meta-data and rootfs components with

    lxc image import <metadata tarball> <rootfs tarball> --alias image_name
  • 1
    The --force option actually does stop the container. It just causes it to restart after the process is done, as noted by @Levi's answer below.
    – code_dredd
    May 10 '18 at 23:01
  • 1
    Also, you could add a remote and then use the lxc image copy ... command to move the images around that way, which would be a lot easier than exporting, etc. For example: lxc image copy --alias=<your-alias> --auto-update <your-remote>:<image-to-move> local: will download the image to the system you ran the command from (i.e. your backup location, etc)
    – code_dredd
    May 10 '18 at 23:14

0_0 posted a good answer but I'm not allowed to comment just yet so I will just post his answer modified.

First off lxc publish --force container_name --alias image_name will stop the container and restart it but the OP did not want the container to be stopped.

You should make a snapshot first with lxc snapshot container_name snapshot_name

Then you can publish the image with lxc publish container_name/snapshot_name --alias image_name

Now just follow the rest of his instructions.

  • 1
    Thanks! I see -f, --force Stop the container if currently running in the help for lxc publish; don't know what I was thinking.
    – 0_0
    May 11 '18 at 13:23

If you have socat or netcat or gcc / python / perl / anything that can listen on tcp, then you could also listen on the intermediate server and forward the connection to the other host

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.