[ https://issues.apache.org/jira/browse/CLOUDSTACK-2519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13659795#comment-13659795 ]
ASF subversion and git services commented on CLOUDSTACK-2519: ------------------------------------------------------------- Commit ddd7cfd71c45c708012d30a0b7858db9d74c90f4 in branch refs/heads/planner_reserve from Prachi Damle <pra...@cloud.com> [ 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