status 9453: resolved fixed
1) Problem #1 was that in 2.1.x there was a bug when we didn't delete pf rules for expunged vms. These kind of rules will be ignored during the db upgrade
2) Problem #2. We didn't trim the spaces for PF/LB ports in 2.1.x, and DB upgrade code was failing because of that.
Changes:
While starting a System VM:
- We check, incase the ROOT volume is READY, if the templateID of the volume matches the SystemVM's template.
- If it does not match, we update the volumes' templateId and ask deployment planner to reassign a pool to this volume even if it is READY.
In general:
- If a root volume is READY, we remove its entry from the deploydestination before calling storagemanager :: prepare()
- StorageManager creates a volume if a pool is assigned to it in deploydestination passed to it.
- If a volume has no pool assigned to it in deploydestination, it means the volume is ready and has a pool already allocated to it.
- Update system vm_instance's template_id if it does not match the system vm template.
- Use _templateDao.findSystemVMTemplate to find the latest system vm template.
Changes:
- Planner must reassign the storage pool if the template id for system vms has changed. StorageManager must then recreate the volume if the volume has been
reassigned. This is needed to do automatic update of the system template.
Also changed 'RegisterTemplate' to take in a new optional parameter 'checksum'.
The value set to it is stored as-is in the DB in vm_template table, 'checksum' column.
Modified TemplateResponse to contain a new field 'checksum' of the template. The value is pulled from the vm_template table, 'checksum' column.
Conflicts:
server/src/com/cloud/api/ApiResponseHelper.java
Changes:
- Now while listing hosts for migration, capacity is calculated as total_capacity -used_capacity
instead of total_capacity -(used_capacity + reserved_capacity)
- Also, the capacity columns in op_host_capacity are now 'signed' type so that the subtractions in queries does not overflow.
- Added this to DB upgrade 222 to 224 change as well.
Changes:
- When migration fails we try to do cleanup on the destination host agent. The AgentUnavailableException in this cleanup was not caught.
-Due to that other cleanup like reverting capacity allocated and vm state were skipped.
-Fix is to catch the AgentUnavailableException so that rest of the cleanup can happen.
- Also corrected the exceptions in various cases of migration failure.
- In case the VM is still starting, HA should schedule a retry. Introduced a special migration exception for handling this.
alena
Edison Su
anthony
root
Alex Huang
prachi
Murali Reddy
Chiradeep Vittal
kishan
Kelven Yang