Greetings,
I'm still running OVZ 7 here on 2 machines, one running beta and the other
running factory. vzctl snapshot hasn't worked on either one, but I test at
intervals to check the status. The factory machine got some updates today,
and so I tried again, and things seemed to get a bit farther before it
failed. An excerpt from near the end of the dump log contained some clues:
(00.159708) Dumping ghost file for fd 26 id 0x7c
(00.159712) Error (files-reg.c:422): Can't dump ghost file
/usr/lib64/libnss3.so;56314442 of 1220096 size, increase limit
(00.159718) Error (cr-dump.c:1314): Dump mappings (pid: 14025) failed with
-1
Are there any environment variables or command line switches I could apply
which could affect this "limit" hinted at above?
BTW - criu doesn't seem entirely happy with the ovz 7 kernel:
[root@annie ~]# uname -a
Linux annie.mainphrame.net 3.10.0-229.7.2.vz7.9.1 #1 SMP Wed Oct 21
17:55:13 MSK 2015 x86_64 x86_64 x86_64 GNU/Linux
[root@annie ~]# criu check
Error (cr-check.c:602): Kernel doesn't support PTRACE_O_SUSPEND_SECCOMP
Error (cr-check.c:719): fdinfo doesn't contain the lock field
Error (cr-check.c:749): CLONE_PARENT | CLONE_NEWPID don't work together
[root@annie ~]#
Am I tilting at windmills here, or is there some expectation that any of
this should be working?
Regards,
Joe
On Wed, Oct 28, 2015 at 2:31 PM, jjs - mainphrame <j...@mainphrame.com>
wrote:
> Greetings,
>
> I've been running some test containers on OVZ7 beta, and, while I realize
> not all functionality is in place yet, they have been so dependable that
> I'm starting to depend on them.
>
> So, understandably, I was looking at backups, and my first tries with
> vzctl snapshot failed. I don't want to spend a lot of time troubleshooting
> something that's not yet known to be working, but in case it is, has anyone
> else had better luck?
>
>
> Here is the result of my attempt to make a backup:
>
> [root@hachi vz]# vzctl snapshot 1001
> Creating snapshot {57c8aa0d-1c04-4469-9d1e-c95fab04bd01}
> Storing /local/vz/private/1001/Snapshots.xml.tmp
> Setting up checkpoint...
> Failed to checkpoint the Container
> All dump files and logs were saved to
> /local/vz/private/1001/dump/{57c8aa0d-1c04-4469-9d1e-c95fab04bd01}.fail
> Checkpointing failed
> Failed to create snapshot
> [root@hachi vz]#
>
>
> The last few lines of the dump log contain these clues:
>
> (00.570576) Error (proc_parse.c:404): Can't handle non-regular mapping on
> 8366's map 7f2164d63000
> (00.570582) Error (cr-dump.c:1487): Collect mappings (pid: 8366) failed
> with -1
> (00.570746) Unlock network
> (00.570751) Running network-unlock scripts
>
>
> There is no pid 8366 in the CT but on the host that pid corresponds to the
> mysql instance running in the container that I'm trying to snapshot:
>
> [root@hachi vz]# ps -ef|grep 8366
> 27 8366 7098 0 14:03 ? 00:00:00 /usr/libexec/mysqld
> --basedir=/usr --datadir=/var/lib/mysql
> --plugin-dir=/usr/lib64/mysql/plugin
> --log-error=/var/log/mariadb/mariadb.log
> --pid-file=/var/run/mariadb/mariadb.pid --socket=/var/lib/mysql/mysql.sock
>
> So, is this something that ought to work?
>
> Regards,
>
> Joseph
>
>
_______________________________________________
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users
