Last year, I reviewed Virtuozzo 3.0 for Linux, and I'd had some hands-on experience with prior versions of Virtuozzo from my days working with a hosting company in Denver. My budget doesn't have room for the Virtuozzo licensing, but OpenVZ fits my pocketbook just fine.
When would you want to use OpenVZ rather than VMware Server or Xen? It depends on the situation. For tasks where you don't want to run multiple OSes, but rather just multiple guests, in order to make the most of hardware or provide separation between services (for instance, separating your Web server from your file and print server) with minimal overhead, OpenVZ is a good choice. However, when you want to run non-Linux operating systems (such as FreeBSD or Windows Server) on top of a Linux host, you'd want to go with VMware rather than OpenVZ (or its commercial and proprietary big brother, Virtuozzo), since OpenVZ doesn't offer the ability to run multiple OSes.
OpenVZ also supports more processor platforms than the alternatives. VMware Server and Xen are available for x86 and AMD64, while OpenVZ is available for x86, AMD64, Itanium (IA64), PowerPC, and UltraSPARC. Note that there are no pre-built PowerPC kernels for Debian at the moment, but OpenVZ is supported on PowerPC.
You can run OpenVZ guests on any host system. I'm running my guests on a Debian system, but you can use Ubuntu, Fedora Core, Gentoo, or any other distro that has an OS template. The OS template is the set of packages used to populate a VPS, AKA virtual environment (VE) in OpenVZ lingo.
Debian kernels for OpenVZ guests are available from the OpenVZ repository, but only for Etch. Grab the most recent kernel and linux-headers package from the OpenVZ repository, and install them using
dpkg -i linux-image-2.6.18-openvz-686_02_i386.deb and
dpkg -i linux-headers-2.6.18-openvz-686_02_i386.deb. Replace the package name with the name of the file that you download, of course. When I installed the packages, dpkg complained about two symlinks pointing to missing directories, but I haven't seen any problems while using OpenVZ, so as far as I can tell this isn't a problem.
Once you've installed the kernel and the headers, you'll want to add a few parameters (found on the the OpenVZ wiki) to /etc/sysctl.conf to prep the system for running OpenVZ. For example, you need to tell the system to enable IP forwarding so that the VPSes can have networking as well. Just add these lines to sysct.conf if they're not already present, or make sure they match:
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
After installing the kernel and making these changes, you'll need to reboot the system. The OpenVZ kernel should be set to the default kernel in the GRUB menu already, so just rebooting should do the trick.
Next, you'll need to grab the OpenVZ utilities, using
apt-get install vzctl. This will install the vzctl and vzquota packages, which include the utlities (like vzctl) that you need to use to manage OpenVZ.
OpenVZ will be set to start up at boot after you install these utilities, but if you want to start playing right away, you need to start up OpenVZ manually this time (or reboot). Start up OpenVZ by running the init script:
Setting up a guest system
So far so good. Now it's time to grab a few templates and set up a guest operating system. You can find precreated templates on the OpenVZ download site, including several versions of Fedora Core, Debian Sarge and Debian Etch, CentOS, Gentoo, Mandriva, and openSUSE. Note that templates are processor-specific, so be careful not to download the AMD64 or UltraSPARC version of a template if you're going to be running it on a x86 system.
You'll also notice that there's a contrib directory with OS templates from the OpenVZ community. These aren't "official" templates, but if you want to run Ubuntu, Slackware, AltLinux, or another distro not found with the OpenVZ templates, look here.
If you want to run a distro that doesn't have a template, see the OpenVZ wiki for documentation on creating OS templates. This is one area where OpenVZ is at a disadvantage to VMware and some of the other virtualization technologies. Installing a Linux distro in VMware Server or VMware Workstation is usually as simple as running through that distro's installation procedure. In OpenVZ it's much more complicated, and you'll need to learn a lot more about OpenVZ than you might want to just to run a couple of guest instances.
Downloaded OS templates need to be stored in /var/lib/vz/template/cache. The templates are tarred and gzipped when you download them, and you want to leave them that way -- don't uncompress them.
To set up a system, use the
vzctl utlity. The bad news is that the vzctl utility is nowhere near as easy to use as the GUI tools that come with Virtuozzo. The good news is that vzctl isn't that difficult to use, it's scriptable, and it's free in every sense of the word. If you manage a lot of OpenVZ systems, you'll have the syntax down in no time, and if you don't create or muck with your OpenVZ guest systems very often, it shouldn't be too time-consuming to whip out the vzctl utlity man page and figure out the options you want. Let's take a look at the most common commands.
The syntax for creating a guest system is
vzctl create vpsid --ostemplate ostemplatename. The vpsid is the number assigned to the new system. OpenVZ reserves IDs below 100 for internal use, so I usually start assigning IDs at 1001. So, for instance, if you download the Debian Sarge OS template for x86, you'd run:
vzctl create 1001 --ostemplate debian-3.1-i386-minimal
Once a guest host is set up, you can find its filesystem under /var/lib/vz/root/vpsid, and its private area under /var/lib/vz/private/vpsid -- unless you change the defaults using the
--private options. The private directory contains files specific to the virtual environment (VE).
So, if you created the guest as vz number 1001, its root filesystem would be under /var/lib/vz/root/1001. This may come in handy if you ever need to access the files directly for some reason -- for example, if the guest's admin has made a configuration that prevents the guest from booting normally -- or for backup purposes.
Now, let's set up networking. Again, this isn't terribly difficult:
vzctl set --ipadd ipaddr --nameserver nameserverIP --hostname hostname --save
--ipadd parameter assigns the IP address to the first venet interface in the guest OS, the --hostname assigns the VPS its hostname, and the --nameserver paramter provides the first nameserver. The venet interface provided to OpenVZ guest systems by default does not have a MAC address, which means that (among other things) you cannot grab an address via DHCP for an interface.
However, the OpenVZ folks have added a new type of interface called a veth, which can provide a MAC address. The veth device also allows users to set up a DHCP server within the guest OS, and users can set their own network settings -- which is not possible using the venet devices. Whether this is desirable is another question. If you'd like to provide veth interfaces rather than venet interfaces, see the OpenVZ wiki for setup instructions.
Once the VPS is set up, go ahead and start the guest by running
vzctl start vpsid, where vpsid is the ID that you assigned to the guest when you created it.
You should see a few messages logged to the console about starting the VPS, ending with "VPS start in progress..." You can see what VPSes are running with the
vzlist command. After running
vzlist, you should see something like this:
VPSID NPROC STATUS IP_ADDR HOSTNAME 1002 4 running 10.0.1.34 vroomfondle
-a option to display all VPSes, whether they are running or not. You might also want to see what resources are being consumed by a VPS. To see how much memory is being used by a VPS, run
vzcalc -v vpsid. You should see something like this:
Resource Current(%) Promised(%) Max(%) Low Mem 0.13 1.20 1.20 Total RAM 0.55 n/a n/a Mem + Swap 0.36 1.83 n/a Alloc. Mem 0.67 1.83 13.82 Num. Proc 0.06 n/a 0.40 -------------------------------------------- Memory 0.67 1.83 13.82
This will show you how much memory is being used by the VPS, how much is allocated to the VPS, and what it can grow to.
You can also see other VPS parameters using the
-o option. See the vzcalc man page for more information.
By default, VPSes will not be started up when you boot the system. In most situations, though, you probably do want VPSes to load after a system has restarted. You can change this setting using
vzctl set vpsid --onboot yes --save
vzctl utility is also used to set system parameters, including the amount of memory, CPU resources, access to iptables modules, and more. Let's look at a few examples.
One of the things that is frustrating about OpenVZ is that it's not straightforward to say "give a VPS 256MB of RAM"; instead, you have to adjust a couple of parameters and read through some fairly technical docs to try to make sense of the way that OpenVZ deals with memory.
To make things a bit simpler, let's look at setting a VPS with a minimum of 256MB of RAM, and up to 1GB. To do that, set the vmguarpages (that's the memory that's guaranteed to the VPS) and privvmpages (that's the maximum amount of memory that will be granted) parameters:
vzctl set vpsid --vmguarpages 65536 --save
vzctl set vpsid --privvmpages 262144 --save
I found another way to do this that is much more intuitive than calculating the amount of RAM by "pages" on the SWsoft forum. Just multiply the amount of RAM that you want by 256 as an easy way to arrive at the right amount of RAM:
vzctl set vpsid --vmguarpages $((256 * 256)) --save
vzctl set vpsid --privvmpages $((256 * 1024)) --save
Read the vzctl man page, as well as the OpenVZ wiki and other documentation, for more information.
As you set parameters for each VPS, the configuration settings are stored in /etc/vz/conf/vpsid.conf. If you make any changes to this file manually, you can use the
vzcfgvalidate utility to make sure that the configuration file is correct.
Often, in hosting situations, you need to get into a system where the admin has changed the root password. With physical systems, you need to reboot the system and enter single-user mode to get root access to handle administrative tasks. With OpenVZ, all you need to do is log into the hardware node and use
vzctl to log in:
vzctl enter vpid
That will log you into the VPS as root. After you've finished whatever admin tasks you need to perform, just type
exit and you'll be returned to the session on the host system. Or, if you want to reset a password for a user, you can just use the
vzctl set vpsid --userpasswd user:passwd
If the user does not exist, it will be created.
If you'd like to run a command in a VPS without actually entering the VPS, you can use the
exec parameter for
vzctl to run a command as root. For example, if you want to run a quick upgrade inside a Debian VPS:
vzctl exec vpsid apt-get upgrade
This will run
apt-get upgrade within the VPS itself.
To shut down a VPS, run
vzctl stop vpsid, which will execute a clean shutdown within the VPS. Running
vzctl restart vpsid will restart the VPS. VPSes can also be shut down or rebooted normally from within the VPS.
So long, goodbye
So, your guest system has had a good run, but it's time to pack it in. For whatever reason, if you have a VPS that you'd like to get rid of, use the
destroy command with
vzctl destroy veid
A note of caution here: the
vzctl utility does not ask for confirmation before destroying the VPS. As soon as you press Enter, that's all she wrote -- the VPS will be removed, its private data directories removed, and if you don't have a backup, you are up a creek without a paddle if you need to retrieve the data.
There's more to OpenVZ, but this should provide enough information to get started with OpenVZ without having to spend too much time reading through the wiki first. After you've got a VPS running, be sure to consult the wiki and man pages to see what else you can accomplish with OpenVZ.