You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cloudstack.apache.org by "Rajesh Battala (JIRA)" <ji...@apache.org> on 2013/07/26 12:29:48 UTC
[jira] [Commented] (CLOUDSTACK-3849) [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
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13720623#comment-13720623 ]
Rajesh Battala commented on CLOUDSTACK-3849:
--------------------------------------------
Is this specific to vmware ?
> [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
> 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