OpenVZ, as most of us know, has taken the field of computer virtualisation by storm. In this article, I will discuss its various aspects and how to implement it with your infrastructure, in order to create virtual machines within minutes. These machines will be isolated from one another and only the host machine will have full control over them. I will walk you through the steps of getting OpenVZ up and running on a CentOS 6 server, along with a few configuration tweaks.
What is OpenVZ?
OpenVZ is open source virtualisation technology with which you can create one or more self-contained operating systems, isolated from one another, but which behave just like standalone systems or servers. For the more technically oriented, it is a framework that is used to divide or share the host servers resources among self-contained virtual containers, which share the host machines patched kernel in order to run.
How is OpenVZ different from KVM?
KVM stands for Kernel based Virtual Machine, also referred to as full virtualisation. It is used to create totally isolated virtual machines, which contain their own kernels and own dedicated resources such as disks, graphics cards, network cards, etc. Virtual KVM servers behave like completely isolated environments.
OpenVZ is container based virtualisation, in which the resources of the host machine are shared among a number of virtual containers.
This is the main reason why OpenVZ can create only Linux based virtual machines (VMs) whereas KVM can create virtual servers that are based on Linux, Windows, BSD, Solaris, etc, because they are self-contained, have their own resources, and do not need to rely on the host machine. Although KVM also must be installed on a Linux box, it can have other OSs as guest machines, as mentioned above.
Because of this full virtualisation, KVM generally has much more overhead than OpenVZ containers, which makes OpenVZ pretty fast compared to KVM. All in all, choosing between OpenVZ and KVM should depend on what you are going to run on the virtual server. Given below are some comparisons that you could consider when making a choice.
1. You want the server to host your PHP/MySQL application:
Go with OpenVZ, as your application must be fast enough to cater to the requests of your clients – an OpenVZ based container is a far better choice in this case.
2. You are more comfortable with Windows than Linux:
There is no option in this case; you have to go with KVM because OpenVZ does not provide cross-platform virtualisation.
3. You are hosting a Java based application on a JBoss server:
Go with KVM because of the extra load a Java application will create on the host machine. In OpenVZ, this load can be mistaken as a misuse or abuse by the provider, resulting in the suspension of your container.
4. You need a Linux machine for testing and need it quick:
Go for OpenVZ as containers can be created within seconds. Later in this article you will see how this is possible.
5. You need a network device, or access to the kernel for adding/loading certain modules:
Go with KVM, because it has its own dedicated kernel to which you will have access. You can load any module you like. OpenVZ is not an ideal choice in this case because if you want a certain module to be loaded, you will have to contact your provider, who will decide whether or not to load the specific module for you, depending upon various factors.
Everything depends on your needs, so choose wisely!
So how do you get very cheap servers these days?
This is one of the most frequently asked questions (FAQs) I get from the readers of my blog and the answer is: virtualisation. Instead of providing dedicated hardware to consumers, providers make use of one virtualisation technique or the other, and divide the same physical machine into numerous self-contained servers. Consumers can run various applications on these servers, such as a blog, purchase/lease these servers with shared resources at very low prices. This is a win-win situation for the consumer as well as the provider, in most cases. The consumer gets a dedicated and isolated server with full root user access, and the provider leases a part of the dedicated server at a low cost.
You might ask how this is different from normal Web hosting. Well, first of all, you do not get shell access to a shared hosting server, let alone the root level access. Second, the performance you get with Web hosting accounts ranks very low compared to what you get from a virtualised server.
A good place to start the search for cheap virtual servers is http://lowendbox.com/
Prerequisites
In this section, we will go through the prerequisites on the host system in order to run OpenVZ successfully and efficiently. In the following sections, we will get our host to run the OpenVZ kernel instead of the stock kernel, followed by some configuration changes and, finally, create a new virtual machine (container) along with some configuration.
I have jotted down some key requisites below:
1. A server based on Red Hat Enterprise Linux 6. This includes CentOS 6, RHEL 6, Scientific Linux 6 — basically any Linux OS that is a derivative of RHEL 6 should work, although I have tested this set-up with RHEL 6 and CentOS 6 only.
2. Minimum 4GB RAM: I recommend this because the system itself needs to have some free RAM, let alone the VMs you will create within.
3. A 100GB hard disk.
4. SELinux set to Off.
echo SELINUX=disabled > /etc/sysconfig/selinux
5. OpenVZ YUM repository installed.
# cd /etc/yum.repos.d/ # wget http://download.openvz.org/openvz.repo # rpm --import http://download.openvz.org/RPM-GPG-Key-OpenVZ # yum clean all
Installation
Installation of OpenVZ is facilitated by installing a patched kernel, which is provided by openvz.org. Run the following commands to get this set-up:
# yum list vzkernel
This will list all the available OpenVZ kernels from the repository. Choose the one that you want to install according to your server operating system architecture:
# yum install vzkernel -y
This should also update the GRUB (bootloader) entry, but I recommend you cross-check that the vzkernel is booted by default every time the system restarts. Open /boot/grub/menu.lst with your favourite text editor, and make sure the value of default is set to 0 and the title OpenVZ (kernel-version) is on the top of the various lists of available kernels. Refer to Figure 1.
If you are using a different bootloader (such as syslinux), then check the configuration file accordingly.
Before rebooting the host server, install a few other goodies that are needed in order to create/manage the containers:
# yum install vzctl vzquota ploop -y
Next, edit the /etc/sysctl.conf file and make sure you have the following parameters defined:
net.ipv4.ip_forward = 1 net.ipv4.conf.default.proxy_arp = 0 net.ipv4.conf.all.rp_filter = 1 kernel.sysrq = 1 net.ipv4.conf.default.send_redirects = 1 net.ipv4.conf.all.send_redirects = 0 net.ipv4.icmp_echo_ignore_broadcasts=1 net.ipv4.conf.default.forwarding=1
To load these parameters, run sysctl -p.
This completes the basic installation of OpenVZ and on the next reboot, you will have an OpenVZ server, which is ready to create virtual machines.
Creating your first container (virtual machine)
In order to create your first container, you need a template file. Templates in OpenVZ refers to a compressed format of different operating systems that are available freely. You can browse the templates at https://openvz.org/Download/template/precreated.
Download your favourite operating systems template to the /vz/template/cache directory and once completed, follow the steps shown in the next section.
The power of the shell comes in handy when creating containers or when amending the current settings related to a container. In this section, we will create our first container (virtual machine) and add a few parameters, including the IP address, so that you can access your machine over a LAN (or provide a public IP so that it can be accessible over a WAN as a standalone virtual server), name, DNS name server, root user password, etc. So, lets get started with creating the container first:
# vzctl create 101 --ostemplate centos-6-x86_64 --config basic
1. vzctl: This is the most useful command for OpenVZ for creating a new container, editing an IP address, changing the root password, etc. Any operation that you can think of relating to the container will use vzctl.
2. –ostemplate: This defines the template (operating system) you want to install in this new container space. All templates go in /vz/template/cache.
3. –config: This will use the ve-basic.conf-sample configuration file present in the /etc/sysconfig/vz-scripts/ directory. Another option can be -config light which will use the ve-light.conf-sample configuration file. You can check the contents of these files by opening them in your favourite text editor. There are other configuration files as well, by default, but I would recommend that you use one of the above just to keep things simple.
After running the above command, you should see the following output along with some other information:
Creating container private area (centos-6-x86_64) Unmounting file system at /vz/root/101 Unmounting device /dev/ploop15699 Opening delta /vz/private/101/root.hdd/root.hdd Adding delta dev=/dev/ploop15699 img=/vz/private/101/root.hdd/root.hdd (rw) Mounting /dev/ploop15699p1 at /vz/root/101 fstype=ext4 data=balloon_ino=12, Performing postcreate actions Unmounting file system at /vz/root/101 Unmounting device /dev/ploop15699 CT configuration saved to /etc/vz/conf/101.conf Container private area was created
To check if your container was created successfully, run vzlist -a and it should list all the containers (even those not running) as shown in Figure 2.
Configuring the container (changing the IP address, DNS entry, name, etc)
Now that we have created our container, we need to provide an IP address, name, hostname, DNS name server, etc.
Adding the IP address to a container: This can be confusing because you need to provide an IP address which is accessible over the LAN, according to your set-up. If you have a pool of public IP addresses, then you can provide an IP from that range. For the sake of testing, check the IP address of your host machine (using ifconfig) and provide an IP from the same range. For example, if your host machines IP address is 192.168.0.254, then use 192.168.0.253. Basically, you can use any unassigned IP address within the range of 192.168.0.2 and 192.168.0.254.
# vzctl stop 101 # vzctl set 101 --ipadd 192.168.0.253 --save # vzctl start 101
a) vzctl stop 101: This is self-explanatory; it stops a running container so that we can make the changes in configuration. Although it is not necessary to stop a container before making changes, I recommend it to avoid any inconsistencies.
b) set: This is a switch used to set various parameters for a container. All these settings go into the configuration file of a container, which for this particular case is /etc/sysconfig/vz-scripts/101.conf.
c) –ipadd: This is the switch used to add an IP address to this container.
d) 192.168.0.253: This is the IP address, of course.
e) –save: This is the switch to save the configuration file. It is necessary, otherwise, on the next boot, this containers IP address will be reverted to the one to which it was set before the change (it will be set to None if no IP address was assigned).
f) vzctl start 101: This starts the container with CTID 101, after the changes are made successfully.
Changing the IP address for a container: Sometimes, you might want to change the IP address for a container that has already been assigned some different IP. This is a two-step process: 1) delete the old IP address, and 2) add the new IP address. This is because a single container can have multiple IP addresses, and if you want to add another IP address to a specific container, do not run the –ipdel command.
# vzctl stop 101 # vzctl set 101 --ipdel all --save # vzctl set 101 --ipadd 192.168.0.251 --save # vzctl start 101
a) –ipdel all: This is used to delete all the IP addresses associated with this container.
Changing the hostname of a container:
# vzctl stop 101 # vzctl set 101 --hostname server101.mydomain.com --save # vzctl start 101
If you do not set any hostname, the default hostname will be used, that is, localhost.localdomain
Changing DNS name server entry:
# vzctl stop 101 # vzctl set 101 --nameserver 8.8.8.8 --save # vzctl start 101
Name servers are necessary in the configuration in order to access the Internet. If you do not provide them, you wont be able to ping www.google.com, although you will be able to ping any IP address. Basically, this entry specifies the DNS server for name to IP conversions. In the aboveexample, I used Googles open DNS servers, but you can do that only provided your container can access the Internet. This entry goes to the /etc/resolv.conf file inside the container.
Changing the name of the container:
# vzctl stop 101 # vzctl set 101 --name new_name --save # vzctl start 101
Setting the container to be started on host reboot:
# vzctl stop 101 # vzctl set 101 --onboot yes --save # vzctl start 101
This option is somewhat important if you are going to reboot your server (host machine) a lot. You can mark a container to start on boot, or not. This is also important if you have clients who have purchased virtual servers from you. If, for some reason, your host machine goes down (I hope not), then containers which are not marked to start on server reboot will not be started automatically.
Changing physical memory (RAM) and SWAP space for a container:
# vzctl stop 101 # vzctl set 101 --ram 512M --swap 1G --save # vzctl start 101
Make sure to set these values as per the right usage to avoid issues such as killed processes, slowness while performing tasks, etc, inside a container.For example, if you have 4096MB of RAM on your host machine, then always set a lower value for RAM for any container. As the resources are shared and not dedicated between the containers, you can surely provide more RAM to containers, but issues arise when the usage increases and containers use all the memory. At that point, it is advisable to increase the host machines RAM; otherwise, the processes will be killed intermittently, eventually creating more serious issues.
In order to read about SWAP space, refer to the article at http://www.centos.org/docs/5/html/5.1/Deployment_Guide/s1-swap-what-is.html
Changing the disk space for a container:
# vzctl stop 101 # vzctl set 101 --diskspace 20G:25G --save # vzctl stop 101
I have specified two values here20G and 25G. These can be referred to as a soft limit and hard limit, respectively. In order to make the soft limit and hard limit active, you would need to have vzquota set to On. As vzquota itself is a vast topic, it is beyond the scope of this article but you can read more about it at https://openvz.org/Man/vzquota.8
Changing the root user password: If you forget the root user password for a container, you can reset it from the host machine. This is true for other users as well but is not needed, because if you have root access to a container, you can reset any users password.
# vzctl stop 101 # vzctl set 101 --userpasswd root:new_password # vzctl start 101
Running any command from the host machine inside the container: This feature allows the administrators of the host machine to run any command inside the container, and the general format is:
# vzctl exec CTID command
Here are some examples:
a) vzctl exec 101 service sshd status
b) vzctl exec 101 df -Th
c) vzctl exec 101 cp -var file1.txt /location/to/copy/
Gaining access to a container from the host machine: Sometimes it is necessary to gain access to a container, without the root password, from the host machine. You can do this using the following command:
# vzctl enter CTID
OpenVZ is a pretty vast topic and if you want to know more, there are unlimited sources on the Internet. The wiki at openvz.org is so comprehensive that you will find all the answers to your doubts there. You can also join the IRC channel (#openvz) on the freenode network and get assistance from other experienced users, live.
