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

Kir Kolyshkin kir at openvz.org
Mon Jul 15 21:17:29 EDT 2013


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/users/attachments/20130715/2ee4499a/attachment.html>


More information about the Users mailing list