Live migration of floating ip addresses and conntrack entries in multi-host mode
There are obvious downtime in live migration of floating ip addresses now. This is not acceptable.
After live migration a instance from the source node to a destination node, instance's connection tracking entries are still on the source node. Security group rules are stateful.Without connection tracking entries on the new node, security group will not work as needed.
We will add new features to fix the above problems.
Blueprint information
- Status:
- Complete
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- None
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- Obsolete
- Series goal:
- None
- Implementation:
-
Not started
- Milestone target:
- None
- Started by
- Completed by
- Jian Wen
Related branches
Related bugs
Sprints
Whiteboard
First new packet which is not SYN sent to migrated instance is not marked as INVALID in conntrack.
I made a mistake about this behaviour. It's really confusing.
Instead it will be ACCEPT by securiy group on the new compute node (This is why you can establish a connetion before live migration).
So we don't need to migrate conntrack entries. -- Jian Wen
If a instance uses its own public ip address to connect to a host such as google.com, we need to migrate the related conntrack entries. Because the new packet sent from google.com will get dropped on the migrated instance's host, if conntrack didn't see packet sent from the instance first or no security group rule ACCEPT the packet. --Jian Wen
It looks like this was related: https:/
No, that commit solves only a problem where VM migrates back to the host from which it migrated away at some point in time. -- ivoks
