On 15 July 2013 05:29, Benjamin Henrion <[email protected]> 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@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@hn /vz/dump# rm /vz/dump/Dump.3030 > > * 14:24 root@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@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
_______________________________________________ Users mailing list [email protected] https://lists.openvz.org/mailman/listinfo/users
