Error: Failed instance creation: Error transferring instance data: Unable to connect to:

Had problems with this command a while back.

Installed 2 LXD servers with public ip.
Server 1 with for example
Server 2 with for example

On server 1 (source):

lxc config set core.https_address

On server 2 (destination)

Open port 8443 TCP and allow from

On server 1 (source):

lxc remote add server2
lxc copy container server2:container
Error: Failed instance creation: Error transferring instance data: Unable to connect to:

| server2 | | lxd | tls | NO | NO | NO |

Any idea?

snap list
Name Version Rev Tracking Publisher Notes
core18 20211215 2284 latest/stable canonicalâś“ base
core20 20211129 1270 latest/stable canonicalâś“ base
lxd 4.22 22292 latest/stable canonicalâś“ -
snapd 2.54.2 14549 latest/stable canonicalâś“ snapd

The way migration works out of the box is that your CLI tool will tell the destination to connect to the source. Your firewall rule looks like it may be backward for that flow and so not allow the connection.

You can reverse the direction with --mode=push or even make everything go through the CLI (which is almost always guaranteed to work, but can be slower) with --mode=relay.

Ah, correct. There was also a firewall in between! I thought the method was modified, but this is still the same. Thanks Stéphane!

What about copying containers over the internet and encryption? I’m in the process of moving servers. After the move, there is no longer an internal network for containers. Is a copy or move encrypted?

Yep, all LXD communication whether it’s between your CLI and a server or server to server is done over LXD’s TLS API (port 8443).

During the migration, the client ask the source server to create a websocket migration operation, this comes with 3 different sockets each with their own secret. The client then posts to the target server and gives it, the URL of the source server, the TLS certificate to expect from the source server (preventing MITM attacks) and the secrets to use to access the source instance.

That target server can then connect to the source over HTTPS, can validate the certificate and then using those secrets, connect to the migration API for that specific instance. The target server never has access to anything other than the instance that’s being transferred and all communications between the two servers happen over that HTTPS connection.

1 Like