Issue when moving a volume to another project

pmarini · May 9, 2023, 8:55pm

The whole purpose is to move all the containers in project A to project B because I don’t want anymore that the scope of volumes, networks and other resources is private to the project. Project A was created as such in the beginning (features.*: true) while project B has been created with features.*: false.

I did the following:


$ lxc storage volume move pool01/vol01 pool01/vol01 --project A --target-project B

The operation is successful:

Then:


$ lxc storage volume list pool01 --project B
$ lxc storage volume list pool01 --all-projects
+-----------------+-----------+-----------------+------------------------------------------------+--------------+---------+
|     PROJECT     |   TYPE    |      NAME       |                  DESCRIPTION                   | CONTENT-TYPE | USED BY |
+-----------------+-----------+-----------------+------------------------------------------------+--------------+---------+
|  B              | custom    | vol01           | my description                                 | filesystem   | 0       |
+-----------------+-----------+-----------------+------------------------------------------------+--------------+---------+

$ sudo zfs list -r pool01
NAME                                                             USED  AVAIL     REFER  MOUNTPOINT
[...]
pool01/custom/B_vol01                                             0B   4.66G     67.9M  legacy
[...]
pool01/deleted/custom/225b0a28-4f9b-4e55-bb86-3d849aa91e6e      67.9M  4.59G     67.9M  legacy
[...]

So it seems my volume is trashed and visible only with the --all-projects flag.

I’m on 5.13

Did I do anything wrong? How can I restore my volume?

tomp · May 12, 2023, 2:52pm

Thanks for reporting this. You’ve found a bug.

I’ve reproduced it, and the issue is that when the storage volume is moved to a project that has features.storage.volumes=false it incorrectly is recorded as being associated with the target project, rather than being associated (and renamed on the underlying storage pool) to being associated with the default project.

Because moving a storage volume to a project which doesn’t have storage volume support shouldn’t be allowed really, and instead you effectively need/want to move it to the default project.

Let me see if I can help you with a DB query to fix this…

tomp · May 12, 2023, 2:57pm

First run this query to get the volume ID:

lxd sql global 'select storage_volumes.* from storage_volumes join projects on projects.id = storage_volumes.project_id where storage_volumes.name = "vol01" and projects.name == "B"'
+------+------+-----------------+---------+------+-------------+------------+--------------+--------------------------------+
|  id  | name | storage_pool_id | node_id | type | description | project_id | content_type |         creation_date          |
+------+------+-----------------+---------+------+-------------+------------+--------------+--------------------------------+
| nnnn | vol01  | 2               | 1       | 2    |             | 22         | 0            | 2023-05-12T14:48:06.639327778Z |
+------+------+-----------------+---------+------+-------------+------------+--------------+--------------------------------+

Then move it to the default project:

lxd sql global 'update storage_volumes set project_id = 1 where id = nnnn'

We then also need to rename the underlying storage volume to the default project:

sudo zfs rename pool01/custom/B_vol01 pool01/custom/default_vol01

tomp · May 12, 2023, 3:08pm

I’ve opened a bug for this:

github.com/lxc/lxd

Moving a storage volume to a project with features.storage.volumes=false does not move it to the default project

opened 03:07PM - 12 May 23 UTC

tomponline

Bug

Moving a custom storage volume to a project that doesn't have `features.storage.…volumes=true` shouldn't be allowed. ``` lxc project create a -c features.storage.volumes=true lxc project create b -c features.storage.volumes=false lxc storage volume create zfs vol1 --project=a lxc storage volume list zfs --project=a +--------+------+-------------+--------------+---------+ | TYPE | NAME | DESCRIPTION | CONTENT-TYPE | USED BY | +--------+------+-------------+--------------+---------+ | custom | vol1 | | filesystem | 0 | +--------+------+-------------+--------------+---------+ sudo zfs list zfs/custom/a_vol1 NAME USED AVAIL REFER MOUNTPOINT zfs/custom/a_vol1 24K 25.2G 24K legacy ``` ``` lxc storage volume move zfs/vol1 zfs/vol1 --project=a --target-project=b Storage volume moved successfully! ``` So far seems fine, but oh no, where has the volume gone: ``` lxc storage volume list zfs --project=b +------+------+-------------+--------------+---------+ | TYPE | NAME | DESCRIPTION | CONTENT-TYPE | USED BY | +------+------+-------------+--------------+---------+ ``` Its still there, but associated to the wrong project: ``` lxc storage volume list zfs --all-projects +---------+-----------+------------------------------------------------------------------+-------------+--------------+---------+ | PROJECT | TYPE | NAME | DESCRIPTION | CONTENT-TYPE | USED BY | +---------+-----------+------------------------------------------------------------------+-------------+--------------+---------+ | b | custom | vol1 | | filesystem | 0 | +---------+-----------+------------------------------------------------------------------+-------------+--------------+---------+ ``` And its still on disk and has been renamed to be part of project b, but project b uses volumes from project default because of `features.storage.volumes=false`. ``` sudo zfs list zfs/custom/b_vol1 NAME USED AVAIL REFER MOUNTPOINT zfs/custom/b_vol1 1K 25.2G 24K legacy ``` I believe the desired behaviour should be ether: - Reject the move because project b doesn't have features.storage.volumes=true. - Allow the move but actually move it to the default project. Reported from https://discuss.linuxcontainers.org/t/issue-when-moving-a-volume-to-another-project/17127