The code comment reads: If the volumeType represents an instance type then check that the volumeConfig doesn't contain any of the instance disk effective override fields (which should not be stored in the database).
From a userās point of view, what worked in v5.2 no longer works in v5.3. I am not sure what problem was being solved and I do not know what I need to change in my environment (storage, profile, container) for the lxc copy command to work.
It will be very helpful to get more background on the problem being solved and steps to remediate.
I rolled lxc back to v5.2 because I have ansible scripts which failed.
If I edit the config to take out the size, it works. But this is the way Iāve limited size of containers in past. Should that be done some other way?
[ken@big-lab ~]$ lxc copy rockylinux8 test
Error: Create instance from copy: Instance disk effective override field āsizeā should not be stored in volume config
Copy Snapshot
[ken@big-lab ~]$ lxc copy rockylinux8/dse-cass-base test
Error: Create instance from copy: Instance disk effective override field āsizeā should not be stored in volume config
Thanksā¦ Iāve been in software development a long time, I understand fixes are usually not released in an ad-hoc manner. If the release ETA is 30+ days, I wonāt hit F5 on my browser every day until then.
We can see the same error message in our logs when trying to start LXD after upgrade from 5.2.1 to 5.3.1. When downgrading LXD back to 5.2.1 everything works fine. None of our volume configs contain keyword āsizeā.
Failed to start the daemon" err="Failed applying patch \"storage_missing_snapshot_records\": Failed applying patch to pool \"default\": Instance disk effective override field \"size\" should not be stored in volume config
Is this a different issue or another symptom of the broken commit discussed here?
Interesting, I suspect this is a related, but different issue, and in this case the check is actually doing the right thing.
Now youāre back on LXD 5.2 (btw there is no such thing as LXD 5.2.1 or LXD 5.3.1) can you run:
sudo lxd sql global "select * from storage_volumes left join storage_volumes_config on storage_volumes_config.storage_volume_id = storage_volumes.id where type = 0 order by storage_volumes.name"
And provide the output, as that should show any problem volumes.
Apparently I am victim to something similar. My guess is that an automatic snap refresh left me in perpetual
time="2022-08-05T20:02:56-07:00" level=error msg="Failed to start the daemon" err="Failed applying patch \"storage_missing_snapshot_records\": Failed applying patch to pool \"vg0\": Instance disk effective override field \"size\" should not be stored in volume config"
in /var/snap/lxd/common/lxd/logs/lxd.log for I donāt know how long. I had to reboot and now none of my containers are started and I cannot connect to lxd because it is not running.
Iām tracking latest/stable: 5.4-82d05d6 2022-07-27 (23339) but my familiarity with the LXD project and git branching/tagging is absent, so I canāt tell if this fix has been pulled in or not, or whether it should have fixed this issue. Iāve tried switching to latest/candidate and latest/edge, but the problem persisted. I attempted to downgrade to 5.3/stable, but it would not let me because of a revision mismatch in my local database (I think) - I did not capture the message. If this is a separate issue, I will gladly start a new topic, but it seemed relevant as the message is identical from rdratlos.
I think youāve been affected by two old bugs whose effects have lingered in your LXD database and have now been flagged up due to recent tightening up of validation checks.
Firstly, LXD has detected that some of your instances are missing associated storage volume DB records for some of the snapshot instance DB records. It is then trying to recreate the missing volume DB records using the main instance volume DB record as a basis. Unfortunately youāre then being affected by a 2nd issue because the main instance volume DB record contains a size config setting (which is invalid for instance volume DB records as the size should come from the instanceās root disk setting) which is then preventing the replacement instance snapshot volume DB records from being inserted.
To fix this we need to identify which instance volume DB records have an invalid size config setting and remove the setting.
To do this first identify the problematic storage volume records using:
sudo apt install sqlite3
sudo sqlite3 -table /var/snap/lxd/common/lxd/database/global/db.bin 'select storage_volumes_config.id as configID, storage_volumes.name, key, value from storage_volumes left join storage_volumes_config on storage_volumes.id = storage_volumes_config.storage_volume_id where storage_volumes.type = 0 and storage_volumes_config.key = "size";'
+----------+------+------+-------+
| configID | name | key | value |
+----------+------+------+-------+
| x | c1 | size | 20GiB |
+----------+------+------+-------+
This should get you one or more rows identifying the instance name(s) and the problematic configID row ID(s) in the storage_volumes_config table.
Next you need to prepare a /var/snap/lxd/common/lxd/database/patch.global.sql file to tell LXD to remove the problematic rows on startup.
E.g.
delete from storage_volumes_config where id in (x,y,z...);
