cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <>
Subject [jira] [Commented] (CLOUDSTACK-2519) VMs on local storage incorrectly destroyed when removing another host using deleteHost API
Date Wed, 15 May 2013 20:31:17 GMT


ASF subversion and git services commented on CLOUDSTACK-2519:

Commit ddd7cfd71c45c708012d30a0b7858db9d74c90f4 in branch refs/heads/master from Prachi Damle
[;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
> ------------------------------------------------------------------------------------------
>                 Key: CLOUDSTACK-2519
>                 URL:
>             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
> - 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:

View raw message