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/12/26 11:37:52 UTC

[jira] [Resolved] (CLOUDSTACK-5193) [Hyper-V] VHDs not deleted post VM destroy and expunge

     [ https://issues.apache.org/jira/browse/CLOUDSTACK-5193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rajesh Battala resolved CLOUDSTACK-5193.
----------------------------------------

    Resolution: Fixed

> [Hyper-V] VHDs not deleted post VM destroy and expunge
> ------------------------------------------------------
>
>                 Key: CLOUDSTACK-5193
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5193
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: Hypervisor Controller, Management Server, Storage Controller
>    Affects Versions: 4.3.0
>         Environment: Hyper-V
>            Reporter: Sowmya Krishnan
>            Assignee: Rajesh Battala
>            Priority: Critical
>              Labels: hyper-V,
>             Fix For: 4.3.0
>
>         Attachments: destroyvm.log
>
>
> Create a VM with local/shared storage offering.
> Destroy the VM with expunge = true or destroy and wait for VM to expunge.
> Although VM is destroyed and volume is marked removed in cloud DB, it is not removed from the hypervisor disk. I don't find .storage.command.DeleteCommand being triggered as part of the Destroy VM.
> As seen below, vhd corresponding to VM i-2-27-VM still resides in the host:
> C:\Users\Public\Documents\Hyper-V\Virtual hard disks>dir /W "ROOT-27.vhd"
>  Volume in drive C has no label.
>  Volume Serial Number is 7C16-4C80
>  Directory of C:\Users\Public\Documents\Hyper-V\Virtual hard disks
> ROOT-27.vhd
>                1 File(s)  3,120,370,688 bytes
>                0 Dir(s)  892,863,770,624 bytes free
> C:\Users\Public\Documents\Hyper-V\Virtual hard disks>
> SQL output for the destroyed VM volume:
> mysql> select * from volumes where id = 28\G
> *************************** 1. row ***************************
>                         id: 28
>                 account_id: 2
>                  domain_id: 1
>                    pool_id: 1
>               last_pool_id: NULL
>                instance_id: 27
>                  device_id: 0
>                       name: ROOT-27
>                       uuid: fe491447-52fb-413e-a7a0-339c573f154f
>                       size: 1073741824
>                     folder: NULL
>                       path: NULL
>                     pod_id: NULL
>             data_center_id: 1
>                 iscsi_name: NULL
>                    host_ip: NULL
>                volume_type: ROOT
>                  pool_type: NULL
>           disk_offering_id: 13
>                template_id: 204
> first_snapshot_backup_uuid: NULL
>                recreatable: 0
>                    created: 2013-11-18 09:22:46
>                   attached: NULL
>                    updated: 2013-11-18 09:27:03
>                    removed: 2013-11-18 09:27:03
>                      state: Destroy
>                 chain_info: NULL
>               update_count: 4
>                  disk_type: NULL
>     vm_snapshot_chain_size: NULL
>                     iso_id: NULL
>             display_volume: 1
>                     format: NULL
>                   min_iops: NULL
>                   max_iops: NULL
>              hv_ss_reserve: NULL
> 1 row in set (0.00 sec)



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)