winterhazel commented on PR #8041: URL: https://github.com/apache/cloudstack/pull/8041#issuecomment-1789479608
Hello guys, Just for the record, I reproduced the issue without the patch and validated the changes in this PR. Following there is the tests that I have made and its details: First, I created two clusters as described [here](https://github.com/apache/cloudstack/pull/8041#issuecomment-1749383613): `c1` with a cluster-wide primary storage (`cw-pri-c1`) and `c2` with a cluster-wide primary-storage (`cw-pri-c2`). <details> <summary> Before the patch </summary> 1. I created the VM `VM-A` in `c1` from a template; 2. I verified that the ROOT volume of `VM-A` referenced a backing file: ```bash qemu-img info -U /mnt/c3f4c767-72fe-39e0-a4d1-176c7c19dc74/7c354408-3fed-4113-92b1-4f59f6f97ce0 image: /mnt/c3f4c767-72fe-39e0-a4d1-176c7c19dc74/7c354408-3fed-4113-92b1-4f59f6f97ce0 file format: qcow2 virtual size: 8 GiB (8589934592 bytes) disk size: 324 KiB cluster_size: 65536 backing file: /mnt/c3f4c767-72fe-39e0-a4d1-176c7c19dc74/bb4b7b6f-5249-4c18-a5f6-dd886683b702 backing file format: qcow2 Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false ``` 3. I created the snapshot `vm-a-snap` from the ROOT volume of `VM-A`; 4. I verified that the snapshot `vm-a-snap` referenced a backing file: ```bash qemu-img info /mnt/secondary-storage/snapshots/2/275/165748b5-6ac3-4f95-aac5-3df84945074c image: /mnt/secondary-storage/snapshots/2/275/165748b5-6ac3-4f95-aac5-3df84945074c file format: qcow2 virtual size: 8 GiB (8589934592 bytes) disk size: 22.9 MiB cluster_size: 65536 backing file: /mnt/c3f4c767-72fe-39e0-a4d1-176c7c19dc74/bb4b7b6f-5249-4c18-a5f6-dd886683b702 backing file format: qcow2 Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false ``` 5. I created the template `tmpl-vm-a` from the snapshot `vm-a-snap`; 6. I tried to deploy a VM with template `tmpl-vm-a` on `c2`; 7. I verified that the deployment failed. </details> <details> <summary> After applying the patch </summary> 1. I created the VM `VM-B` in `c1` from a template; 2. I verified that the ROOT volume of `VM-B` referenced a backing file: ```bash qemu-img info -U /mnt/c3f4c767-72fe-39e0-a4d1-176c7c19dc74/cee7704d-07cc-452f-b6eb-7342ccd87f2c image: cee7704d-07cc-452f-b6eb-7342ccd87f2c file format: qcow2 virtual size: 8 GiB (8589934592 bytes) disk size: 25.9 MiB cluster_size: 65536 backing file: /mnt/c3f4c767-72fe-39e0-a4d1-176c7c19dc74/bb4b7b6f-5249-4c18-a5f6-dd886683b702 backing file format: qcow2 Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false ``` 3. I created the snapshot `vm-b-snap` from the ROOT volume of `VM-B`; 4. I verified that the snapshot `vm-b-snap` was consolidated: ```bash qemu-img info -U /mnt/secondary-storage/snapshots/2/268/60e80be4-ec59-41dc-aaeb-915abe08ec38 image: snapshots/2/268/60e80be4-ec59-41dc-aaeb-915abe08ec38 file format: qcow2 virtual size: 8 GiB (8589934592 bytes) disk size: 2.6 GiB cluster_size: 65536 Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false ``` 5. I created the template `tmpl-vm-b` from the snapshot `vm-b-snap`; 6. I tried to deploy a VM with template `tmpl-vm-b` on `c2`; 7. I verified that the deployment finished successfully. </details> --- I also tested the consolidation of volumes after migrating them, described [here](https://github.com/apache/cloudstack/pull/8041#issuecomment-1748900767). The results were the same before and after applying the patch. <details> <summary> Before the patch </summary> 1. I verified that the ROOT volume of `VM-A` referenced a backing file: ```bash qemu-img info -U /mnt/c3f4c767-72fe-39e0-a4d1-176c7c19dc74/7c354408-3fed-4113-92b1-4f59f6f97ce0 image: /mnt/c3f4c767-72fe-39e0-a4d1-176c7c19dc74/7c354408-3fed-4113-92b1-4f59f6f97ce0 file format: qcow2 virtual size: 8 GiB (8589934592 bytes) disk size: 324 KiB cluster_size: 65536 backing file: /mnt/c3f4c767-72fe-39e0-a4d1-176c7c19dc74/bb4b7b6f-5249-4c18-a5f6-dd886683b702 backing file format: qcow2 Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false ``` 2. I added a `DATADISK` to `VM-A`; 3. I verified that the `DATADISK` did not reference a backing file: ```bash qemu-img info -U /mnt/c3f4c767-72fe-39e0-a4d1-176c7c19dc74/a61c6c88-73ae-4597-be3d-e489b77db09d image: /mnt/c3f4c767-72fe-39e0-a4d1-176c7c19dc74/a61c6c88-73ae-4597-be3d-e489b77db09d file format: qcow2 virtual size: 5 GiB (5368709120 bytes) disk size: 196 KiB cluster_size: 65536 Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false ``` 4. I migrated `VM-A` to `c2`; 5. I verified that the ROOT volume of `VM-A` had been consolidated: ```bash qemu-img info -U /mnt/e0560866-421e-313d-8602-320c58842a7e/458e15ce-61cd-476a-88da-660c28c0e940 image: /mnt/e0560866-421e-313d-8602-320c58842a7e/458e15ce-61cd-476a-88da-660c28c0e940 file format: qcow2 virtual size: 8 GiB (8589934592 bytes) disk size: 2.6 GiB cluster_size: 65536 Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false ``` 6. And that the `DATADISK` did not change: ```bash qemu-img info -U /mnt/e0560866-421e-313d-8602-320c58842a7e/bfdc7820-d090-4622-b9aa-f7c780a96ddc image: /mnt/e0560866-421e-313d-8602-320c58842a7e/bfdc7820-d090-4622-b9aa-f7c780a96ddc file format: qcow2 virtual size: 5 GiB (5368709120 bytes) disk size: 196 KiB cluster_size: 65536 Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false ``` </details> <details> <summary> After applying the patch </summary> 1. I verified that the ROOT volume of `VM-B` referenced a backing file: ```bash qemu-img info -U /mnt/c3f4c767-72fe-39e0-a4d1-176c7c19dc74/cee7704d-07cc-452f-b6eb-7342ccd87f2c image: cee7704d-07cc-452f-b6eb-7342ccd87f2c file format: qcow2 virtual size: 8 GiB (8589934592 bytes) disk size: 25.9 MiB cluster_size: 65536 backing file: /mnt/c3f4c767-72fe-39e0-a4d1-176c7c19dc74/bb4b7b6f-5249-4c18-a5f6-dd886683b702 backing file format: qcow2 Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false ``` 2. I added a `DATADISK` to `VM-B`; 3. I verified that the `DATADISK` did not reference a backing file: ```bash qemu-img info -U /mnt/c3f4c767-72fe-39e0-a4d1-176c7c19dc74/4bc334f5-95e7-43c6-bede-245f22ef7aa5 image: 4bc334f5-95e7-43c6-bede-245f22ef7aa5 file format: qcow2 virtual size: 5 GiB (5368709120 bytes) disk size: 196 KiB cluster_size: 65536 Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false ``` 4. I migrated `VM-B` to `c2`; 5. I verified that the ROOT volume of `VM-B` had been consolidated: ```bash qemu-img info -U /mnt/e0560866-421e-313d-8602-320c58842a7e/7491cf25-7364-4f6a-bf62-b0f1dca16e61 image: 7491cf25-7364-4f6a-bf62-b0f1dca16e61 file format: qcow2 virtual size: 8 GiB (8589934592 bytes) disk size: 2.6 GiB cluster_size: 65536 Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false ``` 6. And that the `DATADISK` did not change: ```bash qemu-img info -U /mnt/e0560866-421e-313d-8602-320c58842a7e/5776344c-1e74-4653-9fb1-ca10cdca3ab6 image: /mnt/e0560866-421e-313d-8602-320c58842a7e/5776344c-1e74-4653-9fb1-ca10cdca3ab6 file format: qcow2 virtual size: 5 GiB (5368709120 bytes) disk size: 196 KiB cluster_size: 65536 Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false ``` </details> --- Finally, I tested all the workflows described in the original PR #5297 twice, once with the global setting `snapshot.backup.to.secondary` as `true` and once as `false`, and verified they are working as expected. -- 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]
