On 11/04/2015 10:16 AM, jjs - mainphrame wrote:
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
For this particular thing there might be a couple of issues filed and
being worked on, please
search Jira.
The ghost file limit is set in CRIU by
--ghost-limit size specify maximum size of deleted file contents
to be carried inside an image file
Although I'm not aware how to pass this flag from vzctl.
Also I saw some on-going work about migrating such deleted files outside
of image (to improve migrate frozen time).
Again, it's either on Jira or on devel@ list (or perhaps both).
(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 <http://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
This shouldn't bother you as far as I understand as seccomp is not being
used.
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
For this I hope CRIU guys can shed more light (ccing CRIU list)
[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
<mailto: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
_______________________________________________
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users
