[jira] [Commented] (CLOUDSTACK-2519) VMs on local storage incorrectly destroyed when removing another host using deleteHost API

["Prachi Damle (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CLOUDSTACK-2519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13658683#comment-13658683 ] 

Prachi Damle commented on CLOUDSTACK-2519:
------------------------------------------

Also one more observation is:

When such situation happens, try to put hostA in maintenance mode after making sure there are no VMs running on it. 'Enable Maintenance' will fail saying there are active VM's using local storage, even if there are no VM's on this host.
This is because of the volume entry in 'Destroy' state on this host A's LVM.
                
> VMs on local storage incorrectly destroyed when removing another host using deleteHost API
> ------------------------------------------------------------------------------------------
>
>                 Key: CLOUDSTACK-2519
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2519
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: Management Server
>            Reporter: Prachi Damle
>            Assignee: Prachi Damle
>             Fix For: 4.2.0
>
>
> Steps to reproduce:
> Using local storage following erroneous situation is observed while using deleteHost API:
> - Use local storage. Suppose Zone has 2 clusters, say Cluster1 has 2 hosts (host A and host B). Cluster 2 has 1 host (host C)
> During deployVM following needs to happen:
> 1) host A is selected and VM's root disk is created on its local storage. Then mgt server sends start command to the host A to start this vm, but somehow, start vm failed.
> 2) Then we will retry another host in the same cluster, but no other host in that cluster can be used since the root Disk on local storage is not accessible to hostB.
> 3) Then planner will find host C in other cluster and a new local storage pool
> 4) Mgmt server will mark the previous root disk as destroyed, and create new root disk on local stoarge of host C
> 5) Vm starts successfully on host C
> 6) At this point, VM instance is on host C. In volumes table, 2 records point to this VM instance - one record is the root disk in READY state on host C LVM. Another entry is root disk in Destroy state (that was created in step 1 ) on host A LVM. This is fine.
> 7) Now using deleteHostAPI, try to delete Host A. When host A is deleted, the VM running on host C gets destroyed. Use command: command=deleteHost&id=<host_id>&forced=true&forcedestroylocalstorage=true
> This is a bug that is picking the VM on host C wrongly because we find a volume record on host A LVM pointing to this VM. Mgmt Server should not destroy this VM. To fix this it should search the volumes records that are in READY state only.
> To reproduce this, simulator might be needed since we need to somehow return error to the startCommand from hostA in step 1 above. But host C should return success.

--
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