cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rajesh Battala (JIRA)" <j...@apache.org>
Subject [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
Date Fri, 26 Jul 2013 10:29:48 GMT

    [ 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

Mime
View raw message