<div dir="ltr">Glad it works for you :)<div><br></div><div>--Saied</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 18, 2015 at 12:59 PM, Hui Kang <span dir="ltr"><<a href="mailto:hkang.sunysb@gmail.com" target="_blank">hkang.sunysb@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Hi, Saied,<br></div>Thanks. It works perfectly.<span class="HOEnZb"><font color="#888888"><br><br></font></span></div><span class="HOEnZb"><font color="#888888">- Hui</font></span><div><div class="h5"><br><div><div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 17, 2015 at 11:52 AM, Saied Kazemi <span dir="ltr"><<a href="mailto:saied@google.com" target="_blank">saied@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Haven't looked at your problem in any detail, just sharing a thought...<br></div><div><br></div>Is the veth end in the global namespace in a bridge? Docker containers, for example, have one end of the veth device in the container namespace and the other end in the global namespace's bridge (docker0). We extended the --veth-pair option to accept the @bridge string appended to its argument so that it would move the veth end to the specified bridge during restore. It also makes sure the interface is up.<div><br></div><div>You can see the commit message of 296129295 for additional details and try this option if it applies to your case.</div><span><font color="#888888"><div><br></div><div>--Saied<br></div><div><br></div><div><br></div><div><br><div><div><br></div><div><br></div></div></div></font></span></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Sun, Aug 16, 2015 at 12:12 PM, Hui Kang <span dir="ltr"><<a href="mailto:hkang.sunysb@gmail.com" target="_blank">hkang.sunysb@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr"><div><div>Hi, Pavel<br></div>I used "--veth-pair veth101=veth100" when dumping and restoring a process. veth101 is the device name in the process net namespace, veth100 is the other end which is in the criu host.<br><br>After restore, I can see the ip address of veth101 is restored. However, the veth end in the host (veth100) is not successfully restored. By "not success", I mean the veth100 link is created, however, its state is DOWN and no IP is assigned to the restore link. Only I manually set the link state to UP and assigne IP, the two ends can talk to each other.<br>Moreover, the link index of veth100 is not the same as when I dump the process. For example the index for veth101 and veth100 is 15 and 16 when I dump the process. After restore, veth100's index becomes 17. Is this a bug in CRIU? Thanks.<br><br></div><div><br></div>- Hui<br><div><div><div><div><div><div><div><div class="gmail_extra"><br></div><div class="gmail_extra">Part of the restore log is below. It looks like veth100 failed to restore on host due to RTNETLINK file exists. But after dump the process, I do not see veth100 in the host.<br><br>(00.004652) 1: Restoring link lo type 1<br>(00.005715) 1: Restoring link veth101 type 2<br>(00.005743) 1: Restoring netdev veth101 idx 33<br>(00.005754) 1: Restore ll addr (62:../6) for device<br>(00.006534) 1: DEBUG Skip veth101/accept_local, val =0<br>(00.006562) 1: DEBUG Skip veth101/accept_redirects, val =1<br>(00.006574) 1: DEBUG Skip veth101/accept_source_route, val =1<br>(00.006584) 1: DEBUG Skip veth101/arp_accept, val =0<br>(00.006594) 1: DEBUG Skip veth101/arp_announce, val =0<br>(00.006604) 1: DEBUG Skip veth101/arp_filter, val =0<br>(00.006614) 1: DEBUG Skip veth101/arp_ignore, val =0<br>(00.006624) 1: DEBUG Skip veth101/arp_notify, val =0<br>(00.006633) 1: DEBUG Skip veth101/bootp_relay, val =0<br>(00.006644) 1: DEBUG Skip veth101/disable_policy, val =0<br>(00.006653) 1: DEBUG Skip veth101/disable_xfrm, val =0<br>(00.006664) 1: DEBUG Skip veth101/force_igmp_version, val =0<br>(00.006674) 1: DEBUG Skip veth101/forwarding, val =1<br>(00.006683) 1: DEBUG Skip veth101/igmpv2_unsolicited_report_interval, val =10000<br>(00.006693) 1: DEBUG Skip veth101/igmpv3_unsolicited_report_interval, val =1000<br>(00.006703) 1: DEBUG Skip veth101/log_martians, val =0<br>(00.006712) 1: DEBUG Skip veth101/medium_id, val =0<br>(00.006722) 1: DEBUG Skip veth101/promote_secondaries, val =0<br>(00.006733) 1: DEBUG Skip veth101/proxy_arp, val =0<br>(00.006742) 1: DEBUG Skip veth101/proxy_arp_pvlan, val =0<br>(00.006752) 1: DEBUG Skip veth101/route_localnet, val =0<br>(00.006762) 1: DEBUG Skip veth101/rp_filter, val =1<br>(00.006772) 1: DEBUG Skip veth101/secure_redirects, val =1<br>(00.006782) 1: DEBUG Skip veth101/send_redirects, val =1<br>(00.006793) 1: DEBUG Skip veth101/shared_media, val =1<br>(00.006803) 1: DEBUG Skip veth101/src_valid_mark, val =0<br>(00.006814) 1: DEBUG Skip veth101/tag, val =0<br>(00.006864) 1: Running ip addr restore<br>RTNETLINK answers: File exists<br>RTNETLINK answers: File exists<br>:<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 3, 2015 at 10:20 AM, Pavel Emelyanov <span dir="ltr"><<a href="mailto:xemul@parallels.com" target="_blank">xemul@parallels.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 07/31/2015 05:25 PM, Hui Kang wrote:<br>
> Thanks for pointing out this option. I tested it to checkpoint and restore my program. It seems that dumping is successful, but the restore fails. The detailed log message is as follows<br>
><br>
> veth100: the link in the host''s namespace<br>
> veth101: the link in the child process''s namespace<br>
><br>
> # criu dump -t 3737 -vvvv --veth-pair veth101=veth100 -j<br>
><br>
> ...<br>
> (00.043143) Dumping pstree (pid: 3737)<br>
</span><span>> (00.092334) Writing stats<br>
> (00.092545) Dumping finished successfully<br>
><br>
><br>
> # criu restore -vvvv --veth-pair veth101=veth100<br>
</span><span>> (00.043539) 1: Error (tty.c:333): tty: Found slave peer index 2 without correspond master peer<br>
<br>
</span>The -j option should be used on restore too.<br>
<br>
</blockquote></div><br></div></div></div></div></div></div></div></div></div>
<br></div></div><span>_______________________________________________<br>
CRIU mailing list<br>
<a href="mailto:CRIU@openvz.org" target="_blank">CRIU@openvz.org</a><br>
<a href="https://lists.openvz.org/mailman/listinfo/criu" rel="noreferrer" target="_blank">https://lists.openvz.org/mailman/listinfo/criu</a><br>
<br></span></blockquote></div><br></div>
</blockquote></div><br></div></div></div></div></div></div></div></div>
</blockquote></div><br></div>