problem
With CLVM / CLVM-NG, it is required that the volume (LV) be active on the host that eventually starts the VM. This has been taken care of with template based deployments, by ensuring that the volume created from template gets created on the same host as the planned VM destination. This enforcement isn't there for ISOs, which could possibly lead the lv to be created (activated exclusively) on say host1 which the VM being started on host2 - and VM will not be able to start successfully as it can't access the lv.
As a workaround, either, one needs to manually deactivate (-an) the lv on host1 and exclusively activate it on host2 (-aey), or a force stop start / restart of agent - would trigger another start attempt, and that will reconcile the lock to the right host.
versions
4.23.0.0
The steps to reproduce the bug
- Register an ISO
- Attempt VM deployment from ISO
- VM may fail because it can access the LV as the activation happened on another host.
What to do about it?
No response
problem
With CLVM / CLVM-NG, it is required that the volume (LV) be active on the host that eventually starts the VM. This has been taken care of with template based deployments, by ensuring that the volume created from template gets created on the same host as the planned VM destination. This enforcement isn't there for ISOs, which could possibly lead the lv to be created (activated exclusively) on say host1 which the VM being started on host2 - and VM will not be able to start successfully as it can't access the lv.
As a workaround, either, one needs to manually deactivate (-an) the lv on host1 and exclusively activate it on host2 (-aey), or a force stop start / restart of agent - would trigger another start attempt, and that will reconcile the lock to the right host.
versions
4.23.0.0
The steps to reproduce the bug
What to do about it?
No response