OpenVZ Virtuozzo Containers Wiki - User contributions [en]

Migration from one HN to another

2007-12-21T10:43:51Z

Btgeekboy:

The vzmigrate script is used to migrate a Virutal Environment from one Hardware Node to another.

You first have to setup SSH to permit the old HN to be able to login to the new HN without a password prompt. Run the following on the old HN.

<pre>[root@OpenVZ ~]# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Created directory '/root/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
74:7a:3e:7f:27:2f:42:bb:52:4c:ad:55:31:6f:79:f2 root@OpenVZ.ics.local
[root@OpenVZ ~]# cd .ssh/
[root@OpenVZ .ssh]# ls -al
total 20
drwx------ 2 root root 4096 Aug 11 09:41 .
drwxr-x--- 5 root root 4096 Aug 11 09:40 ..
-rw------- 1 root root 887 Aug 11 09:41 id_rsa
-rw-r--r-- 1 root root 231 Aug 11 09:41 id_rsa.pub
[root@OpenVZ .ssh]# scp id_rsa.pub root@10.1.5.6:./id_rsa.pub
The authenticity of host '10.1.5.6 (10.1.5.6)' can't be established.
RSA key fingerprint is 3f:2a:26:15:e4:37:e2:06:b8:4d:20:ee:3a:dc:c1:69.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.1.5.6' (RSA) to the list of known hosts.
root@10.1.5.6's password:
id_rsa.pub 100% 231 0.2KB/s 00:00</pre>

Run the following on the new HN.

<pre>[root@Char ~]# cd .ssh/
[root@Char .ssh]# touch authorized_keys2
[root@Char .ssh]# chmod 600 authorized_keys2
[root@Char .ssh]# cat ../id_rsa.pub >> authorized_keys2
[root@Char .ssh]# rm ../id_rsa.pub
rm: remove regular file `../id_rsa.pub'? y</pre>

Run the following on the old HN.

<pre>[root@OpenVZ .ssh]# ssh -2 -v root@10.1.5.6
OpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 10.1.5.6 [10.1.5.6] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/id_rsa type 1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.9p1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '10.1.5.6' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: An invalid name was supplied
Cannot determine realm for numeric host address

debug1: An invalid name was supplied
Cannot determine realm for numeric host address

debug1: Next authentication method: publickey
debug1: Offering public key: /root/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Offering public key: /root/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 149
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
Last login: Thu Aug 9 16:41:30 2007 from 10.1.5.20
[root@Char ~]# exit</pre>

Now that the vzmigrate script will function, a little bit on vzmigrate.

<pre>This program is used for VE migration to another node
Usage:
vzmigrate [-r yes|no] [--ssh=<options>] [--keep-dst] [--online] [-v]
destination_address <VEID>
Options:
-r, --remove-area yes|no
Whether to remove VE on source HN for successfully migrated VE.
--ssh=<ssh options>
Additional options that will be passed to ssh while establishing
connection to destination HN. Please be careful with options
passed, DO NOT pass destination hostname.
--keep-dst
Do not clean synced destination VE private area in case of some
error. It makes sense to use this option on big VE migration to
avoid syncing VE private area again in case some error
(on VE stop for example) occurs during first migration attempt.
--online
Perform online (zero-downtime) migration: during the migration the
VE hangs for a while and after the migration it continues working
as though nothing has happened.
-v
Verbose mode. Causes vzmigrate to print debugging messages about
its progress (including some time statistics).</pre>

Here is an example of migrating VE 101 from the current HN to one at 10.1.5.6:

<pre>[root@OpenVZ .ssh]# vzmigrate 10.1.5.6 101
OPT:10.1.5.6
Starting migration of VE 101 on 10.1.5.6
Preparing remote node
Initializing remote quota
Syncing private
Syncing 2nd level quota
Turning quota off
Cleanup</pre>

Here's a simple shell script that will migrate each VPS one after another. Just pass the destination host node as the single argument to the script. Feel free to add the -v flag to the vzmigrate flags if you'd like to see it execute with the verbose option:

<pre>#!/bin/bash
vzlist | tail -n +2 | awk 'BEGIN { } /.*/ { print $1 }' | xargs -n1 vzmigrate --remove-area no --keep-dst $1</pre>

[[Category:HOWTO]]

UBC failcnt reset

2007-12-21T10:40:49Z

Btgeekboy: Grammar, misc cleanup

One of the frequently asked question is '''How do I reset failcnt in /proc/user_beancounters?''' While it's not suggested, it is possible.

== What is failcnt? ==
There are a number of resource limits (called [[User Beancounters]], or UBC for short) set for a VE. If one of those resources hit its limit, the appropriate fail counter (last column of <code>/proc/user_beancounters</code>) increases. See [[Resource shortage]] for more info.

== How to clear failcnt? ==
You do not need to, and this would be an incorrect thing to do.

There can be many applications that read <code>/proc/user_beancounters</code>, and thus if you will reset it, you may have problems with those other apps. Consider what happens if you reset your sent/received packets/bytes statistics on a network interface — programs which track it may not function properly.

Therefore, the proper usage of failcnt is not to check whether it is zero or not, but to check whether it is increased since the previous readout. In other words, check the difference, not the absolute value. It is easy to write a simple script to do just that.

== OK, I understand, but I still want to clear failcnt! ==

UBC failcnts are stored for the duration of the uptime of your VE. Thus, restarting the VE resets the counts.

The problem here is tcp time wait buckets can still there after a VE is stopped. You can check that by seeing the <code>held</code> column for <code>kmemsize</code> parameter. If it is not zero, that means you have to wait about 5 minutes in order to time wait buckets to expire, and the corresponding beancounter to be uncharged.

If you still see failcnt not reset to 0 after more than 5 minutes after VE is stopped, your kernel was likely compiled with CONFIG_UBC_KEEP_UNUSED=y, and in that case you'll have to switch off this option if you want to reset beancounters when VE is restarted.

If you're sure your kernel was NOT compiled with the above option and it's not resetting failcnt after 5 minutes, it means there is a bug in UBC code. Please file a detailed [[bug report]] to [http://bugzilla.openvz.org bugzilla.openvz.org]

== External links ==
* {{Forum|361}}
* {{Forum|497}}

[[Category:FAQ]]
[[Category:UBC]]

UBC failcnt reset

2007-12-21T10:38:01Z

Btgeekboy:

One of the frequently asked question is '''How do I reset failcnt in /proc/user_beancounters?''' While it's not suggested, it is possible.

== What is failcnt? ==
There are a number of resource limits (called [[User Beancounters]], or UBC for short) set for a VE. If one of those resources hit its limit, the appropriate fail counter (last column of <code>/proc/user_beancounters</code>) increases. See [[Resource shortage]] for more info.

== How to clear failcnt? ==
You do not need to, and this would be an incorrect thing to do.

There can be many application who reads <code>/proc/user_beancounters</code>, and thus if you will reset it you gonna have problems with those other apps. Consider what happens if you will reset you sent/received packets/bytes statistics on the network interface — programs which reads will be screwed up.

So, the proper procedure of checking failcnt is not to check whether it is zero or not, but to check whether it is increased since the previous readout. In other words, check the difference, not the absolute value. It is easy to write a simple script to do just that.

== OK, I understand, but I still want to clear failcnt! ==

OK, you can do so by restarting your VE. Since fail counters are for VE lifetime, they will be cleared after VE stop.

The problem here is tcp time wait buckets can still there after a VE is stopped. You can check that by seeing the <code>held</code> column for <code>kmemsize</code> parameter. If it is not zero, that means you have to wait about 5 minutes in order to time wait buckets to expire, and the corresponding beancounter to be uncharged.

If you still see failcnt not reset to 0 after more than 5 minutes after VE is stopped, your kernel was likely compiled with CONFIG_UBC_KEEP_UNUSED=y, and in that case you'll have to switch off this option if you want to reset beancounters when VE is restarted.

If you're sure your kernel was NOT compiled with the above option and it's not resetting failcnt after 5 minutes, it means there is a bug in UBC code. Please file a detailed [[bug report]] to [http://bugzilla.openvz.org bugzilla.openvz.org]

== External links ==
* {{Forum|361}}
* {{Forum|497}}

[[Category:FAQ]]
[[Category:UBC]]

Quick installation (legacy)

2007-12-07T08:28:24Z

Btgeekboy: Added link to helpful info for x86_64 users.

This document briefly describes the steps needed to install OpenVZ on your (RPM based) machine. For '''Debian''' based systems see [[Installation on Debian]].

This document is also available in the following languages: [http://forum.openvz.org/index.php?t=tree&goto=35&#msg_35 French], [http://forum.openvz.org/index.php?t=tree&goto=1805&#msg_1805 German],
[http://wiki.openvz.jp Japanese],
[[Quick_installation_(Spanish)|Spanish]].

OpenVZ consists of a kernel, user-level tools, and VE templates. This guide tells how to install the kernel and the tools.

== Requirements ==
This guide assumes you are running recent release of Fedora Core (like FC5) or RHEL/CentOS 4. Currently, OpenVZ kernel tries to support the same hardware that Red Hat kernels support. For full hardware compatibility list, see [http://www.swsoft.com/en/products/virtuozzo/hcl/ Virtuozzo HCL].

=== Filesystems ===
It is recommended to use a separate partition for VEs private directories (by default /vz/private/<veid>). The reason why you should do so is that if you wish to use OpenVZ per-VE disk quota, you won't be able to use usual Linux disk quotas on the same partition. Bear in mind, that per-VE quota in this context includes not only pure per-VE quota, but also usual Linux disk quota used in VE, not on [[HN]].

At least try to avoid using root partition for VEs, because the root user of VE will be able to overcome 5% disk space barrier in some situations. This way HN root partition can be completely filled and it will break the system.

OpenVZ per-VE disk quota is supported only for ext2/ext3 filesystems. So use one of these filesystems (ext3 is recommended) if you need per-VE disk quota.

=== rpm or yum? ===

In case you have yum utility available on your system, you may want to use it effectively to install and update OpenVZ packages. In case you don't have yum, or don't want to use it, you can use plain old rpm. Instructions for both rpm and yum are provided below.

=== yum pre-setup ===
If you want to use yum, you should set up OpenVZ yum repository first.

Download [http://download.openvz.org/openvz.repo openvz.repo] file and put it to your <code>/etc/yum.repos.d/</code> repository. This can be achieved by the following commands, as root:
<pre>
# cd /etc/yum.repos.d
# wget http://download.openvz.org/openvz.repo
# rpm --import http://download.openvz.org/RPM-GPG-Key-OpenVZ
</pre>

In case you can not cd to /etc/yum.repos.d, it means either yum is not installed on your system, or yum version is too old. In that case, just stick to rpm installation method.

== Kernel installation ==

{{Note|In case you want to recompile the kernel yourself rather than use the one provided by OpenVZ, see [[kernel build]].}}

First, you need to choose what “flavor” of the kernel you want to install. Please refer to [[Kernel flavors]] for more information.

=== Using yum ===
Run the following command
<pre>
# yum install ovzkernel[-flavor]
</pre>

Here <code>[-flavor]</code> is optional, and can be <code>-smp</code> or <code>-enterprise</code>. Refer to [[kernel flavors]] for more info.

=== Using rpm ===
Get the kernel binary RPM from the [http://openvz.org/download/kernel/ Download » Kernel] page, or directly from [http://download.openvz.org/kernel/ download.openvz.org/kernel], or from one of its [[Download mirrors|mirrors]]. You need only one kernel RPM so please [[Kernel flavors|choose the appropriate one]] depending on your hardware.

Next, install the kernel RPM you chose:

<pre>
# rpm -ihv ovzkernel[-flavor]*.rpm
</pre>

Here <code>[-flavor]</code> is optional, and can be <code>-smp</code> or <code>-enterprise</code>. Refer to [[kernel flavors]] for more info.

{{Note|<tt>rpm -U</tt> (where <tt>-U</tt> stands for ''upgrade'') should '''not''' be used, otherwise all currently installed kernels will be uninstalled.}}

== Configuring the bootloader ==

In case GRUB is used as the boot loader, it will be configured automatically: lines similar to these will be added to the <tt>/boot/grub/grub.conf</tt> file:

<pre>
title Fedora Core (2.6.8-022stab029.1)
root (hd0,0)
kernel /vmlinuz-2.6.8-022stab029.1 ro root=/dev/sda5 quiet rhgb vga=0x31B
initrd /initrd-2.6.8-022stab029.1.img
</pre>
Change <tt>Fedora Core</tt> to <tt>OpenVZ</tt> (just for clarity reasons, so the OpenVZ kernels will not be mixed up with non-OpenVZ ones). Remove extra arguments from the kernel line, leaving only the <tt>root=...</tt> parameter. The modifed portion of <tt>/etc/grub.conf</tt> should look like this:

<pre>
title OpenVZ (2.6.8-022stab029.1)
root (hd0,0)
kernel /vmlinuz-2.6.8-022stab029.1 ro root=/dev/sda5
initrd /initrd-2.6.8-022stab029.1.img
</pre>

== Configuring ==

Please make sure the following steps are performed before rebooting into OpenVZ kernel.

=== sysctl ===

There are a number of kernel parameters that should be set for OpenVZ to work correctly. These parameters are stored in <tt>/etc/sysctl.conf</tt> file. Here is the relevant part of the file; please edit it accordingly.

<pre>
# On Hardware Node we generally need
# packet forwarding enabled and proxy arp disabled
net.ipv4.ip_forward = 1
net.ipv4.conf.default.proxy_arp = 0
# Enables source route verification
net.ipv4.conf.all.rp_filter = 1
# Enables the magic-sysrq key
kernel.sysrq = 1
# TCP Explict Congestion Notification
#net.ipv4.tcp_ecn = 0
# we do not want all our interfaces to send redirects
net.ipv4.conf.default.send_redirects = 1
net.ipv4.conf.all.send_redirects = 0
</pre>

=== SELinux ===

SELinux should be disabled. To that effect, put the following line to <code>/etc/sysconfig/selinux</code>:
<pre>
SELINUX=disabled
</pre>

=== Conntracks ===

In the stable OpenVZ kernels (those that are 2.6.8-based) netfilter connection tracking for [[VE0]] is disabled by default. If you have a stateful firewall enabled on the host node (it is there by default) you should either disable it, or enable connection tracking for [[VE0]].

To enable conntracks for VE0, add the following line to <code>/etc/modprobe.conf</code> file:
<pre>
options ip_conntrack ip_conntrack_enable_ve0=1
</pre>

{{Note|In kernels later than 2.6.8, connection tracking is enabled by default.}}

== Rebooting into OpenVZ kernel ==

Now reboot the machine and choose "OpenVZ" on the boot loader menu. If the OpenVZ kernel has been booted successfully, proceed to installing the user-level tools for OpenVZ. If you are installing on x86_64 CentOS or Fedora system, you may want to continue the setup process using the [[Install_OpenVZ_on_a_x86_64_system_Centos-Fedora|x86_64 guide]].

== Installing the utilities ==

OpenVZ needs some user-level tools installed. Those are:

; vzctl
: A utility to control OpenVZ VPSs (create, destroy, start, stop, set parameters etc.)
; vzquota
: A utility to manage quotas for VPSs. Mostly used indirectly (by vzctl).

=== Using yum ===

<pre>
# yum install vzctl vzquota
</pre>

=== Using rpm ===

Download the binary RPMs of these utilities from [http://openvz.org/download/utils/ Download » Utils], or directly from [http://download.openvz.org/utils/ download.openvz.org/utils], or from one of its [[Download mirrors|mirrors]]. Install them:

<pre>
# rpm -Uhv vzctl*.rpm vzquota*.rpm
</pre>

If rpm complains about unresolved dependencies, you'll have to satisfy them first, then repeat the installation.

When all the tools are installed, start the OpenVZ subsystem.

== Starting OpenVZ ==

As root, execute the following command:

<pre>
# /sbin/service vz start
</pre>

This will load all the needed OpenVZ kernel modules. This script should also start all the VPSs marked to be auto-started on machine boot (there aren't any yet).

During the next reboot, this script should be executed automatically.

== Next steps ==

OpenVZ is now set up on your machine. To load OpenVZ kernel by default, edit the default line in the /boot/grub/grub.conf file to point to the OpenVZ kernel. For example, if the OpenVZ kernel is the first kernel mentioned in the file, put it as default 0. See man grub.conf for more details.

The next step is to prepare the [[OS template]]: please continue to [[OS template cache preparation]] document.

[[Category: Installation]]
[[Category: HOWTO]]
[[Category: Debian]]