A rough description of how to migrate existing physical server into a [[VEcontainer]].

== Prepare a new “empty” VE Preparing to migrate ==For OpenVZ this would mean Stop most services on a machine to be migrated. “Most” means services such as web server, databases and the like — so you will not lose your data. Just leave the following bare minimum (assume including ssh daemon). To make things easier you chose VE ID of 123):may like to first follow the basic instructions elsewhere and create a dummy container based on the same Linux distribution you want to migrate. That way you can take that dummy as a template and then copy to your new migrated container and modify. You can later discard this dummy.

cat /etc/vz/conf/ve-vps.basic.conf-sample > /etc/vz/conf/123.conf</source>

== Preparing to migrate == Stop most services on {{Note|If you have created a machine to be migrated. “Most” means services such container from the same distro as web serverthe basis for the migration, databases simply take note of the CT ID and the like — so you will not lose your data. Just leave the bare minimum (including ssh daemon)skip this step.}}

Copy all your data from the machine to an OpenVZ box. Say you'll be using VE container with ID of 123, then all the data should be placed to <code>/vz/private/123/</code> directory (so there will be directories such as <code>/vz/private/123/bin</code>, <code>etc</code>, <code>var</code> and so on). This could be done in several ways:

rsync example (run from On the new HN)create a file <code>/tmp/exclude.txt</code> with:<pre>/tmp/boot/lib/modules/etc/blkid/etc/mtab/etc/lvm/etc/fstab/etc/udev</pre> and run <b>rsync</b> as follows:<source lang="bash"> rsync -arvpz avz -H -X --numericone-ids file-system -exclude dev -numeric-exclude proc ids --exclude -from=/tmp /exclude.txt -e "ssh -l root@a.b.c.d:/ /vz/private/123/</source> {{Note|You should add the <code>-H</code> option, so hardlinks will be preserved during sync and also include the <code>-X</code> option to preserve file extended attributes}} If your source system have multiple partitions (for example <code>/var</code> or <code>/home</code>) repeat the command above for each partition in your system; for example:<source lang=" bash">rsync -avz -H -X --one-file-system --numeric-ids -e ssh root@a.b.c.d:/var/ /vz/private/123/var/</source>

Then create the tar. But remember, when the system is 'not' using udev, you have to look into /proc/ after creating your VE container because some devices might not exist. (/dev/ptmx or others)

# tar --numeric-owner -cjpf /tmp/mysystem.tar.bz2 / -X /tmp/excludes.excl

== Setting VE container parameters ==

Also, you have to supply an IP for a new VEcontainer:

Since VE container is a bit different to a real physical server, you have to edit some files inside your new VEcontainer.

A VE container does not have real ttys, so you have to disable getty in <code>/etc/inittab</code> (i. e. <code>/vz/private/123/etc/inittab</code>). 

sed -i -e 's/^[0-9].*getty.*tty/d#&/g' /vz/private/123/etc/inittab

rm -f /vz/private/123/etc/mtab ln -s sf /proc/mounts /vz/private/123/etc/mtab

{{out|The problem here is VEcontainer's root filesystem (<code>/</code>) is mounted not from the VE container itself, but rather from the host system. That leaves <code>/etc/mtab</code> in VE container without a record for <code>/</code> being mounted, thus df doesn't show it. By linking <code>/etc/mtab → /proc/mounts</code> we make sure /etc/mtab shows what is really mounted in a VEcontainer.

Since you do not have any real disk partitions in a VEcontainer, /etc/fstab (or most part of it) is no longer needed. Empty it (excluding the line lines for <code>/dev/pts</code>, <code>/proc</code>, <code>/sys</code> and such):<source lang="bash"> mv /vz/private/123/etc/fstab /vz/private/123/etc/fstab.old egrep '/dev/pts|/dev/shm|/proc|/sys' /vz/private/123/etc/fstab.old > /vz/private/123/etc/fstab</source>

You can also mount a devpts in a running (but not fully functional) container: cp /vz/private/vzctl exec 123/etc/fstab /vz/private/123/etc/fstab.old grep mount -t devpts none /vz/private/123/etc/fstab.old > /vz/private/123/etcdev/fstabpts

You can also mount A still better approach would be simply to copy the <code>/etc/fstab</code> from a devpts in previously created container from a running (but not fully functional) VEtemplate of the same or similar distribution. In the case of RedHat/CentOS 5 this is:<source lang="bash">none /dev/pts devpts vzctl exec 123 mount -t devpts rw 0 0</source>and for RedHat/CentOS 6:<source lang="bash">none /dev/pts devpts rw,gid=5,mode=620 0 0</source>

In order for VE container to work, some nodes should be present in VEcontainer's <code>/dev</code><code></code>. For modern distributions, udev is taking care of it. For a variety of reasons udev doesn't make much sense in a VEcontainer, so the best thing to do is to disable udev and create needed device nodes manually.

In order for vzctl enter to work, a VE container needs to have some entries in /dev. This can either be /dev/ttyp* and /dev/ptyp*, or /dev/ptmx and mounted /dev/pts.

Some system services can (or in some cases should) be disabledand/or uninstaled. A few good candidates are:

* checkfs, checkroot (no filesystem checking is required in VEcontainer)* clock (no clock setting is required/allowed in VEcontainer)* consolefont (VE container does not have a console)* hdparm (VE container does not have real hard drives)

* keymaps (VE container does not have a real keyboard)* kudzu (VE container does not have real hardware)* lm_sensors (VE container does not have access to hardware sensors)* microcodectl (VE container can not update CPU microcode)* netplugd (VE container does not have real Ethernet device)* irqbalance (this is handled in host node)* auditd ( not needed in container)* lvm2-monitor (no LVM in containers)* ntp/ntpd (clock taken from host node)

* RedHat/Fedora/SUSE: <code>/sbin/chkconfig --del SERVICENAME off </code>

Edit /vz/private/{VEIDCTID}/etc/sysconfig/network-scripts/ifcfg-eth''x''

iface eth0 inet dhcpstatic

== Starting a new VE container ==

Try to start your new VEcontainer:

=== Can't enter VE PHP not serving pages / random issues=== Make sure that /tmp and /var/tmp are created if you rsynced over your data and that they have proper permissions  mkdir tmp chmod 1777 tmp

=== Can't enter container === If you can not enter your VE container (using <code>vzctl enter</code>), you should be able to at least execute commands in it.

Then, add the appropriate mount command to VEcontainer's startup scripts. On some distros, you need to have the appropriate line in VEcontainer's /etc/fstab.

In Fedora, try commenting out any '''udev''' entries in /vz/private/{VEIDCTID}/etc/rc.sysinit vi /vz/private/{VEIDCTID}/etc/rc.sysinit

== Success Stories Scripting ==- Debian 3.1 Sarge For CentOS below are two scripts to help with MySQL, apache2, PowerDNSthe migration:--[* [Userhttp:Stoffell|stoffell]] 08:41, 8 February 2007 (EST) //pastebin.com/ehf8G3H6 pre- Red Hat 7.2 with MySQL 3copy.23, apache, Chilisoft --[[User:Stoffell|stoffell]sh] 13:26, 9 February 2007 (EST)Does the necessary configuration required for the migration of a server/VM to a CT. - Gentoo with Courier, Postfix, MySQL, Apache2--* [[Userhttp:bfrackie|bfrackie]] 19:00, 18 March 2007 (EST) - AltLinux Master with qmail, MySQL, Apache, etc - to Debian/testing with OpenVZ /pastebin.com/thn0sezV post--[[Usercopy.sh]:alexkuklin|alexkuklin]] Performs steps 5 and 6.

- Centos 4.4 with apache2== Success stories =={{Note|please add your line to the bottom of this list, SVN, TRAC, etc and do not forget to sign it using <code><nowiki>--[[User:bitherder|bitherder]] ~~~~</nowiki></code>}}