Prachi Damle created CLOUDSTACK-2519:
----------------------------------------
Summary: 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
