Copy instance with dependent volume to different storage pool

Incus
1

I’m testing the new dependent volumes introduced with 6.23 but fail to copy to a host having a different pool name:

incus copy incus-2:container-1 container-1 --mode pull --refresh --storage zpool1 -d data,pool=zpool1 --project default --target-project=default
Error: Failed instance creation: Error transferring instance data: Failed migration on target: Failed to negotiate migration types for dependent volumes: Failed loading storage pool: Storage pool not found

The pool is definitely there on the target:

incus storage list zpool1 -c ns
+--------+---------+
|  NAME  |  STATE  |
+--------+---------+
| zpool1 | CREATED |
+--------+---------+

Am I doing something wrong, or should I file a bug report?

2

When I first copy the custom volume manually like:

incus storage volume copy $h:ssd1/container-data zpool1/container-data --refresh

the previous container copy command works as expected, so I think there is some chicken/egg issue in the copy of dependent volumes?

3

One restriction I found for dependent volumes is that they can not be shared with other containers like we did with custom volumes before not having the dependent flag.
Trying to add a volume which is defined as dependent to another container:

Config parsing error: Failed add validation for device "data": Cannot add dependent custom storage block volume to more than one instance

We use this as a feature for test systems mounting the prod data read-only in shared mode without the need to do a copy

This means we should do now a volume copy for dependent volumes instead of a read-only shared mount.

4

We’ve got @presztak currently working on two things that are related to you issue:

  1. Making it so an instance copy will also create copies of all dependent volumes attached to it.
  2. Allowing for -d overrides on copy/move calls to allow overriding the pool. So basically incus move my-inst target: --storage foo -d my-vol,pool=bar should then work
1 Like
5

great - thanks!