[Users] OVZ 7 beta - ploop backup fully functional?

[jjs - mainphrame]

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 at 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 at 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 at 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 <jjs at 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 at 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 at 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 at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/users/attachments/20151104/8958d0d5/attachment.html>