You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I did Podman container live migration to another machine using Podman checkpoint/restore with "--tcp-established" argument. My question: is there a way to redirect an opened TCP connection to the new destination machine? I tested iptables forwarding and ssh tunneling but established tcp client hanged when i installed the forwarding rules. I want to have seamless live migration so already established tcp connection continue on the new server. The client connects to a gateway linux and this gw redirects traffic to the intended server. And when live migration happens, the gateway will redirect the client traffic to the new server location. The client uses the gateway IP as destination IP. This works for new tcp connections but not for already established tcp connections. Usually for Nat or similar there are rules which only react on new connections with syn set. Maybe we need different rules for existing connections (unset syn for established state)?
To make a Linux machine acts as Gateway, i used iptables with the following rules:
echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination x.x.x.x:80
iptables -t nat -A POSTROUTING -j MASQUERADE)
x.x.x.x is the destination of the migration ip
Steps to reproduce the issue:
1. Send GET request to a webserver for a big file size
2. In the middle of the transfer, do live migration using commit_cmd = 'sudo podman container checkpoint %s --export=/tmp/%s.tar.gz --tcp-established' % (container, container, )
3. scp /tmp/%s.tar.gz to the destination of migration
4. And restore: restore_cmd = "sudo podman container restore --import=%s%s.tar.gz --tcp-established" % (remote_path, container, )
5. Run the above rules to make the middle man acts as a gateway
Describe the results you received:
I ran tcpdump; it seems there is no redirection happened for already established connection. Redirection only happened for new connections.
Redirection worked for new tcp connections but not for already established tcp connections.
The clients hanged when they are on established tcp state after checkpoint/restore steps.
Describe the results you expected:
Redirection works for established tcp connections. Clients continue the tcp connection with the new migrated server.
The text was updated successfully, but these errors were encountered:
I did Podman container live migration to another machine using Podman checkpoint/restore with "--tcp-established" argument. My question: is there a way to redirect an opened TCP connection to the new destination machine? I tested iptables forwarding and ssh tunneling but established tcp client hanged when i installed the forwarding rules. I want to have seamless live migration so already established tcp connection continue on the new server. The client connects to a gateway linux and this gw redirects traffic to the intended server. And when live migration happens, the gateway will redirect the client traffic to the new server location. The client uses the gateway IP as destination IP. This works for new tcp connections but not for already established tcp connections. Usually for Nat or similar there are rules which only react on new connections with syn set. Maybe we need different rules for existing connections (unset syn for established state)?
To make a Linux machine acts as Gateway, i used iptables with the following rules:
echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination x.x.x.x:80
iptables -t nat -A POSTROUTING -j MASQUERADE)
x.x.x.x is the destination of the migration ip
Steps to reproduce the issue:
Describe the results you received:
I ran tcpdump; it seems there is no redirection happened for already established connection. Redirection only happened for new connections.
Redirection worked for new tcp connections but not for already established tcp connections.
The clients hanged when they are on established tcp state after checkpoint/restore steps.
Describe the results you expected:
Redirection works for established tcp connections. Clients continue the tcp connection with the new migrated server.
The text was updated successfully, but these errors were encountered: