[
https://issues.apache.org/jira/browse/CLOUDSTACK-3849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13721662#comment-13721662
]
Kishan Kavala commented on CLOUDSTACK-3849:
-------------------------------------------
Snapshot size is derived from volume size. Volume size in turn is derived from
template size. In this case template size is zero, so volume and snapshot size
also was set to zero.
Template size 0 was reported in CLOUDSTACK-3555 and is closed currently. Please
reopen CLOUDSTACK-3555 if the issue still exists.
> [Object_store_refactor][Usage] snapshot size is set to 0 in snapshts table
> which inturn sets size to 0 for SNAPSHOT_CREATE event in usage_events table
> ------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CLOUDSTACK-3849
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3849
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Snapshot, Storage Controller, Usage, VMware
> Affects Versions: 4.2.0
> Environment: Latest build from ACS 4.2 branch.
> Storage: NFS for both primary and secondary
> Reporter: Sanjeev N
> Assignee: Kishan Kavala
> Priority: Critical
> Fix For: 4.2.0
>
>
> [Object_store_refactor][Usage] snapshot size is set to 0 in snapshts table
> which inturn sets size to 0 for SNAPSHOT_CREATE event in usage_events table
> Observed this issue on VMWare only. Din't see in case of XenServer.
> Steps to Reproduce:
> ================
> 1.Bring up CS with VMWare cluster
> 2.Deploy guest vm with default cent os template
> 3.Take snapshot on guest vm's root disk
> 4.Wait for the snapshot backup to complete.
> Observations:
> ===========
> After snapshot backup was done and snapshot was in ready state in
> snapshot_store_ref observed the size set to 0.
> Even in snapshsots table size is set to 0 whereas in the secondary storage
> snapshot is present with actual physical size.
> Because of this issue size in usage_event for SNAPSHOT_CREATE is also set to
> 0. Since size is set to 0 user would not be charged for this snapshot.
> Following is the db output:
> =====================
> mysql> select * from snapshots where id=1\G;
> *************************** 1. row ***************************
> id: 1
> data_center_id: 2
> account_id: 2
> domain_id: 1
> volume_id: 9
> disk_offering_id: 1
> status: BackedUp
> path: NULL
> name: vm1-esx_ROOT-8_20130726084133
> uuid: a265823a-57bd-40d0-b890-49c511ff47e4
> snapshot_type: 0
> type_description: MANUAL
> size: 0
> created: 2013-07-26 08:41:33
> removed: NULL
> backup_snap_id: NULL
> swift_id: NULL
> sechost_id: NULL
> prev_snap_id: NULL
> hypervisor_type: VMware
> version: 2.2
> s3_id: NULL
> 1 row in set (0.00 sec)
> ERROR:
> No query specified
> mysql> select * from snapshot_store_ref where id=2\G;
> *************************** 1. row ***************************
> id: 2
> store_id: 2
> snapshot_id: 1
> created: 2013-07-26 08:41:33
> last_updated: NULL
> job_id: NULL
> store_role: Image
> size: 0
> physical_size: 0
> parent_snapshot_id: 0
> install_path:
> snapshots/2/9/6a3fec79-a55b-4536-9cc2-9aea56af3527/6a3fec79-a55b-4536-9cc2-9aea56af3527
> state: Ready
> update_count: 4
> ref_cnt: 0
> updated: 2013-07-26 09:40:04
> volume_id: 9
> 1 row in set (0.00 sec)
> ERROR:
> No query specified
> mysql> select * from usage_event where id=27\G;
> *************************** 1. row ***************************
> id: 27
> type: SNAPSHOT.CREATE
> account_id: 2
> created: 2013-07-26 09:08:31
> zone_id: 2
> resource_id: 1
> resource_name: vm1-esx_ROOT-8_20130726084133
> offering_id: NULL
> template_id: NULL
> size: 0
> resource_type: NULL
> processed: 0
> virtual_size: NULL
> 1 row in set (0.00 sec)
> ERROR:
> No query specified
> Physical location of the snapshot on the secondary storage as follows:
> [root@Rhel63-Sanjeev 6a3fec79-a55b-4536-9cc2-9aea56af3527]# pwd
> /tmp/sec/sec_esx_os/snapshots/2/9/6a3fec79-a55b-4536-9cc2-9aea56af3527
> [root@Rhel63-Sanjeev 6a3fec79-a55b-4536-9cc2-9aea56af3527]# ls -l
> total 897948
> -rw-rw----+ 1 root root 459283968 Jul 25 17:01
> 6a3fec79-a55b-4536-9cc2-9aea56af3527-disk0.vmdk
> -rw-rw----+ 1 root root 459294720 Jul 25 17:07
> 6a3fec79-a55b-4536-9cc2-9aea56af3527.ova
> -rw-rw----+ 1 root root 6500 Jul 25 17:01
> 6a3fec79-a55b-4536-9cc2-9aea56af3527.ovf
> [root@Rhel63-Sanjeev 6a3fec79-a55b-4536-9cc2-9aea56af3527]#
--
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
