Export and import to a different host

Scenario: I have exported a container from one host and wish to import to a different host (in difficult geographic locations and no network between them).
I have exported the container to portable storage and tried to import but ran into several problems.
The configuration of the target host is different, including the source host uses zfs and the target btrfs.

What is the best procedure to import the container?

I have already run into some ¨failed to import" issues including:

  • Unknown configuration key: volatile.vm.definition
  • Unknown configuration key: volatile.cloud-init.instance-id

As a workaround I removed the entries from within the backup/index.yaml and backup/virtual-machine/backup.yaml files within the relevant .tgz.

Now I have the issue of:

Error: Failed importing backup: Failed creating instance record: Failed initializing instance: Invalid config: No uid/gid allocation configured. In this mode, only privileged containers are supported

Is there a way I can import as privileged container?
If the source container was privileged, why is this not already configured in the export?
I anticipate perhaps my next problem could be the storage configurations are different.
How would one go about specifying the new target parameters for the import?

The storage pool can be overridden during import so that shouldn’t be a problem.
What exactly are you importing this backup into?

The volatile.vm.defintiion being present suggests that this is coming from a very recent Incus version as that key was introduced in 6.11. However volatile.cloud-init.instance-id has been around for a long time, in fact, as far as I know, this has always been supported by Incus.

Are you trying to import that Incus VM export into a LXD server or something?

Thanks for the response.
Please would you give an example of the override at import. It was not obvious to me from the import documentation or --help
The source would have been a recent incus build on Debian 12 Bookworm. Apologies I do not have access to the exact version.
The target is Fedora 41 (Workstation) incus version 6.8.

incus import --help shows that you can pass --storage POOL to override the storage pool.

stgraber@dakara:~/data/code/lxc/incus (lxc/main)$ git checkout v6.8.0
Note: switching to 'v6.8.0'.
stgraber@dakara:~/data/code/lxc/incus ((HEAD detached at v6.8.0))$ git grep volatile.cloud-init.instance-id internal/instance/config.go 
internal/instance/config.go:    "volatile.cloud-init.instance-id": validate.Optional(validate.IsUUID),
stgraber@dakara:~/data/code/lxc/incus ((HEAD detached at v6.8.0))$ 

So Incus 6.8 did support volatile.cloud-init.instance-id. The error on that config key seems really weird…

In any case, export/import from a newer to an older release of Incus isn’t generally supported.
The same as with incus copy between a newer and older server.

We obviously care about the other direction and can fix issues when they occur there, but when going to an older release, there isn’t a whole lot we can do.

Apologies, yes I now see the --storage in Flags.
I completely understand about not supporting export to older versions.

The fedora package is 6.8.
I removed and built from source to use the latest version.
It appears incusd and the incus client were built. Both show as version 6.11.
I am not 100% all the dependencies were met but there did not appear to be any errors.

Please would you clarify about the install.

As I understand it, there is no sudo group in Fedora but the wheel group is used for admin so I used:
sudo -E PATH=${PATH} LD_LIBRARY_PATH=${LD_LIBRARY_PATH} $(go env GOPATH)/bin/incusd --group wheel
The command does not return, which I assume is correct, as it meant to run as a daemon.

The install did not create the relevant systemd configs.
As per: From source: Install on page: https://linuxcontainers.org/incus/docs/main/installing/

My user is in the wheel and incus-admin groups but there appears to be no socket for the client to use:

incus admin init
Error: Failed to connect to local daemon: Get "http://unix.socket/1.0": dial unix /run/incus/unix.socket: connect: connection refused
incus list
Error: The incus daemon doesn't appear to be started (socket path: /run/incus/unix.socket)

Thank you for any assistance offered.

By default Incus uses /var/lib/incus/unix.socket instead of /run/incus/unix.socket.

Fedora overrides the socket path in both the server and client, but now with your manually built one, you have a client that looks in /run but a server that listens in /var.

You should be able to fix the server side by setting INCUS_SOCKET=/run/incus/unix.socket

Thank you for the clarification regarding the socket. That was indeed the problem.

I confirm the import completed without errors from the Debian 12 (BookWorm) to Fedora 41 incus 6.11, using the original unmodified export file.

There was a problem starting the instance but fixed as below.
There was a problem with the networking but also fixed as below.
In case it is useful, included below are some notes on Fedora packages installed for the build.

Outstanding
I believe the only outstanding issue I need to work on is a working systemd config to make it easier to start incus. I am working through incus/systemd at daily · zabbly/incus · GitHub

Start error: resolved
When I attempt to start the instance: incus start win11dev I ran into this error:

Error: Unable to locate matching firmware: [{Code:/usr/share/OVMF/OVMF_CODE.secboot.fd Vars:/usr/share/OVMF/OVMF_VARS.secboot.fd} {Code:/usr/share/OVMF/OVMF_CODE.secboot.fd Vars:/usr/share/OVMF/OVMF_VARS.fd}]
Try incus info --show-log win11dev for more info

incus info --show-log win11dev showed:

Name: win11dev
Description:
Status: STOPPED
Type: virtual-machine
Architecture: x86_64
Created: 2024/04/08 13:55 CEST
Last Used: 2025/03/20 09:17 CET
Error: open /var/log/incus/win11dev/qemu.log: no such file or directory

This post: Unable to locate matching firmware on Incus 6.5 · Issue #1202 · lxc/incus · GitHub
advised running:

incus config set NAME security.secureboot=false
incus config unset NAME security.secureboot

That fixed the issue.
The instance now runs.

No IPv4 address/firewall issue: resolved
The instance did not have an IPv4 address
As per this guide, Fedora uses firewalld and the recommendation is to have only one firewall so disabling the incus firewall and adding the default profile bridge to firewalld enables access:

#Disable incus firewall on the bridge
incus network set incusbr0 ipv6.firewall false
incus network set incusbr0 ipv4.firewall false
#firewalld: Add the bridge to the trusted zone
sudo firewall-cmd --zone=trusted --change-interface=incusbr0 --permanent
sudo firewall-cmd --reload

Fedora install from source notes
In case this maybe useful, as there is no Fedora instructions in the Install Incus from source How to install Incus - Incus documentation
these were the Fedora packages I used for building incus from source:

sudo dnf install make automake gcc gcc-c++ kernel-devel
sudo dnf install acl attr autoconf  git golang-go libacl-devel libcap-devel lxc-devel sqlite3-dev libtool libudev-devel lz4-devel libuv-devel pkg-config rsync squashfs-tools tar tcl xz ebtables 

Some of the package names are the same as Debian, same or similar (instead of dev, devel).
Some packages I could not find Fedora equivalents but may have already been installed. As I am limited on time I can´t be 100% sure all the above are equivalent or required or if there is something missing. I can only confirm in my case the build appear to complete without error.

There were the storage drivers:
sudo dnf install btrfs-progs ceph-common install lvm2
These I did not find equivalent Fedora packages: thin-provisioning-tools, zfsutils-linux

I did not explore the packages required for the test suite.

These were the packages for QEMU/KVM:
sudo dnf install qemu-kvm libvirt virt-install virt-manager virt-viewer edk2-ovmf swtpm qemu-img guestfs-tools libosinfo tuned

Fedora incus package
As of 2025-04-02 fedora incus packages are 6.8-1