GutoVeronezi commented on issue #8034:
URL: https://github.com/apache/cloudstack/issues/8034#issuecomment-1750699975
@rohityadavcloud @andrijapanicsb
Users will have a backing store in their volume snapshots in the following
cases:
- the snapshots are from a `ROOT` volume created from template[^migrated];
Users will not have a backing store in their volume snapshots in the
following cases:
- the snapshots are from `ROOT` volumes created with ISO;
- the snapshots are from `DATADISK` volumes;
Following there are two queries to help users identify snapshots with a
backing store:
- Identify snapshots that were not removed yet and were created from a
volume that was created from a template:
```sql
SELECT s.uuid AS "Snapshot ID",
s.name AS "Snapshot Name",
s.created AS "Snapshot creation datetime",
img_s.uuid AS "Sec Storage ID",
img_s.name AS "Sec Storage Name",
ssr.install_path AS "Snapshot path on Sec Storage",
v.uuid AS "Volume ID",
v.name AS "Volume Name"
FROM cloud.snapshots s
INNER JOIN cloud.volumes v ON (v.id = s.volume_id)
INNER JOIN cloud.snapshot_store_ref ssr ON (ssr.snapshot_id = s.id
AND ssr.store_role = 'Image')
INNER JOIN cloud.image_store img_s ON (img_s.id = ssr.store_id)
WHERE s.removed IS NULL
AND v.template_id IS NOT NULL;
```
With that, one can use `qemu-img info` in the snapshot file to check if
they have a backing store.
- For those snapshots that have a backing store, one can use the following
query to check which template is it and in which storage pool it is:
```sql
SELECT vt.uuid AS "Template ID",
vt.name AS "Template Name",
tsr.install_path AS "Template file on Pri Storage",
sp.uuid AS "Pri Storage ID",
sp.name AS "Pri Storage Name",
sp.`path` AS "Pri Storage Path",
sp.pool_type as "Pri Storage type"
FROM cloud.template_spool_ref tsr
INNER JOIN cloud.storage_pool sp ON (sp.id = tsr.pool_id AND sp.removed
IS NULL)
INNER JOIN cloud.vm_template vt ON (vt.id = tsr.template_id)
WHERE tsr.install_path = "<template file in the snapshot backing store>";
```
After identifying the snapshots with a backing store and the related
templates, one can mount the secondary storage on a host that has access to the
template and use `qemu-img convert` on the snapshot to consolidate it:
```
qemu-img convert -O qcow2 -U --image-opts driver=qcow2,file.filename=<path
to snapshot on secondary storage> <path to snapshot on secondary
storage>-converted
```
Then, one can use `qemu-img info` to check the information of the
consolidated file. After validating the consolidated file (e.g.: if it is
booting), one can replace the original snapshot file with the consolidated
file. These processes should be done carefully, in order to guarantee the
health of the environment.
[^migrated]: while migrating a volume, ACS consolidates the volume. However,
it depends on the type and protocol of the source and destination storage. For
instance, a `NFS` to `NFS` migration will not consolidate the volume; on the
other hand, a `NFS` to `SharedMountPoint` migration will consolidate the
volume. Therefore, users might not see the problem with snapshots from `ROOT`
volumes created from templates and migrated, in some cases.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
