Hi Rajani,
Thanks for your reply.
i have created one testvm and manually destroyed from cloud ui.
the db entry in events table is:
select * from usage_event where type='VM.DESTROY'\G
*************************** 519. row ***************************
id: 36520
type: VM.DESTROY
account_id: 62
created: 2015-07-21 07:53:45
zone_id: 1
resource_id: 752
resource_name: testvm
offering_id: 78
template_id: 333
size: NULL
resource_type: XenServer
processed: 1
virtual_size: NULL
*i compared these entries to my vm:*
select * from usage_event where resource_name='appserver'\G
*************************** 18. row ***************************
id: 30714
type: VM.DESTROY
account_id: 29
created: 2015-03-17 14:31:24
zone_id: 1
resource_id: 311
resource_name: AppServer
offering_id: 34
template_id: 257
size: NULL
resource_type: XenServer
processed: 1
virtual_size: NULL
*i found that these two tables are same.*
*below are the few tables of the vm.*
*please suggest me what is the exact table to stop usage records.*
select * from cloud_usage where vm_name='AppServer'\G
*************************** 1289. row ***************************
id: 679340
zone_id: 1
account_id: 29
domain_id: 12
description: AppServer running time (ServiceOffering: 34) (Template: 257)
usage_display: 24 Hrs
usage_type: 1
raw_usage: 24
vm_instance_id: 311
vm_name: AppServer
offering_id: 34
template_id: 257
usage_id: 311
type: XenServer
size: NULL
network_id: NULL
start_date: 2015-08-17 00:00:00
end_date: 2015-08-17 23:59:59
virtual_size: NULL
select * from vm_instance where name='appserver'\G
*************************** 2. row ***************************
id: 311
name: AppServer
uuid: 0802d513-0bda-43d5-9600-20f705ca1ed7
instance_name: i-29-311-VM
state: Expunging
vm_template_id: 257
guest_os_id: 54
private_mac_address: 02:00:4a:a8:00:04
private_ip_address: 10.10.10.17
pod_id: 1
data_center_id: 1
host_id: NULL
last_host_id: 14
proxy_id: 299
proxy_assign_time: 2013-08-26 21:11:17
vnc_password: uPk1EIH5AmWi+djshYFcg7BtBXVzYHgQ866UT0/nV28=
ha_enabled: 0
limit_cpu_use: 0
update_count: 33
update_time: 2015-03-17 14:32:35
created: 2013-08-23 01:28:39
removed: 2015-08-14 12:57:21
type: User
vm_type: User
account_id: 29
domain_id: 12
service_offering_id: 34
reservation_id: 99128765-61b1-4e9f-b703-f20715a10a78
hypervisor_type: XenServer
disk_offering_id: NULL
cpu: NULL
ram: NULL
owner: 29
speed: 1024
host_name: AppServer
display_name: AppServer
desired_state: NULL
dynamically_scalable: 0
display_vm: 1
mysql> select * from volumes where instance_id=311\G
*************************** 1. row ***************************
id: 427
account_id: 29
domain_id: 12
pool_id: 208
last_pool_id: NULL
instance_id: 311
device_id: 0
name: ROOT-311
uuid: c253355e-a33c-4590-9b5e-74f7fa0c32cc
size: 53687091200
folder: lvm
path: ed119650-671e-4328-9ff2-2aefaac625a9
pod_id: 1
data_center_id: 1
iscsi_name: NULL
host_ip: NULL
volume_type: ROOT
pool_type: LVM
disk_offering_id: 34
template_id: 257
first_snapshot_backup_uuid: NULL
recreatable: 0
created: 2013-08-23 01:28:39
attached: NULL
updated: 2015-03-17 14:32:35
removed: 2015-05-03 02:57:00
state: Destroy
chain_info: NULL
update_count: 1025
disk_type: NULL
vm_snapshot_chain_size: NULL
iso_id: NULL
display_volume: 1
format: VHD
min_iops: NULL
max_iops: NULL
regards,
rajasekhar.
On Tue, Aug 18, 2015 at 11:49 AM, Rajani Karuturi <raj...@apache.org> wrote:
> update the usage_event table with VM.DESTROY event for this vm.
> I would say create a vm, destroy it and observer the entries in usage_event
> table. create a similar entry for the manually destroyed vm.
>
>
> ~Rajani
>
> On Tue, Aug 18, 2015 at 12:12 AM, raja sekhar <rajsekhar....@gmail.com>
> wrote:
>
> > Hi All,
> >
> > The usage records are still generating even if the vm is removed from
> > cloudstack.
> > The actual scenario is:
> > The xenserver host went to alert state and the vms in it are not
> > accessible.
> > we have removed the vms from backend by updating vm_instance,volume
> table.
> > can any one help me what is the exact table to update?
> > i am using cloudstack 4.2
> >
> > waiting for your valuable suggestions.
> >
> >
> > regards,
> > rajasekhar.
> >
>
