VPS Dedicated Servers
OpenVZ/Virtuozzo Enable Fuse in Container
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.
Have an OpenVZ VPS/Linux Virtual Private Server and nothing works right?
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.
Openvz "Container already locked" Error Message Solution/Fix
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:
- Delete the /vz/lock/VEID.lck file (where VEID is the number of your VPS).
- vzctl chkpnt VEID --kill
That's all there is to it, your VEID can now be restarted successfully.
How to Track Down/Find Cause of Linux high disk iowait/wa
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
OpenVZ backup container to a single file while it's running using "vzdump"
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.
CPanel OpenVZ VPS Error - *** Notice *** No working loopback device files found. Try running `modprobe loop` as root via ssh and running this script again.
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!
OpenVZ user_beancounters kmemsize failcnt Processes Timing Out/Doing Nothing/Zombie
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.
Canel Default VHOST DocumentRoot/Contents Directory is /usr/local/apache/htdocs
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.