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

Fri Dec 11 19:05:04 PST 2015

I'm happy to report that, with this latest round of updates, vzctl snapshot
now also works on my OVZ 7 beta machine as well -

Joe

On Fri, Nov 6, 2015 at 10:11 AM, jjs - mainphrame <jjs at mainphrame.com>
wrote:

> 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/20151211/5a1f5e65/attachment.html>