[
https://issues.apache.org/jira/browse/CLOUDSTACK-4208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
venkata swamybabu budumuru closed CLOUDSTACK-4208.
--------------------------------------------------
misunderstood the scenario. The behaviour I mentioned here is as expected hence
closing the issue.
> [ResetVM] ResetVM is not cleaning the old snapshots
> ----------------------------------------------------
>
> Key: CLOUDSTACK-4208
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4208
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Snapshot
> Affects Versions: 4.2.0
> Environment: commit id # 7fced6460f13468369550c968670c7d0b9837949
> Reporter: venkata swamybabu budumuru
> Assignee: Harikrishna Patnala
> Priority: Critical
> Fix For: 4.2.0
>
>
> Steps to reproduce:
> 1. Have latest CloudStack setup with at least one advanced zone using a KVM
> cluster of 2 hosts.
> 2. As a non-ROOT admin, deploy a VM
> 3. Take a snapshot
> 4. Click on ResetVM option while the VM is running
> Observations:
> (i) I can see in the mgmt server logs for restoreVirtualMachine as mentioned
> below.
> 2013-08-09 15:18:37,991 DEBUG [cloud.api.ApiServlet] (catalina-exec-20:null)
> ===START=== 10.252.192.25 -- GET
> command=restoreVirtualMachine&virtualmachineid=5d7a81fe-65ef-4a17-8558-0df0ab7e02d8&response=json&sessionkey=BCQB7S0qwhF8ZaSpZ%2ByvCw%2F92d4%3D&_=1376041729404
> 2013-08-09 15:18:38,057 DEBUG [cloud.network.NetworkManagerImpl]
> (Network-Scavenger-1:null) Lock is acquired for network Ntwk[236|Guest|8] as
> a part of network shutdown
> 2013-08-09 15:18:38,058 DEBUG [cloud.network.NetworkManagerImpl]
> (Network-Scavenger-1:null) Network is not implemented: Ntwk[236|Guest|8]
> 2013-08-09 15:18:38,061 DEBUG [cloud.network.NetworkManagerImpl]
> (Network-Scavenger-1:null) Lock is released for network Ntwk[236|Guest|8] as
> a part of network shutdown
> 2013-08-09 15:18:38,108 DEBUG [cloud.async.AsyncJobManagerImpl]
> (catalina-exec-20:null) submit async job-670 = [
> 2b6de978-2c71-4ad5-bc61-a0721d556f11 ], details: AsyncJobVO {id:670, userId:
> 139, accountId: 151, sessionKey: null, instanceType: None, instanceId: null,
> cmd: org.apache.cloudstack.api.command.user.vm.RestoreVMCmd, cmdOriginator:
> null, cmdInfo:
> {"response":"json","sessionkey":"BCQB7S0qwhF8ZaSpZ+yvCw/92d4\u003d","virtualmachineid":"5d7a81fe-65ef-4a17-8558-0df0ab7e02d8","cmdEventType":"VM.RESTORE","ctxUserId":"139","httpmethod":"GET","_":"1376041729404","ctxAccountId":"151","ctxStartEventId":"3210"},
> cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
> processStatus: 0, resultCode: 0, result: null, initMsid: 7280707764394,
> completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
> (ii) This action deleted the old volume with id 251 and created a new with
> volume id 259
> mysql> select * from volumes where id=251\G
> *************************** 1. row ***************************
> id: 251
> account_id: 151
> domain_id: 3
> pool_id: 1
> last_pool_id: NULL
> instance_id: NULL
> device_id: NULL
> name: ROOT-213
> uuid: c8951f7f-593a-4bb4-a9dc-2a9ed307c6f1
> size: 32212254720
> folder: NULL
> path: 30a56120-caa3-424a-a291-3794ff74d5bf
> pod_id: NULL
> data_center_id: 1
> iscsi_name: NULL
> host_ip: NULL
> volume_type: ROOT
> pool_type: NULL
> disk_offering_id: 2
> template_id: 211
> first_snapshot_backup_uuid: NULL
> recreatable: 0
> created: 2013-08-08 13:39:25
> attached: NULL
> updated: 2013-08-09 09:48:49
> removed: 2013-08-09 09:48:49
> state: Expunged
> chain_info: NULL
> update_count: 8
> disk_type: NULL
> vm_snapshot_chain_size: NULL
> iso_id: 0
> display_volume: 0
> format: QCOW2
> min_iops: NULL
> max_iops: NULL
> 1 row in set (0.00 sec)
> mysql> select * from volumes where instance_id=213\G
> *************************** 1. row ***************************
> id: 259
> account_id: 151
> domain_id: 3
> pool_id: 1
> last_pool_id: NULL
> instance_id: 213
> device_id: 0
> name: ROOT-213
> uuid: b3331940-e778-4b36-8e74-ede4c8953c1b
> size: 32212254720
> folder: NULL
> path: 6c691045-c050-4321-b567-a6761b473ad8
> pod_id: NULL
> data_center_id: 1
> iscsi_name: NULL
> host_ip: NULL
> volume_type: ROOT
> pool_type: NULL
> disk_offering_id: 2
> template_id: 211
> first_snapshot_backup_uuid: NULL
> recreatable: 0
> created: 2013-08-09 09:48:49
> attached: 2013-08-09 09:48:49
> updated: 2013-08-09 09:48:50
> removed: NULL
> state: Ready
> chain_info: NULL
> update_count: 2
> disk_type: NULL
> vm_snapshot_chain_size: NULL
> iso_id: 0
> display_volume: 0
> format: QCOW2
> min_iops: NULL
> max_iops: NULL
> 1 row in set (0.00 sec)
> (iii) But, this event didn't trigger in deleting the old snapshots on old
> volume i.e. 251
> mysql> select * from snapshot_store_ref\G
> *************************** 1. row ***************************
> id: 1
> store_id: 1
> snapshot_id: 1
> created: 2013-08-09 09:34:30
> last_updated: NULL
> job_id: NULL
> store_role: Primary
> size: 0
> physical_size: 0
> parent_snapshot_id: 0
> install_path:
> /mnt/5458182e-bfcb-351c-97ed-e7223bca2b8e/30a56120-caa3-424a-a291-3794ff74d5bf/51bb35f9-7b8c-4481-b45e-24baa8f8ce06
> state: Ready
> update_count: 2
> ref_cnt: 0
> updated: 2013-08-09 09:34:32
> volume_id: 251
> *************************** 2. row ***************************
> id: 2
> store_id: 1
> snapshot_id: 1
> created: 2013-08-09 09:34:32
> last_updated: NULL
> job_id: NULL
> store_role: Image
> size: 0
> physical_size: 0
> parent_snapshot_id: 0
> install_path: snapshots/151/251/51bb35f9-7b8c-4481-b45e-24baa8f8ce06
> state: Ready
> update_count: 2
> ref_cnt: 0
> updated: 2013-08-09 09:43:52
> volume_id: 251
> mysql> select * from snapshots\G
> *************************** 1. row ***************************
> id: 1
> data_center_id: 1
> account_id: 151
> domain_id: 3
> volume_id: 251
> disk_offering_id: 2
> status: BackedUp
> path: NULL
> name: 5d7a81fe-65ef-4a17-8558-0df0ab7e02d8_ROOT-213_20130809093429
> uuid: d3a403b9-d196-4c57-b2a8-85cf0c093833
> snapshot_type: 0
> type_description: MANUAL
> size: 32212254720
> created: 2013-08-09 09:34:29
> removed: NULL
> backup_snap_id: NULL
> swift_id: NULL
> sechost_id: NULL
> prev_snap_id: NULL
> hypervisor_type: KVM
> version: 2.2
> s3_id: NULL
> (iv) Checked the primary and I can see that the volume i.d 251 is deleted.
> below is snippet from primary storage
> [root@CentOS63Dev 1]# cd primary.campo.kvm.1.zone/
> [root@CentOS63Dev primary.campo.kvm.1.zone]# !ls
> ls -lth | grep -i 30a
> (v) Have checked on the secondary storage and I could still see the snapshot
> existing thought the volume associated with is deleted.
> [root@CentOS63Dev 251]# pwd
> /tmp/1/secondary.campo.kvm.1/snapshots/151/251
> [root@CentOS63Dev 251]# ls -lth 51bb35f9-7b8c-4481-b45e-24baa8f8ce06
> -rw-r-----+ 1 root root 6.5G Aug 9 03:14 51bb35f9-7b8c-4481-b45e-24baa8f8ce06
> Here is global setting info
> storage.cleanup.enabled = true
> storage.cleanup.interval = 30
> Attaching all the logs along with db dump to the bug.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
