vzctl start: fix starting non-vswap CT migrated from old 32-bit host
This is a dirty hack required for non-vswap CT configs produced by
vzctl < 3.0.29 on a 32-bit host which then were used on a 64-bit host.
Without it, one gets this error trying to start such a CT:
# vzctl start $VEID
Error: required UB parameter swappages not set
This happens because CT config contains the following line:
PHYSPAGES="0:2147483647"
and vzctl treats this config as vswap enabled.
The initial problem is LONG_MAX is different on 32 bit and 64 bit hosts
(equal to 2147483647 and 9223372036854775807, respectively). So when we
migrate the container from 32 bit to 64 bit system, the 32 bit LONG_MAX
value which was treated as unlimited is now not treated in a special way.
This problem was addressed sequentially, here are a few bits of history.
1. Since vzctl-3.0.19 (commit 635f13ee) one can specify the word 'unlimited'
instead of a numeric value.
2. Since vzctl-3.0.26 (commit 3866be1b) the sample configs are using this,
so they have PHYSPAGES="0:unlimited".
3. Since vzctl-3.0.29 (commit acaf07f9) the value of LONG_MAX is saved
to CT config as 'unlimited'.
Now consider the following scenario:
1. We have 32-bit host with vzctl < 3.0.29 and CT config having line
PHYSPAGES="0:2147483647"
2. We migrate this container to 64 bit host with vzctl-3.0.30.
3. We try to start this container.
vzctl thinks that this is vswap-enabled config, complains about absent
swappages parameter and fails to start CT.
The fix is to modify is_vswap_config() to treat 32-bit LONG_MAX (== INT_MAX)
as unlimited.
Fixes http://bugzilla.openvz.org/2138
Reported-by: Sergey Turchaninov <Sadistt0@gmail.com>
Signed-off-by: Kir Kolyshkin <kir@openvz.org>
1 file changed