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 you chose VE ID of 123including ssh daemon):.

mkdir /vz/root/123 /vz/private/123 cat /etc/vz/conf/ve-vpsTo make things easier you may like to first follow the basic instructions elsewhere and create a dummy container based on the same Linux distribution you want to migrate.basicThat way you can take that dummy as a template and then copy to your new migrated container and modify.conf-sample > /etc/vz/conf/123You can later discard this dummy.conf

== Preparing to migrate Prepare a new “empty” container ==For OpenVZ this would mean the following (assume you chose CT ID of 123):<source lang="bash"> mkdir /vz/root/123 /vz/private/123 cat /etc/vz/conf/ve-basic.conf-sample > /etc/vz/conf/123.conf</source>

Stop most services on a machine to be migrated{{Note|Now comes the dummy container handy mentioned above: Simply copy the xxx. “Most” means services such as web server, databases and conf file of the like — so you will not loose dummy to your datanew yyy. Just leave the bare minimum (including ssh daemon)conf and modify it.}}

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

'''Advantage:''' You don't need to boot from a livecdlive cd, so your system doesn't really go down.

== Setting VE container parameters ==

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

Since VE container is a bit different than 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

Link <code>/etc/mtab</code> to <code>/proc/mounts</code>, for <code>df</code> to work properly:  ln -sf /proc/mounts /vz/private/123/etc/mtab {{out|The problem here is container's root filesystem (<code>/</code>) is mounted not from the container itself, but rather from the host system. That leaves <code>/etc/mtab</code> in 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 container.

rm -f /vz/private/123Sure this is not the only way to fix df; you can just manually add a line to <code>/etc/mtab ln -s </proccode> telling <code>/mounts </vz/private/123/etc/mtab code> is mounted, and make sure this line will be there after a reboot.}}

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: vzctl exec 123 mount -t devpts none /dev/pts A still better approach would be simply to copy the <code>/etc/fstab</code> from a previously created container from a template of the same or similar distribution. In the case of RedHat/CentOS 5 this is:<source lang="bash">none /dev/pts 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> === /dev ==={{Note| Once again if you are using the container from the same distro as basis, and you were carefull to not overwrite <code>/dev</code> with <b>rsync</b> by using the <code>--one-file-system</code> option, you can skip this section}} ==== Introduction: static /dev ====In order for container to work, some nodes should be present in container'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 container, so the best thing to do is to disable udev and create needed device nodes manually. Note that in some distributions <code>/dev</code> is mounted on <code>tmpfs</code> — this will not work in case of static <code>/dev</code>. So what you need to do is find out where <code>/dev</code> is being mounted on <code>tmpfs</code> and remove this. This is highly distribution-dependent; please add info for your distro here. For Suse 11.0, It is found in /etc/init.d/boot  After you made sure your <code>/dev</code> is static, populate it with needed device nodes. Please pay attention to the access permissions of the device files being created:a default file mode for newly created files is affected by <code>umask</code> ([[w:umask]]). You can use --mode option for <code>mknod</code> to set the desired permissions.

cp {{Note|Now comes the dummy container handy mentioned above: Simply copy the entire /vz/private/123/etc/fstab /vz/private/123/etc/fstab.old grep devpts /vz/private/123/etc/fstabdev directory of the dummy to your new migrated container - worked in my case at least with Debian Etch.old > /vz/private/123/etc/fstab}}

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

===== /dev/ptmx =====

mknod --mode 666 /vz/private/123/dev/ptmx c 5 2

===== /dev/pts/ =====

===== /dev/ttyp* and /dev/ptyp* =====

=== Other devices =/dev/null====Make sure sure /dev/null is not a file or directory; if unsure remove and recreate. If this is not correct sshd will not start correctly. rm -f /vz/private/123/dev/null mknod --mode 666 /vz/private/123/dev/null c 1 3

mknod --mode 444 /vz/private/123/dev/urandom c 1 9 ==== Using udev anyway ====CentOS 5 can run in a container with udev enabled. You need to create /etc/udev/devices, containing the above device nodes. Also, the following will create the extra device nodes you need mkdir /vz/private/123/etc/udev/devices /sbin/MAKEDEV -d /vz/private/123/dev {p,t}ty{a,p}{0,1,2,3,4,5,6,7,8,9,a,b,c,d,e,f} console core full kmem kmsg mem null port ptmx random urandom zero ram0 /sbin/MAKEDEV -d /vz/private/123/etc/udev/devices {p,t}ty{a,p}{0,1,2,3,4,5,6,7,8,9,a,b,c,d,e,f} console core full kmem kmsg mem null port ptmx random urandom zero ram0 ===/proc==={{Note| One more time you may skip this if you are using a container created from a template of the same distro as your basis system.}} Make sure the /proc directory exists: ls -la /vz/private/123/ | grep proc If it doesn't, create it: mkdir /vz/private/123/proc

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)

* Debian: Use '<code>*FIXME*rcconf</code>' (ncurses) or <code>update-rc.d</code>( See: http://www.debianadmin.com/manage-linux-init-or-startup-scripts.html )

* RedHat/Fedora/SUSE: <code>/sbin/chkconfig --del SERVICENAME off </code>* Debian: <code>*FIXME*' update-rc.d -f hdparm remove '</code>

=== Other Disable old network interface ===There might You should disable your old physical network interface from starting at boot time. This is distribution-dependant. ==== Fedora/CentOS/Red Hat ====Edit /vz/private/{CTID}/etc/sysconfig/network-scripts/ifcfg-eth''x'' Make the following look like this: ONBOOT=no If the files /vz/private/{CTID}/etc/sysconfig/network-scripts/ifdown-venet or/vz/private/{CTID}/etc/sysconfig/network-scripts/ifup-venet exist, make sure they won't be other adjustments neededused. Please add those here These two files might exist if you have more infothe physical server had OpenVZ installed. One way to do this is to rename them, like so: mv ifdown-venet SKIP.ifdown-venet Failing to do this will prevent networking from starting up correctly in the container. ==== Debian/Ubuntu ====Edit /etc/network/interfaces <pre># /etc/network/interfaces -- configuration file for ifup(8), ifdown(8) # The loopback interface# automatically added when upgradingauto lo eth0iface lo inet loopback iface eth0 inet static address 10.0.0.4 netmask 255.0.0.0 network 10.0.0.0 broadcast 10.0.0.255</pre> You can either comment out the eth* interface stanza(s), or take it out of the "auto" line(s).

== Starting a new VE === Ubuntu server 8.x =====

Here what I have done for my Ubuntu server JEOS 8.04.2 <pre>rm /vz/private/123/etc/network/if-up.d/ntpdaterm /vz/private/123/etc/event.d/tty{1,2,3,4,5,6} vzctl exec 123 update-rc.d -f klogd removevzctl exec 123 update-rc.d -f udev remove </pre> ==== openSUSE/SLES ==== Use Yast. === Disable udev if you create DEVNODES devices === If you are creating devices for the container with a DEVNODES statement in a veid.conf file then these devices may be overwritten/deleted by udev when the container starts. As udev cannot "see" the device from within the container it disables it. Therefore, if you have DEVNODES statements in veid.conf then disable udev. In Fedora, Redhat, Centos, try commenting out any '''udev''' entries in /vz/private/{CTID}/etc/rc.sysinitComment the line similar to this: #[ -x /sbin/start_udev ] && /sbin/start_udev === Other adjustments ===There might be other adjustments needed. Please add those here (just above this section) if you have more info. == Starting a new container == Try to start your new VEcontainer:

=== Can't enter VE PHP not serving pages / random issues===

If Make sure that /tmp and /var/tmp are created if you can not enter rsynced over your VE (using <code>vzctl enter</code>), you should be able to at least execute commands in it.data and that they have proper permissions

mkdir tmp chmod 1777 tmp === Can't enter container === If you can not enter your container (using <code>vzctl enter</code>), you should be able to at least execute commands in it. First, see the [[#/dev TTY devicestty device nodes]] section above.

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/{CTID}/etc/rc.sysinit vi /vz/private/{CTID}/etc/rc.sysinitLocate the '''udev''' entry from within vim /udevThen comment the line similar to this: #[ -x /sbin/start_udev ] && /sbin/start_udev

== 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) - Gentoo with Courier, Postfix, MySQL, Apache2Does the necessary configuration required for the migration of a server/VM to a CT.--[* [Userhttp:bfrackie|bfrackie]//pastebin.com/thn0sezV post-copy.sh] 19:00, 18 March 2007 (EST)Performs steps 5 and 6.

- AltLinux Master with qmail, MySQL, Apache== Success stories =={{Note|please add your line to the bottom of this list, etc - and do not forget to Debian/testing with OpenVZ sign it using <code><nowiki>--[[User:alexkuklin|alexkuklin]] ~~~~</nowiki></code>}}