Changes:
- Cluster entry is not removed from the table when a cluster is deleted because there are some foreign key constraints failing if the row delete is attempted. Instead the cluster is marked as 'removed'
- While deleting the pod changed the check to see if pod has any clusters - we now check that there are no clusters with removed column null.
- Also pod entry cannot be deleted from the db due to foreign key constraints. So added 'removed' column to Pod table host_pod_ref
- Now on deleting a pod, the pod will be marked as removed and pod name is set to null.
The OOME is due to when server reading the data, it would try to adjust the
reading buffer size according to the "packet length" it read. But if the "packet
length" is some random numbers, server would still try to allocate a part of
very big memory for the reading buffer, result in OOM.
This patch add a 64k limit to sending/receiving the packet. It's the maximum
length one IP datagram can support, and we don't think the request can exceed
this limit. Even if exceed the limit in normal condition, we would aware of it
due to the exception.
Solution has been verified using wget and telnet.
status 4387: resolved fixed
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.
- In the upgrade, new XenServer template entry was added in vm_template having id=100
- However we already have another System VM XenServer template downloaded in the upgrade process that gets different id.
- SSVM could not start because the vm_instance's templateId after the upgrade was set to '100' with the assumption that the Xenserver template with id=100 will be used.
Fix to upgrade script is:
- we should not insert any entry in vm_template table for XenServer systemVM via the upgrade DB script. The latest XenServer template will get added in the upgrade process having name 'routing-xenserver-2.2.4'.
- we should update the system VM's template_id in vminstance table to point to this ''routing-xenserver-2.2.4' template.
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.
prachi
Sheng Yang
abhishek
alena
anthony
Abhinandan Prateek
nit
Jessica Tomechak
Edison Su
will
Jessica Wang
Nikita
Frank
Murali Reddy
Alex Huang
Kelven Yang