Backups using --optimized-storage require --storage=name when importing? (Error: Storage pool not found: Storage pool not found)

LXD Support
1

Intuitively, when I export a container from one computer and import the resulting file into LXD on another computer, I obviously am wanting to import that file into the LXD server as it is setup on the second computer. Or, in other words, the clear intent is to import the container-filename.tar.gz into the second computer on LXD however LXD is setup on that second system.

However, it doesn’t seem to work quite that way.

I ran into an issue tonight where a container on my laptop which I exported, rsynced to a server, then imported on that server resulted in the following error:

user@server:/zfs$ sudo lxc import u22-blank.tar.gz
Importing instance: 100% (575.71MB/s)Error: Storage pool not found: Storage pool not found

Why would the import process not be able to find the storage pool on the LXD server that I was importing into? The storage pool exists and seems to be functioning properly, but the import process cannot seem to find it. To me that doesn’t make sense.

After some searching, I found the --storage option and took a bit of trial and error, as well as looking back at my notes, to figure out what the specific issue was in my case here. The --storage option isn’t even asking for the actual zfs dataset being used for LXD on the second computer, which in this case is serverpool/lxd. Instead, --storage needs the name that was used during ‘lxd init’ for the following part:

Name of the new storage pool [default=default]:

Turns out, on my laptop I left that setting above as the default and on the server I used ‘lxd’ for the name. So, importing with --storage=lxd got the imports working.

But still, shouldn’t the lxc import process be able to determine without user input that the LXD server being imported into was configured with whatever name was used during the “Name of the new storage pool [default=default]:” init part?

Something else I found out is that --storage=name is needed also only when the export is done using the --optimized-storage flag because without using that flag the filename.tar.gz imported just fine without needing --storage=name.

Just seems odd to me.

The way I think of it, metaphorically, is I’m taking something out of a box and putting it into another box. But the process wants to know what I named the second box. And I’m thinking, “Why does it even matter what I named the box? Just go inside the box like I am instructing.”

I’m assuming that had I used the same name for “Name of the new storage pool [default=default]:” on both my laptop and the server that the imports would have worked without needing the extra --storage=name part, but I did not test this so not certain yet.

And I’m guessing there’s probably a good reason why the name part from “Name of the new storage pool [default=default]:” is required to be specified with --storage=name in this situation.

Maybe this is an opportunity for me to learn a bit more about LXD, if anyone feels like explaining why it works this way.

2

I agree that if you have only one storage pool, the assumption that this is the one that should be used is straight-forward.

But your new server might have more than one storage pool. If you don’t specify which pool to use, the import will use the storage pool with the same name - so yes, if you had a default pool on the new server, this one would have been used. But if you want to import into a pool with a different name (like lxd in your case), you have to specify which. LXD cannot guess which of your storage pools is your “default” - and if you have only one but used a different name, there might be a reason for that (for example, you want to avoid accidentally using it), so you’ll need to explicitly say which pool to use.

3

It does make sense to require specifying the pool name when importing into a multi-pool setup.

But when importing into a LXD server with only a single pool, the pool name is basically irrelevant as there is only one to choose from. That’s probably why it seemed a bit odd to me, also considering that I’ve only ever used LXD with a single pool.

The error message, instead of “Error: Storage pool not found: Storage pool not found” probably should have been more like “Error: Storage pool not found. Must specify storage pool name with --storage=name”

4

This sounds interesting. What were the pool types of the exported pool vs the target pool?

I wonder if this is a misleading error where the optimized export format wasn’t compatible with the target import pool (they have to match).

5

Sorry for the delayed response. Both pool types were the same. In fact, everything was exactly the same except for the two lxd init settings below:

Name of the new storage pool [default=default]:
Name of the existing ZFS pool or dataset:

I was exporting from my laptop and importing into a remote server.

On my laptop the “Name of the new storage pool” was the default. On the remote server I had it set to “lxd”

For the “Name of the existing ZFS pool or dataset:” I used ZFS datasets for both my laptop & the remote server. rpool/lxd on my laptop and serverpool/lxd on the server.

Other than that I believe everything else was configured the same during the lxd init process.

I’m not sure if the optimized export format wasn’t compatible. It just required using --storage=lxd at the end of my import command. Adding that on enabled the imports to work.

Also not sure if the error message should be considered misleading. In my case I just wasn’t sure what to do, so took a bit to figure out. If the error message was more like the following I would probably have figured it out sooner: “Error: Storage pool not found. Must specify storage pool name with --storage=name” Or, since I only had one storage pool name set on my server, the error message could have specified it with --storage=lxd as that was the name I used.