anniejili opened a new pull request, #8202:
URL: https://github.com/apache/cloudstack/pull/8202
### Description
When there is outage in storage API coincides with a VM start, the volume
could be stuck in "Allocated" state but with a pool Id assigned in DB. It
blocked the ability to start the VM during planDeployment process, in the
method storagePoolCompatibleWithVolumePool() shown below when validating a
volume with a storage pool, if the volume's pool Id is not null and state is
Allocated, it would always return false for any storage pools. As a result, the
allocator cannot find a suitable pool and it blocks the VM start process.
```
@Override
public boolean storagePoolCompatibleWithVolumePool(StoragePool pool,
Volume volume) {
if (pool == null || volume == null) {
return false;
}
if (volume.getPoolId() == null) {
// Volume is not allocated to any pool. Not possible to check
compatibility with other pool, let it try
return true;
}
StoragePool volumePool =
_storagePoolDao.findById(volume.getPoolId());
if (volumePool == null) {
// Volume pool doesn't exist. Not possible to check
compatibility with other pool, let it try
return true;
}
if (volume.getState() == Volume.State.Ready) {
if (volumePool.getPoolType() ==
Storage.StoragePoolType.PowerFlex && pool.getPoolType() !=
Storage.StoragePoolType.PowerFlex) {
return false;
} else if (volumePool.getPoolType() !=
Storage.StoragePoolType.PowerFlex && pool.getPoolType() ==
Storage.StoragePoolType.PowerFlex) {
return false;
}
} else {
return false;
}
return true;
}
```
This PR fixed the issue above by validating volumes's state and pool id
before the deployment in DeploymentPlanningManagerImpl.java's
findSuitablePoolsForVolumes() method. Before DeploymentPlanningManager is
trying to find suitable storage pools for volumes, if any volume is in
Allocated state with a pool ID, the pool id will be cleared.
**Testing**
For a stopped VM, manually updated its root volume state to "Allocated" with
a pool ID. Then restart the VM.
Before the change
2023-08-22 23:40:00,948 INFO [o.a.c.a.c.u.v.StartVMCmd]
(API-Job-Executor-70:ctx-xxxx job-xxxx ctx-xxxx) (logid:xxxx) No destination
found for a deployment for VM instance {id: "xxxx", name: "xxxx, uuid: "xxxx",
type="User"}
After the change
The VM is started successfully.
### Types of changes
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] New feature (non-breaking change which adds functionality)
- [X] Bug fix (non-breaking change which fixes an issue)
- [ ] Enhancement (improves an existing feature and functionality)
- [ ] Cleanup (Code refactoring and cleanup, that may add test cases)
### Feature/Enhancement Scale or Bug Severity
#### Feature/Enhancement Scale
- [ ] Major
- [ ] Minor
#### Bug Severity
- [ ] BLOCKER
- [ ] Critical
- [ ] Major
- [X] Minor
- [ ] Trivial
### Screenshots (if appropriate):
### How Has This Been Tested?
The change is tested via added junit test cases. The change is also tested
and verified in Cloud Stack development environment.
<!-- Please read the
[CONTRIBUTING](https://github.com/apache/cloudstack/blob/main/CONTRIBUTING.md)
document -->
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
