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

[Kirill Kolyshkin]

On 24 July 2013 00:49, Benjamin Henrion <bh at udev.org> wrote:

> 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.



That is right, but it was not what you were asking about.

Also, I have answered all your questions, could you please answer mine?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/users/attachments/20130724/f00512d6/attachment.html>