[Users] how to ignore "Dump file /vz/dump/Dump.3030 exists, trying to restore from it"?

Benjamin Henrion bh at udev.org
Wed Jul 24 03:49:47 EDT 2013


On Tue, Jul 16, 2013 at 3:17 AM, Kir Kolyshkin <kir at openvz.org> wrote:
> On 15 July 2013 05:29, Benjamin Henrion <bh at udev.org> wrote:
>>
>> Hi,
>>
>> Any idea how to ignore "Dump file /vz/dump/Dump.3030 exists, trying to
>> restore from it"?
>
>
> Well, it is ignored. As you can see below, vzctl start found the dump file
> and tried restoring
> from it (instead of starting from scratch). Since restoring failed, vzctl
> started the container
> in a usual manner.
>
>>
>>
>> If I do not set the avlue DUMPDIR in /etc/vz/vz.conf, does it ignores
>> this dump file?
>
>
> No, in this case a built-in dumpdir value is used as far as I remember.
> Check the sources to find out for sure.
>
>>
>>
>> I had to remove the file by hand to rescue my vz.
>
>
> What do you mean? As I explained above (and as you can see below) container
> is still started, with vzctl start ignoring the unsuccessful restore
> attempt.
>
>>
>>
>> * 14:22 root at hn /vz/dump# vzctl restart 3030
>> Restarting container
>> Stopping container ...
>> Container was stopped
>> Container is unmounted
>> Dump file /vz/dump/Dump.3030 exists, trying to restore from it
>> Restoring container ...
>> Container is mounted
>>         undump...
>> Setting CPU units: 1000
>> Setting CPUs: 16
>> Configure veth devices: veth303.1 veth303.0 veth303.2
>> Adding interface veth303.1 to bridge vzbr0 on CT0 for CT3030
>> Adding interface veth303.0 to bridge vzbr0 on CT0 for CT3030
>> Adding interface veth303.2 to bridge vzbr0 on CT0 for CT3030
>> Error: undump failed: No such file or directory
>> Restoring failed:
>> Error: rst_open_file: failed to lookup path '/var/nagios/nagios.lock': -2
>> Error: can't open file /var/nagios/nagios.lock
>> Error: rst_file: -2 753032
>> Error: rst_files: -2
>> Error: make_baby: -2
>> Error: rst_clone_children
>> Error: make_baby: -2
>> Error: rst_clone_children
>> Container restore failed
>> Starting container...
>> Setting CPU units: 1000
>> Setting CPUs: 16
>> Configure veth devices: veth303.1 veth303.0 veth303.2
>> Adding interface veth303.1 to bridge vzbr0 on CT0 for CT3030
>> Adding interface veth303.0 to bridge vzbr0 on CT0 for CT3030
>> Adding interface veth303.2 to bridge vzbr0 on CT0 for CT3030
>> Container start in progress...
>>
>> * 14:23 root at hn /vz/dump# rm /vz/dump/Dump.3030
>>
>> * 14:24 root at hn /vz/dump# vzctl restart 3030
>> Restarting container
>> Stopping container ...
>> Container was stopped
>> Container is unmounted
>> Starting container...
>> Container is mounted
>> Setting CPU units: 1000
>> Setting CPUs: 16
>> Configure veth devices: veth303.1 veth303.0 veth303.2
>> Adding interface veth303.1 to bridge vzbr0 on CT0 for CT3030
>> Adding interface veth303.0 to bridge vzbr0 on CT0 for CT3030
>> Adding interface veth303.2 to bridge vzbr0 on CT0 for CT3030
>> Container start in progress...
>>
>> * 14:24 root at hn-a231 /vz/dump#
>
>
>
> Which vzctl version is that? (Yes, please, whenever you are talking about
> vzctl, specify its version)
>
> I remember that some recent version deletes a dump file on start in any
> case, because:
>  - if a container is restored from that file, it is no longer needed;
>  - if a container can't be restored from that file, it is a bad file.
>
> This functionality appears in vzctl 4.3, as noted in its changelog:
>
>> vzctl start: remove dumpfile on successful start
>
> For the reference, the git commit in question is this one:
>  http://git.openvz.org/?p=vzctl;a=commitdiff;h=eca2ff0

Just setting:

VE_STOP_MODE="stop" in /etc/vz/vz.conf

seems to be enough to get rid of Suspend mode.

--
Benjamin Henrion <bhenrion at ffii.org>
FFII Brussels - +32-484-566109 - +32-2-3500762
"In July 2005, after several failed attempts to legalise software
patents in Europe, the patent establishment changed its strategy.
Instead of explicitly seeking to sanction the patentability of
software, they are now seeking to create a central European patent
court, which would establish and enforce patentability rules in their
favor, without any possibility of correction by competing courts or
democratically elected legislators."


More information about the Users mailing list