Closed chong601 closed 4 years ago
Yes, that's normal. lxd import
only knows about instances, it doesn't know about custom storage volumes, networks, images, ...
Did that lxd import
attempt re-create the storage pool itself (as in visible in lxc storage list
)?
The storage pool containing the container did get recreated, but not the other one (secondary-fio-cache)
+-----------------------+-------------+--------+--------------------------------+---------+
| NAME | DESCRIPTION | DRIVER | SOURCE | USED BY |
+-----------------------+-------------+--------+--------------------------------+---------+
| secondary-fio-storage | | zfs | secondary-fio-storage/lxd-area | 0 |
+-----------------------+-------------+--------+--------------------------------+---------+
Yeah, that makes sense, the instance wasn't on the cache one so it didn't get re-created. Is that secondary disk on the instance on the cache pool or on the storage pool?
Here's the layout of the container
secondary-fio-cache:
- secondary-fio-cache/lxd-area/custom/osm-postgres-cache
mounted on /var/snap/lxd/common/lxd/storage-pools/secondary-fio-cache/custom/osm-postgres-cache
- secondary-fio-cache/lxd-area/custom/osm-postgres-index
mounted on /var/snap/lxd/common/lxd/storage-pools/secondary-fio-cache/custom/osm-postgres-index
secondary-fio-storage:
- secondary-fio-storage/lxd-area/containers/osm-postgres
mounted on /var/snap/lxd/common/lxd/storage-pools/secondary-fio-storage/containers/osm-postgres
- secondary-fio-storage/lxd-area/custom/osm-postgres-db-storage
mounted on /var/snap/lxd/common/lxd/storage-pools/secondary-fio-storage/custom/osm-postgres-db-storage
(This is based on the zfs list
output)
Ok, so yeah, there's no way to automatically import this.
Your best bet is to either restore a partial database backup or to manually re-add secondary-fio-cache
to the database as well as manually re-adding the custom volumes to the storage_volumes
table.
Once those are sorted, the containers themselves should import just fine.
I did put import/export infrastructure for custom storage volumes on our backlog, so in the near future there should be a better way to both handle disaster recovery for those as well as export them as tarballs similar to what containers support today.
Ah well, I guess I have to pray that the snapshotted snap data for LXD are salvagable (this server got hit by issue #6913 and recently recovered by nuking everything) and planned to just reimport, but that doesn't work as lxd init --preseed
doesn't allow creating storage pools with existing datasets.
The main take-away of this issue is this:
lxd init --preseed
does not allow non-interactive for disaster recovery (cannot recreate pools with existing data inside)--preseed
doesn't accept file name as argument, you have to pass in using stdin (can create a new GitHub issue on this if needed)This issue is okay to close as of now.
In this case, a simple snap revert lxd
would have gotten you on the previous working revision, that's usually worth a shot when something like this happen.
If something weird happens with the database, there's also always the option to revert it, either to the previous upgrade state (that's what the .bak
files are) or by reverting just a few segments in the current database.
It's incredibly rare (as in, I've never seen it) that we can't recover a database. We've usually been able to provide a pretty quick fix or at least one of those revert methods usually work.
Required information
Issue description
As a preparation to avoid issue #6913, I have decided to downgrade from latest LXD to the 3.20. However, when I attempted to import the existing container after uninstalling LXD 3.21 and installing LXD 3.20, I get the following error:
Error: Create container: Invalid devices: Device validation failed "osm-postgres-index": The "secondary-fio-cache" storage pool doesn't exist
Attempted fixes:
lxd init --preseed
and used the LXD YAML dump created earlier: failed because the dataset used is not emptyOnly alternative is to lose out the dataset and recreate from scratch.
Let me know if require more information.
Steps to reproduce
snap remove lxd
snap install lxd --channel=3.20/stable
sudo lxd import <container>
Information to attach
location: none metadata: context: {} level: dbug message: 'New event listener: 2707f803-1c1d-41a5-9644-194e4c0a5b97' timestamp: "2020-02-21T21:35:37.914805666+08:00" type: logging
location: none metadata: context: ip: '@' method: GET url: /1.0 user: "" level: dbug message: Handling timestamp: "2020-02-21T21:35:56.24631439+08:00" type: logging
location: none metadata: context: ip: '@' method: POST url: /internal/containers user: "" level: dbug message: Handling timestamp: "2020-02-21T21:35:56.249043934+08:00" type: logging
location: none metadata: context: {} level: dbug message: 'Database error: &errors.errorString{s:"No such object"}' timestamp: "2020-02-21T21:35:56.251948143+08:00" type: logging