[CRIU] [SOLVED] Re: [Users] OVZ 7 beta - ploop backup fully functional?

Fri Nov 6 10:11:08 PST 2015

Greetings -

I am pleased to report that after today's kernel update to the OVZ 7
factory box, I was able to successfully dump a fully functional running
container.

[root at annie ~]# vzctl snapshot 101
Creating snapshot {4c5f6dda-f3d7-4624-aaa3-74fcf7cd602d}
Storing /vz/private/101/Snapshots.xml.tmp
        freeze
Creating image snapshot uuid={4c5f6dda-f3d7-4624-aaa3-74fcf7cd602d}
image=/vz/private/101/root.hdd
Storing /vz/private/101/root.hdd/DiskDescriptor.xml.tmp
Creating delta
/vz/private/101/root.hdd/root.hds.{505e3a22-aed0-42f8-be55-bc20b840052c}
bs=2048 size=134217728 sectors v2
Creating snapshot dev=/dev/ploop44345
img=/vz/private/101/root.hdd/root.hds.{505e3a22-aed0-42f8-be55-bc20b840052c}
ploop snapshot {4c5f6dda-f3d7-4624-aaa3-74fcf7cd602d} has been successfully
created
        dump
Checkpointing finished successfully
        unfreeze
Snapshot {4c5f6dda-f3d7-4624-aaa3-74fcf7cd602d} has been successfully
created

Regards,

Joe

On Wed, Nov 4, 2015 at 8:15 PM, Kir Kolyshkin <kir at openvz.org> wrote:

>
>
> 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 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
>
>
> 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 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
>>
>>
>
>
> _______________________________________________
> Users mailing listUsers at openvz.orghttps://lists.openvz.org/mailman/listinfo/users
>
>
>
> _______________________________________________
> CRIU mailing list
> CRIU at openvz.org
> https://lists.openvz.org/mailman/listinfo/criu
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20151106/3c7718b1/attachment-0001.html>