<div dir="ltr"><div>Hi Tycho.</div><div><br></div><div>It's been on a to-do list to file a bug for this limit, but I hadn't gotten around to it. </div><div><br></div><div>You can see the size indications in the messages below -<br></div><div><br></div><div>root@olympia:~# lxc list</div><div>+--------+---------+-----------------------+------+------------+-----------+</div><div>| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |</div><div>+--------+---------+-----------------------+------+------------+-----------+</div><div>| akita | RUNNING | 192.168.111.22 (eth0) | | PERSISTENT | 0 |</div><div>+--------+---------+-----------------------+------+------------+-----------+</div><div>| kangal | RUNNING | 192.168.111.44 (eth0) | | PERSISTENT | 0 |</div><div>+--------+---------+-----------------------+------+------------+-----------+</div><div>root@olympia:~# lxc move akita lxd1:</div><div>error: Error transferring container data: checkpoint failed:</div><div>(02.064728) Error (files-reg.c:683): Can't dump ghost file /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21 of 1566440 size, increase limit</div><div>(02.064730) Error (cr-dump.c:1356): Dump mappings (pid: 4685) failed with -1</div><div>(02.068126) Error (cr-dump.c:1600): Dumping FAILED.</div><div>root@olympia:~# lxc move kangal lxd1:</div><div>error: Error transferring container data: checkpoint failed:</div><div>(14.495544) Error (files-reg.c:683): Can't dump ghost file /usr/lib/x86_64-linux-gnu/libxml2.so.2.9.1 of 1465592 size, increase limit</div><div>(14.495547) Error (cr-dump.c:1356): Dump mappings (pid: 11956) failed with -1</div><div>(14.500840) Error (cr-dump.c:1600): Dumping FAILED.</div><div>root@olympia:~# </div><div><br></div><div>Regards,</div><div><br></div><div>Jake</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 22, 2016 at 8:04 AM, Tycho Andersen <span dir="ltr"><<a href="mailto:tycho.andersen@canonical.com" target="_blank">tycho.andersen@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, Jun 21, 2016 at 09:27:21AM -0700, jjs - mainphrame wrote:<br>
> That particular error was resolved, but the lxc live migration doesn't work<br>
> for a different reason now. We now get an error that says "can't dump ghost<br>
> file" because of apparent size limitations - a limit less than the size of<br>
> any lxc container we have running here.<br>
<br>
</span>How big is the ghost file that you're running into and what<br>
application is it from? Perhaps we should just increase the default<br>
limit.<br>
<span class="HOEnZb"><font color="#888888"><br>
Tycho<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> (In contrast, live migration on all of our Openvz 7 containers works<br>
> reliably)<br>
><br>
> Jake<br>
><br>
><br>
><br>
><br>
> On Tue, Jun 21, 2016 at 4:19 AM, McDonagh, Ed <<a href="mailto:Ed.McDonagh@rmh.nhs.uk">Ed.McDonagh@rmh.nhs.uk</a>><br>
> wrote:<br>
><br>
> ><br>
> ><br>
> > > On Tue, Mar 29, 2016 at 09:30:19AM -0700, jjs - mainphrame wrote:<br>
> > > > On Tue, Mar 29, 2016 at 7:18 AM, Tycho Andersen <<br>
> > > > tycho.andersen at <a href="http://canonical.com" rel="noreferrer" target="_blank">canonical.com</a>> wrote:<br>
> > > ><br>
> > > > > On Mon, Mar 28, 2016 at 08:47:24PM -0700, jjs - mainphrame wrote:<br>
> > > >> > I've looked at ct migration between 2 ubuntu 16.04 hosts today,<br>
> > and had<br>
> > > > > > some interesting problems; I find that migration of stopped<br>
> > containers<br>
> > > > > > works fairly reliably; but live migration, well, it transfers a<br>
> > lot of<br>
> > > > > > data, then exits with a failure message. I can then move the same<br>
> > > > > > container, stopped, with no problem.<br>
> > > > > ><br>
> > > > > > The error is the same every time, a failure of "mkdtemp" -<br>
> > > > ><br>
> > > > > It looks like your host /tmp isn't writable by the uid map that the<br>
> > > > > container is being restored as?<br>
> > > > ><br>
> > > ><br>
> > > > Which is odd, since /tmp has 1777 perms on both hosts, so I don't see<br>
> > how<br>
> > > > it could be a permissions problem. Surely the default apparmor profile<br>
> > is<br>
> > > > not the cause? You did give me a new idea though, and I'll set up a<br>
> > test<br>
> > > > with privileged containers for comparison. Is there a switch to enable<br>
> > > > verbose logging?<br>
> > ><br>
> > > It already is enabled, you can find the full logs in<br>
> > > /var/log/lxd/$container/migration_*<br>
> > ><br>
> > > Perhaps the pwd of the CRIU task is what's broken instead, since CRIU<br>
> > > isn't supplying a full mkdtemp template. I'll have a deeper look in a<br>
> > > bit.<br>
> > ><br>
> > > Tycho<br>
> > ><br>
> > > ><br>
> > > > > ><br>
> > > > > > root at ronnie:~# lxc move third lxd:<br>
> > > > > > error: Error transferring container data: restore failed:<br>
> > > > > > (00.033172) 1: Error (cr-restore.c:1489): mkdtemp failed<br>
> > > > > > crtools-proc.x9p5OH: Permission denied<br>
> > > > > > (00.060072) Error (cr-restore.c:1352): 9188 killed by signal 9<br>
> > > > > > (00.117126) Error (cr-restore.c:2182): Restoring FAILED.<br>
> ><br>
> > I've been getting the same error - was the issue ever resolved for<br>
> > non-privileged containers?<br>
> ><br>
> > Kind regards<br>
> > Ed<br>
> > #########################################################################<br>
> > Attention:<br>
> > This e-mail and any attachment is for authorised use by the intended<br>
> > recipient(s) only. It may contain proprietary, confidential and/or<br>
> > privileged information and should not be copied, disclosed, distributed,<br>
> > retained or used by any other party. If you are not an intended recipient<br>
> > please notify the sender immediately and delete this e-mail (including<br>
> > attachments and copies).<br>
> ><br>
> > The statements and opinions expressed in this e-mail are those of the<br>
> > author and do not necessarily reflect those of the Royal Marsden NHS<br>
> > Foundation Trust. The Trust does not take any responsibility for the<br>
> > statements and opinions of the author.<br>
> ><br>
> > Website: <a href="http://www.royalmarsden.nhs.uk" rel="noreferrer" target="_blank">http://www.royalmarsden.nhs.uk</a><br>
> > #########################################################################<br>
> > _______________________________________________<br>
> > lxc-users mailing list<br>
> > <a href="mailto:lxc-users@lists.linuxcontainers.org">lxc-users@lists.linuxcontainers.org</a><br>
> > <a href="http://lists.linuxcontainers.org/listinfo/lxc-users" rel="noreferrer" target="_blank">http://lists.linuxcontainers.org/listinfo/lxc-users</a><br>
<br>
> _______________________________________________<br>
> lxc-users mailing list<br>
> <a href="mailto:lxc-users@lists.linuxcontainers.org">lxc-users@lists.linuxcontainers.org</a><br>
> <a href="http://lists.linuxcontainers.org/listinfo/lxc-users" rel="noreferrer" target="_blank">http://lists.linuxcontainers.org/listinfo/lxc-users</a><br>
<br>
_______________________________________________<br>
lxc-users mailing list<br>
<a href="mailto:lxc-users@lists.linuxcontainers.org">lxc-users@lists.linuxcontainers.org</a><br>
<a href="http://lists.linuxcontainers.org/listinfo/lxc-users" rel="noreferrer" target="_blank">http://lists.linuxcontainers.org/listinfo/lxc-users</a></div></div></blockquote></div><br></div>