Troubleshooting a Restore of an OpenVZ Image from one Host Node to Another

I hadn’t tried this before but I figured I could use vzdump to save a Virtual Environment aka. (VE) from one Host Node aka. (HN) and restore it to another Host Node. It turns out that you can do this but there is one gotcha that I wasted couple of hours on, so this post is my attempt to hopefully save someone else a couple of hours and also as a beacon for myself the next time I run into this and forget how to work around it.

Firstly I have 2 OpenVZ servers. One has 4 GB of RAM and the 2nd has 1 GB. I started off using vzdump to create a backup of one of my VEs running on the 4 GB HN. I then restored the backed up VE using vzdump on the 1 GB HN. Everything went smoothly up to this point, until I ran the vzlist -a command on the 1 GB HN and was presented with this message:

1
2
3
4
5
6

% vzlist -a
Warning: too large value for PHYSPAGES=0:9223372036854775807 was truncated
Warning: too large value for VMGUARPAGES=33792:9223372036854775807 was truncated
Warning: too large value for OOMGUARPAGES=26112:9223372036854775807 was truncated
      CTID      NPROC STATUS  IP_ADDR         HOSTNAME                        
       201          - stopped 192.168.1.201   flanders.bubba.net

I had never seen this message before and it appeared to be benign in terms of the VE being able to start/stop, but messages like this really get under my skin, so of course I had to burn a few hours to figure out why. There wasn’t really much in the way of blog posts or forum posts either, which kind of surprised me.

To start I researched what these 3 parameters actually controlled.

I then poked around and noticed that the /etc/vz/conf/0.conf file on the 1 GB HN looked like this:

1
2
3
4
5
6
7
8
9
10

% more /etc/vz/conf/0.conf 
# This is configuration file for VE0.
# Only UB parameters are processed
#
# Copyright (C) 2006-2008, Parallels, Inc. All rights reserved.
 
ONBOOT="no"
 
# UBC parameters (in form of barrier:limit)
OOMGUARPAGES="2147483647:2147483647"

While on the 4 GB HN system it looked like this:

1
2
3
4
5
6
7
8
9
10

% more /etc/vz/conf/0.conf 
# This is configuration file for VE0.
# Only UB parameters are processed
#
# Copyright (C) 2006-2008, Parallels, Inc. All rights reserved.
 
ONBOOT="no"
 
# UBC parameters (in form of barrier:limit)
OOMGUARPAGES="9223372036854775807:9223372036854775807"

It then dawned on me that the barrier portion of these parameters was the problem. The barrier is the number that comes after the colon in these lines:

1
2
3

Warning: too large value for PHYSPAGES=0:9223372036854775807 was truncated
Warning: too large value for VMGUARPAGES=33792:9223372036854775807 was truncated
Warning: too large value for OOMGUARPAGES=26112:9223372036854775807 was truncated

So a quick change of all the values from 9223372036854775807 to 2147483647 fixed the problem.

This post doesn’t even scratch the surface of all the nuts and bolts of memory management ins and outs within OpenVZ. For more info about OpenVZ memory management you might want to check out these useful links:

• Good explanation of the mechanics behind oomguarpages, privvmpages, and physpages
• OpenVZ Resource Management Parameters Example

• Definition of OpenVZ parameters
• Definition of parameter: vmguarpages
• Definition of parameters: oomguarpages & privvmpages