GabrielBrascher commented on issue #3969: Snapshot deletion issues
URL: https://github.com/apache/cloudstack/pull/3969#issuecomment-604436002
 
 
   @andrijapanicsb thank you very much for all the tests. Here follows an 
update on  `snapshot.backup.to.secondary = FALSE`.
   
   I have been testing this implementation (tested with 4.13.1 and also on a 
port to 4.14.0). The snapshotting with `snapshot.backup.to.secondary = FALSE` 
seems to be working fine for me. Created and deleted on (i) XenServer + NFS, 
(ii) KVM + NFS, (iii) KVM + Ceph.
   
   Environment:
   - CloudStack management node: Ubuntu 18.04
   - KVM nodes: Ubuntu 18.04
   - XenServer 6.5
   
   Can you please share more details on the issue that you had? Are there 
exceptions on management or the agent node? Is the DB  being correctly updated 
(snapshots, volumes, snapshot_store_ref)?
   
   Note that snapshots on NFS as primary storage is a bit different than on 
secondary. The snapshot handling for NFS (primary) is executed with the help of 
the 
[managesnapshot.sh](https://github.com/apache/cloudstack/blob/da865f08d30df5e177154049215fb6f4b54e5252/scripts/storage/qcow2/managesnapshot.sh#L72)
 script. That script on KVM + NFS (primary) creates a lvm, which makes a bit 
tricky to find the snapshot volume compared to other approaches (e.g. ceph: 
`rbd snap ls foo`, nfs secondary: `ls -lah /export/secondary/snapshots/`, 
XenServer: `xe vdi-list`).
   
   Basically the script runs a lvm lvcreate: `lvm lvcreate --size ${lv_bytes}b 
--name "${snapshotname}-cow" ${vg} >&2 || return 2`. Let's say that the volume 
path is `/mnt/<uuid primary>/<uuid volume>`.
   
   Thus, the snapshot path will become something as `/mnt/<uuid primary>/<uuid 
volume>/<uuid snapshot>`. However, one looking at the NFS storage via `ls 
/mnt/<uuid primary>/` will see something as `/mnt/<uuid primary>/<uuid volume>`.
   
   Is that happening on your test environment?

----------------------------------------------------------------
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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Reply via email to