Editing Migration from Linux-VServer to OpenVZ

Jump to: navigation, search

Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision Your text
Line 1: Line 1:
{{Roughstub}}
+
Current document describes the migration from Linux-VServer based virtualization solution to OpenVZ.
  
This article describes the migration from Linux-VServer to OpenVZ.
+
Description of challenge:
  
== Details of migration process ==
+
The challenge is migration from Linux-Vserver to OpenVZ by booting the OpenVZ kernel and updating the existing configs of  
 +
utility level in purpose to make the existing guest OSes work over OpenVZ kernel.
  
=== Initial conditions ===
+
Details of migration process. Step by step:
  
The following example of Linux-VServer based solution was used for the experiment:
+
1. Initial conditions: the following example of Linux-VServer based solution was used for the experiment:
  
* Kernel linux-2.6.17.13 was patched by the patch-2.6.17.13-vs2.0.2.1.diff and rebuild;
+
- Kernel linux-2.6.17.13 was patched by the patch-2.6.17.13-vs2.0.2.1.diff and rebuild;
* Util-vserver-0.30.211 tools were used for creating containers;
+
- Util-vserver-0.30.211 tools were used for creating containers;
  
 +
<code>
 
   # vserver-info
 
   # vserver-info
 
   Versions:
 
   Versions:
Line 17: Line 19:
 
   VS-API: 0x00020002
 
   VS-API: 0x00020002
 
   util-vserver: 0.30.211; Dec  5 2006, 17:10:21
 
   util-vserver: 0.30.211; Dec  5 2006, 17:10:21
+
 
 
   Features:
 
   Features:
 
   CC: gcc, gcc (GCC) 3.4.3 20041212 (Red Hat 3.4.3-9.EL4)
 
   CC: gcc, gcc (GCC) 3.4.3 20041212 (Red Hat 3.4.3-9.EL4)
Line 32: Line 34:
 
   syscall(2) invocation: alternative
 
   syscall(2) invocation: alternative
 
   vserver(2) syscall#: 273/glibc
 
   vserver(2) syscall#: 273/glibc
+
 
 
   Paths:
 
   Paths:
 
   prefix: /usr/local
 
   prefix: /usr/local
Line 41: Line 43:
 
   vserver-Rootdir: /vservers
 
   vserver-Rootdir: /vservers
 
   #
 
   #
 +
</code>
  
 
VServer v345 was built using vserver vX build utility and populated by using the tarballed template of Fedora Core 4.
 
VServer v345 was built using vserver vX build utility and populated by using the tarballed template of Fedora Core 4.
 
   
 
   
 +
<code>
 
   # vserver v345 start
 
   # vserver v345 start
 
   Starting system logger:                                    [  OK  ]
 
   Starting system logger:                                    [  OK  ]
Line 70: Line 74:
 
   sh-2.05b#
 
   sh-2.05b#
 
   .........
 
   .........
 +
</code>
  
 
As a result we obtain running virtual environment v345:
 
As a result we obtain running virtual environment v345:
  
 +
<code>
 
   # vserver-stat
 
   # vserver-stat
+
 
 
   CTX  PROC    VSZ    RSS  userTIME  sysTIME    UPTIME NAME
 
   CTX  PROC    VSZ    RSS  userTIME  sysTIME    UPTIME NAME
 
   0      51  90.9M  26.3M  0m58s75  2m42s57  33m45s93 root server
 
   0      51  90.9M  26.3M  0m58s75  2m42s57  33m45s93 root server
 
   49153    4  10.2M  2.8M  0m00s00  0m00s11  21m45s42 v345
 
   49153    4  10.2M  2.8M  0m00s00  0m00s11  21m45s42 v345
+
 
 
   #  
 
   #  
 +
</code>
 +
 +
2. Starting migration to OpenVZ: downloading and installing the stable OpenVZ kernel.
 +
 +
First of all we should download and install the latest stable version of OpenVZ kernel:
  
=== Starting migration to OpenVZ ===
+
<code>
 +
  #  wget http://openvz.org/download/kernel/stable/ovzkernel-2.6.9-023stab032.1.i686.rpm
 +
  #  rpm -ihv ovzkernel-2.6.9-023stab032.1.i686.rpm
 +
</code>
  
Downloading and installing the stable OpenVZ kernel.
+
If you use grub bootloader, then before installing the OpenVZ kernel file /boot/grub/grub.conf looked like this:
  
Install the OpenVZ kernel, as described in [[Quick installation]].  
+
<code>
 +
  # grub.conf generated by anaconda
 +
  #
 +
  # Note that you do not have to rerun grub after making changes to this file
 +
  # NOTICE:  You have a /boot partition.  This means that
 +
  #          all kernel and initrd paths are relative to /boot/, eg.
 +
  #          root (hd0,0)
 +
  #          kernel /vmlinuz-version ro root=/dev/VolGroup00/LogVol00
 +
  #          initrd /initrd-version.img
 +
  #boot=/dev/sda
 +
  default=0
 +
  timeout=5
 +
  splashimage=(hd0,0)/grub/splash.xpm.gz
 +
  hiddenmenu
 +
  title Red Hat Enterprise Linux AS (2.6.17.13-vs2.0.2.1)
 +
          root (hd0,0)
 +
          kernel /vmlinuz-2.6.17.13-vs2.0.2.1 ro root=/dev/VolGroup00/LogVol00
 +
          initrd /initrd-2.6.17.13-vs2.0.2.1.img
 +
</code>
  
After the kernel is installed, reboot the machine. After rebooting and logging in you will see the following reply on vserver-stat call:
+
After installing it should look like this:
  
 +
<code>
 +
  # grub.conf generated by anaconda
 +
  #
 +
  # Note that you do not have to rerun grub after making changes to this file
 +
  # NOTICE:  You have a /boot partition.  This means that
 +
  #          all kernel and initrd paths are relative to /boot/, eg.
 +
  #          root (hd0,0)
 +
  #          kernel /vmlinuz-version ro root=/dev/VolGroup00/LogVol00
 +
  #          initrd /initrd-version.img
 +
  #boot=/dev/sda
 +
  default=0
 +
  timeout=5
 +
  splashimage=(hd0,0)/grub/splash.xpm.gz
 +
  hiddenmenu
 +
  title Red Hat Enterprise Linux AS (2.6.9-023stab032.1)
 +
          root (hd0,0)
 +
          kernel /vmlinuz-2.6.9-023stab032.1 ro root=/dev/VolGroup00/LogVol00
 +
          initrd /initrd-2.6.9-023stab032.1.img
 +
  title Red Hat Enterprise Linux AS (2.6.17.13-vs2.0.2.1)
 +
          root (hd0,0)
 +
          kernel /vmlinuz-2.6.17.13-vs2.0.2.1 ro root=/dev/VolGroup00/LogVol00
 +
          initrd /initrd-2.6.17.13-vs2.0.2.1.img
 +
</code>
 +
 +
And the default parameter should be set to 0 in purpose to make the OpenVZ kernel work by default after rebooting the machine.
 +
 +
Some more manual configuring needed on this step:
 +
Update the /etc/sysctl.conf file according to the following listing ( Comment all other settings that are not presented
 +
in listing below ):
 +
 +
<code>
 +
  # 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
 +
</code>
 +
 +
As the SELinux should be disabled, put the following line to /etc/sysconfig/selinux:
 +
 +
<code>
 +
  SELINUX=disabled
 +
</code>
 +
 +
Now reboot the machine. After rebooting and loggin in you will see the following reply on vserver-stat call:
 +
 +
<code>
 
   # vserver-stat
 
   # vserver-stat
 
   can not change context: migrate kernel feature missing and 'compat' API disabled: Function not implemented
 
   can not change context: migrate kernel feature missing and 'compat' API disabled: Function not implemented
 +
  #
 +
</code>
  
It is a natural thing that now virtual environment v345 is unavailable. The following steps will be devoted to making it
+
It is a natural thing that now virtual environments v345 is unavailable. The following steps will be devoted to making them
 
work over OpenVZ kernel.
 
work over OpenVZ kernel.
  
=== Downloading and installing vzctl package ===
+
3. Downloading and istalling vzctl package
  
OpenVZ solution requires installing a set of tools: vzctl and vzquota packages. Download and install it, as described in [[quick installation]].
+
OpenVZ solution reqires installing a set of tools: vzctl and vzquota packages. Let us download and install this tools:
 +
 
 +
<code>
 +
  # wget http://openvz.org/download/utils/vzctl-3.0.13-1.i386.rpm
 +
  # wget http://openvz.org/download/utils/vzquota-3.0.9-1.i386.rpm
 +
  # rpm -Uhv vzctl-3.0.13-1.i386.rpm vzquota-3.0.9-1.i386.rpm
 +
</code>
  
 
If rpm complains about unresolved dependencies, you'll have to satisfy them first, then repeat the installation.
 
If rpm complains about unresolved dependencies, you'll have to satisfy them first, then repeat the installation.
 
Then launch the OpenVZ:
 
Then launch the OpenVZ:
  
 +
<code>
 
   # /sbin/service vz start
 
   # /sbin/service vz start
 
   Starting OpenVZ:                                          [  OK  ]
 
   Starting OpenVZ:                                          [  OK  ]
 
   Bringing up interface venet0:                              [  OK  ]
 
   Bringing up interface venet0:                              [  OK  ]
 
   Configuring interface venet0:                              [  OK  ]
 
   Configuring interface venet0:                              [  OK  ]
 +
  #
 +
</code>
  
Currently vzlist utility is unable to find any containers:
+
Currently vzlist util is unable to find any VE:
 +
 
 +
<code>
 
   # vzlist
 
   # vzlist
   Containers not found
+
   VE not found
 +
  #
 +
</code>
  
=== Updating different configurations ===
+
4. Updating different configurations in purpose to make existing templates work
  
Get the existing guest OSs to the right place:
+
Move the existing templates of guest OSes to the right place:
  
 +
<code>
 
   # cd /vz
 
   # cd /vz
 
   # mkdir private
 
   # mkdir private
   # mkdir private/345
+
   # mkdir 345
 
   # mv /vservers/v345 /vz/private/345
 
   # mv /vservers/v345 /vz/private/345
In Debian Lenny the path is /var/lib/vz/private/345 instead.
+
</code>
In any case it is a good idea to have the guest file system in a dedicated partition or lvm container (shown in the example below) and just mount it there
 
instead of moving:
 
  # mkdir /var/lib/vz/private/345
 
  # mount /dev/mapper/vg01-lvol5 /var/lib/vz/private/345
 
  
Now it is time for creating configuration files for OpenVZ container. Use the basic sample
+
Now it is time for creating configuration files for OpenVZ VPS. Use the basic sample
 
configuration presented in /etc/sysconfig/vz-scripts/ve-vps.basic.conf-sample file:
 
configuration presented in /etc/sysconfig/vz-scripts/ve-vps.basic.conf-sample file:
  
 +
<code>
 
   # cd /etc/sysconfig/vz-scripts
 
   # cd /etc/sysconfig/vz-scripts
 
   # cp ve-vps.basic.conf-sample 345.conf
 
   # cp ve-vps.basic.conf-sample 345.conf
In Debian Lenny the configuration is located in /etc/vz/conf/ , in this case type:
+
</code>
  # cd /etc/vz/conf
 
  # cp ve-vps.basic.conf-sample  345.conf
 
  
Now, let's set some parameters for the new container.
+
Update the ON_BOOT string in 345.conf file by typing:
  
First, we need to tell which distro the container is running:
+
<code>
   # echo "OSTEMPLATE=\"fedora-core-4\"" >> 345.conf
+
  .....
   # echo "OSTEMPLATE=\"debian\"" >> 345.conf    (for Debian Lenny)
+
  ONBOOT="yes"
 +
  .....
 +
</code>
 +
to make it boot on node restart, and add a couple of strings related to the particular 345 VE:
 +
<code>
 +
  .....
 +
   VE_ROOT="/vz/root/345"
 +
  VE_PRIVATE="/vz/private/345"
 +
  ORIGIN_SAMPLE="vps.basic"
 +
   HOSTNAME="test345.my.org"
 +
  IP_ADDRESS="192.168.0.145"
 +
  .....
 +
</code>
  
Then we set a few more parameters:
+
And reboot the machine:
  vzctl set 345 --onboot yes --save # to make it start upon reboot
 
  vzctl set 345 --ipadd 192.168.0.145 --save
 
  vzctl set 345 --hostname test345.my.org --save
 
  
== Testing how the guest OSs successfully work over OpenVZ ==
+
<code>
 +
  # reboot
 +
</code>
  
Now you can start a container:
+
5. Testing how the guest OSes succesfully work over OpenVZ. reference to Users Guide of OpenVZ (vzctl).
  
# vzctl start 345
+
After rebooting you will be able to see running VE 345 that have been migrated from vserver:
  
and see if it's running:
+
<code>
 
   # vzlist -a
 
   # vzlist -a
 
   CTID      NPROC  STATUS  IP_ADDR        HOSTNAME
 
   CTID      NPROC  STATUS  IP_ADDR        HOSTNAME
 
   345          5  running 192.168.0.145  test345.my.org
 
   345          5  running 192.168.0.145  test345.my.org
 +
  #
 +
</code>
  
You can run commands in it:
+
And run commands on it:
  
 +
<code>
 
   # vzctl exec 345 ls -l
 
   # vzctl exec 345 ls -l
 
   total 48
 
   total 48
Line 176: Line 288:
 
   drwxr-xr-x  15 root    root        4096 Jul 27  2004 usr
 
   drwxr-xr-x  15 root    root        4096 Jul 27  2004 usr
 
   drwxr-xr-x  17 root    root        4096 Oct 26  2004 var
 
   drwxr-xr-x  17 root    root        4096 Oct 26  2004 var
 +
  #
 +
</code>
  
== Issues ==
+
Potential issues:
 
+
This work has in progress status. Some issues may take place with tuning the network for containers. To be continued.
=== Starting ===
 
 
 
If starting fails with a message '''Unable to start init, probably incorrect template''' either the /sbin/init file is missing in the guest file system, or just not executable. Or the guest file system is completely absent or dislocated. The proper path where you must place is specified in the vz.conf file, namely the parameter VE_PRIVATE. For Debian this file can be found in /etc/vz.
 
 
 
=== Networking ===
 
 
 
==== Starting networking in VEs ====
 
 
 
The vserver-originating containers do not initialize network at all. Thus one needs to use following command to enable networking start (inside of the migrated container):
 
 
 
update-rc.d networking defaults
 
 
 
==== Migrating your VServer Shorewall setup ====
 
 
 
If you had the [http://www.shorewall.net/ Shorewall firewall] running on the hardware node to route traffic to and from your guests, here are a couple of advices, provided you want a networking setup close to what you had with Vserver (i.e. running <code>vnet</code> interfaces, not <code>veth</code> ones) :
 
* do not use the <code>venet0</code> interface in Shorewall's configuration as the <code>vz</code> service starts after Shorewall (at least on Debian) and thus the interface does not exist when Shorewall starts. Do not use <code>detect</code> for the broadcast in <code>/etc/shorewall/interfaces</code>.
 
* for your VEs to be able to talk to each other, use the <code>routeback</code> option for <code>venet0</code> (and others) in <code>/etc/shorewall/interfaces</code>.
 
 
 
==== IP src from VEs ====
 
 
 
If you run a mail server in a VE, and if the hardware node has multiple network interfaces, you may have mail routing issues because of the originated IP address of the packets coming from the hardware node. Simply specify an interface in <code>/etc/vz/vz.conf</code> :
 
<pre>VE_ROUTE_SRC_DEV="iface_name"</pre>
 
 
 
=== Disk space information ===
 
 
 
Disk space information is empty. Do the following to fix:
 
rm /etc/mtab
 
ln -s /proc/mounts /etc/mtab
 
 
 
=== /dev ===
 
 
 
Vserver mounts /dev/pts filesystem for container transparently, whereas openvz does not. To compensate the ommission, you need to move aside /dev directory in the vserver-originating container and copy /dev directory from openvz based container.
 
 
 
=== Ubuntu udev ===
 
 
 
Additionally, Ubuntu based vservers have the udev package installed which prevents access to the console in openvz. This error message is an example of the problem:
 
 
 
# vzctl enter 345
 
enter into CT 345 failed
 
Unable to open pty: No such file or directory
 
 
 
The fix is to remove the udev package from the guest:
 
 
 
 
 
# vzctl exec 345 'dpkg --force-depends --purge udev'
 
(Reading database ... dpkg: udev: dependency problems, but removing anyway as you request:
 
  initramfs-tools depends on udev (>= 117-5).
 
15227 files and directories currently installed.)
 
Removing udev ...
 
Purging configuration files for udev ...
 
dpkg - warning: while removing udev, directory `/lib/udev/devices/net' not empty so not removed.
 
dpkg - warning: while removing udev, directory `/lib/udev/devices' not empty so not removed.
 
 
 
 
 
Now restart the container, you should now be able to use the console.
 
 
 
 
 
# vzctl restart 345
 
Restarting container
 
...
 
  <SNIP>
 
...
 
Container start in progress...
 
 
 
# vzctl enter 345
 
entered into CT 345
 
root@test:/#
 
 
 
=== /proc ===
 
 
 
The /proc filesystem is not automatically mounted by openvz. So the vserver needs to mount it itself. The simplests (not the best) way it can be done, is by sticking following command at the end of /etc/init.d/bootmisc.sh:
 
mount /proc
 
  
 
[[Category:HOWTO]]
 
[[Category:HOWTO]]

Please note that all contributions to OpenVZ Virtuozzo Containers Wiki may be edited, altered, or removed by other contributors. If you don't want your writing to be edited mercilessly, then don't submit it here.
If you are going to add external links to an article, read the External links policy first!

To edit this page, please answer the question that appears below (more info):

Cancel Editing help (opens in new window)

Template used on this page: