To enable Fuse to work inside a OpenVZ container it's very simple (although some people say it can't be done).

Remember that on your HN (HostNode) for OpenVZ, Fuse must be installed and the module must be loaded for this to work.  In addition remember that you need the Fuse package installed inside the container of course.

vzctl set 2000 --devices c:10:229:rw --save
vzctl exec 2000 mknod /dev/fuse c 10 229

The part that most people forget when trying to enable Fuse on OpenVZ is that the container must be restarted, otherwise you'll get this message:

fuse: mount failed: No such device

Simply restart the OpenVZ container and then things will work:

vzctl restart 2000 or you can just manually reboot from within the container.

A VPS Server I had just wasn't working right, code that I migrated there just wasn't working.  For example, it kept telling me the connection to the database was unsuccessful, halfway through iterating through results it already had.

Then I realized it wasn't my code.  I checked my /proc/user_beancounters and found this:

  cat /proc/user_beancounters
Version: 2.5
       uid  resource           held    maxheld    barrier      limit    failcnt
     2000:  kmemsize        2499074    3453079  268435456  268435456       2985
            lockedpages           0          8     999999     999999          0
            privvmpages       43361      87480    1024000    1024000          0
            shmpages            671       1647      65536      65536          0
            dummy                 0          0          0          0          0
            numproc              32         48     999999     999999          0
            physpages         10119      24142          0 2147483647          0
            vmguarpages           0          0    1024000    1024000          0
            oomguarpages      10119      24142       6144 2147483647          0
            numtcpsock            6         24    7999992    7999992          0
            numflock              8         12     999999     999999          0
            numpty                1          1     500000     500000          0
            numsiginfo            0          6     999999     999999          0
            tcpsndbuf         69316     380120  235713536  235713536          0
            tcprcvbuf         98304    1527656  235713536  235713536          0
            othersockbuf       8944     175584  235713536  235713536          0
            dgramrcvbuf           0       8380  235713536  235713536          0
            numothersock         12         32    7999992    7999992          0
            dcachesize       220365     274667 2147483646 2147483646          0
            numfile            1116       2025   23999976   23999976          0
            dummy                 0          0          0          0          0
            dummy                 0          0          0          0          0
            dummy                 0          0          0          0          0
            numiptent             5          5        128        128          0

Notice the "failcnt" for "kmemsize" is 2985.  The value was too low, in this quote it had already been corrected and after that my PHP scripts were working fine.

When things don't make sense and aren't working properly, check your "beancounters" to make sure nothing is failing.

Also remember not to instantly blame your VPS Provider, lots of times people have these problems when running intensive scripts, applications, CPanel/Plesk and it's because your plan does not have enough RAM etc...

This should be something every admin/owner of a VPS checks routinely for inexplicable problems/timeouts with your applications in a VPS Server.

OpenVZ technology is the best for performance, but the settings must be just right to avoid problems, and you must make sure you have a plan that meets your needs.  There's no such thing as swapping, if you exceed your limits, connections drop, application/database calls fail without explanation.

So just remember to pick a VPS/Virtual Private Server plan that meets you needs and monitor the beancounters for any signs of failures.

I didn't find any useful information that actually fixed this.  My VPS was in the "Running State" and I could not stop or restart it.  I kept getting "Container already locked" no matter what I did (I tried all the suggestions in the Google results for this error).

Most of the suggestions were for Windows but I only use Linux.  The other solutioins also said to restart the VZ service or even the entire hostnode and this was not acceptable to me so I wanted to find a "clean fix".

I tried to "vzctl restart VEID" and "vzctl start VEID --force" and "vzctl stop VEID --fast" with no luck.

Here is how I fixed it:

1. Delete the /vz/lock/VEID.lck file (where VEID is the number of your VPS).
2. vzctl chkpnt VEID --kill

That's all there is to it, your VEID can now be restarted successfully.

top - 09:34:12 up 2 days, 20:57,  2 users,  load average: 1.83, 1.99, 2.03
Tasks:  59 total,   2 running,  57 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.3%us,  0.0%sy,  0.0%ni,  0.0%id, 99.7%wa,  0.0%hi,  0.0%si,  0.0%st

That 99.7% wa is iowait, it means the server is waiting for a process to complete an IO operation or in plain English, there is a delay in reading and/or writing data to the hard drive.

Here are some ways to get an idea of what is going on (in RPM based Distros this package is called "sysstat") and contains the very helpful binary called "iostat".  There's another package I like called "dstat" that does a great job too.

Run iostat -d 5 (it refreshes the data every 5 seconds):

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda1              2.07         5.27        28.66    1309570    7120384
sda2              0.00         0.03         0.04       7496       8832

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda1             27.15         0.00       357.68          0       1792
sda2              0.00         0.00         0.00          0          0

What we're seeing is that the iowait must be caused primarily by blocks being written to /dev/sda1 which is mounted as / (my root filesystem).  So now we know the main cause is by an application constantly writing to the root partition, but we still don't know what process is directly responsible for this.

If you have a newer kernel it's often possible to view processes by io usage, you can test for this by running: cat /proc/self/io

If the file is not found then you don't have io stats enabled in your kernel.  Then you can check a suspected process by running cat /proc/13/io (replace the 13 with the PID you want to check).


read_bytes: 0
write_bytes: 0
cancelled_write_bytes: 0

Proxmox has made this free utility to backup running OpenVZ containers.  It's a great program which is actually just a PERL script but gets the job done.  This program is not 100% required because all it really does is cp -a from your container's path as far as I know but it is still good to have uniformity to how you backup your containers.

For RPM distros such as Centos/RHEL/Fedora etc.. download and install this:

wget http://www.proxmox.com/cms_proxmox/cms/upload/vzdump/vzdump-1.1-2.noarch.rpm; rpm -ivh vzdump-1.1-2.noarch.rpm

For Debian based distros like Ubuntu etc.. download and install this:

wget http://www.proxmox.com/cms_proxmox/cms/upload/vzdump/vzdump_1.1-2_all.deb; dpkg -i vzdump_1.1-2_all.deb

vzdump options

 vzdump --help
Unknown option: help
usage: /usr/sbin/vzdump OPTIONS [--all | VPSID]

        --exclude VPSID         exclude VPSID (assumes --all)
        --exclude-path REGEX    exclude certain files/directories
        --stdexcludes           exclude temorary files and logs

        --compress              compress dump file (gzip)
        --dumpdir DIR           store resulting files in DIR
        --tmpdir DIR            store temporary files in DIR

        --mailto EMAIL          send notification mail to EMAIL.
        --quiet                 be quiet.
        --stop                  stop/start VPS if running
        --suspend               suspend/resume VPS when running
        --snapshot              use LVM snapshot when running
        --size MB               LVM snapshot size

        --node CID              only run on pve cluster node CID
        --lockwait MINUTES      maximal time to wait for the global lock
        --stopwait MINUTES      maximal time to wait until a VM is stopped
        --bwlimit KBPS          limit I/O bandwidth; KBytes per second

        --restore FILENAME      restore FILENAME

Real Life Usage To Dump/Backup an OpenVZ Container

*note that since I chose --compress (why not compress right?) that the file will actually be:

vzdump-5000.tgz

vzdump --compress 5000
INFO: Starting new backup job - vzdump --compress 5000
INFO: Starting Backup of VM 2000 (openvz)
INFO: status = CTID 5000 exist mounted running
WARN: online backup without stop/suspend/snapshot
WARN: this can lead to inconsistent data
INFO: creating archive '/vz/dump/vzdump-5000.dat' (/vz/private/5000)

To Restore The OpenVZ Backup

vzrestore /vz/dump/vzdump-5000.tgz 5000

*note that if you specify something different eg. 10000 as the VPSID it will restore to that container.

I have no idea how to get the loopback device working in OpenVZ, but what's more frustrating is that I purchased a CPanel license for my VPS and clearly it is not "VPS Optimized".  Although everything does seem to work at this point despite that error.

The suggestions here: http://forum.openvz.org/index.php?t=msg&goto=1339 don't seem to work at all.  This is an OpenVZ issue, but also a CPanel isue, why on earth would loopback support be expected in a VPS and why would CPanel need this?

It also makes me want to stick with Plesk exclusively, at least they have  well designed and thought out Control Panel.  I can't believe CPanel looks like it was designed by hackers from the 90's!

cat /proc/user_beancounters produces the following:

kmemsize        1861537    5139870   12752512   12752512   26965041

Notice the failcnt "26965041", that is for kmemsize and at first it confused me.  The system had enough guaranteed and enough burst RAM available.  kmemsize is a variable indepedent of that, but who cars about the explanation right, let's just make things work.  I was installing CPanel and wondered why the install process was taking forever until I checked my beancounters:

The solution is to of course increase kmemsize, in many cases you'll want to double, triple or even quadruple it.  Also note it's bad that my barrier and limits are the same, so I've arbitrarily changed the limit in the example below.  I can't remember the consequences but I read certain processes will get killed if the server runs out of memory.

vzctl set vpsid --kmemsize $((1275251*4)):$((1875251*4)) --save

The above increased my kmemsize allowances by 4x and should keep everything good.  In my opinion tihs is a silly feature and should be more tuned/controlled by the guaranteed memory allocation in OpenVZ.

This can be very annoying and CPanel doesn't seem to document it, or it's not found or made as obvious as it should be.  It's always funny when I find it more difficult to work with a control panel than to do everytihng manually without CPanel or even Plesk.

So once again, the default serve path for contents is: /usr/local/apache/htdocs and this is especially applicable when accessing Apache by just an IP which is unbound to any domain at this point.