[
https://issues.apache.org/jira/browse/CLOUDSTACK-2519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13658754#comment-13658754
]
ASF subversion and git services commented on CLOUDSTACK-2519:
-------------------------------------------------------------
Commit ddd7cfd71c45c708012d30a0b7858db9d74c90f4 in branch refs/heads/master
from Prachi Damle <[email protected]>
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ddd7cfd ]
CLOUDSTACK-2519: VMs on local storage incorrectly destroyed when removing
another host using deleteHost API
- For DeleteHost API: Search for Volumes in READY state on the local storage of
the host to find VM's in 'Running' State
- For PrepareForMaintenance API: Search for Volumes not in Destroy or Expunging
state to check if the Local Storage on the host is being used.
> 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
