Difference between revisions of "Physical to container"

From OpenVZ Virtuozzo Containers Wiki
Jump to: navigation, search
(added mount command for dev/pts)
(Prepare a new “empty” container)
 
(147 intermediate revisions by 50 users not shown)
Line 1: Line 1:
A rough description of how to migrate existing physical server into a [[VE]].
+
A rough description of how to migrate existing physical server into a [[container]].
  
== Prepare a new “empty” VE ==
+
== Preparing to migrate ==
For OpenVZ this would mean the following (assume you chose VE ID of 123):
+
 
 +
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 bare minimum (including ssh daemon).
 +
 
 +
To 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. 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.
 +
 
 +
{{Note|Still better is to use this container from the same Linux distribution you want to migrate as the starting point for the new installation. In this case, if we are carefull to copy only the needed files from the original system, we will be able to skip many of the following steps.}}
  
 +
== 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
 
  mkdir /vz/root/123 /vz/private/123
  cat /etc/vz/conf/ve-vps.basic.conf-sample > /etc/vz/conf/123.conf
+
  cat /etc/vz/conf/ve-basic.conf-sample > /etc/vz/conf/123.conf
 +
</source>
 +
 
 +
{{Note|Now comes the dummy container handy mentioned above: Simply copy the xxx.conf file of the dummy to your new yyy.conf and modify it.}}
 +
 
 +
{{Note|If you have created a container from the same distro as the basis for the migration, simply take note of the CT ID and skip this step.}}
  
 +
== Copying the data ==
  
== Preparing to migrate ==
+
Copy all your data from the machine to an OpenVZ box. Say you'll be using 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:
  
Stop most services on a machine to be migrated. “Most” means services such as web server, databases and the like — so you will not loose your data. Just leave the bare minimum (including ssh daemon).
+
=== rsync ===
 +
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 -avz -H -X --one-file-system --numeric-ids --exclude-from=/tmp/exclude.txt -e ssh root@a.b.c.d:/ /vz/private/123/
 +
</source>
  
== Copying the data ==
+
{{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}}
  
Copy all your data from the machine to an OpenVZ box. Say you'll be using VE 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 by scp or rsync.
+
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>
  
 
'''Advantage:''' Your system doesn't really go down.
 
'''Advantage:''' Your system doesn't really go down.
  
 +
{{Note|To decrease the downtime, you can use double rsync approach. Run rsync for the first time before stopping most of the services, and then for the second time after stopping services. That way most of the data will be transferred while your server is fully working, and the second rsync will just "catch the latest changes" which is faster.}}
 +
 +
=== Live CD ===
 
Another way to do is using a live cd, booting up and use tar to dump the complete disk in a tar you save over the network or on a USB device.
 
Another way to do is using a live cd, booting up and use tar to dump the complete disk in a tar you save over the network or on a USB device.
  
 +
=== Tar ===
 
Another approach is using tar and excluding some dirs, you could do it like this:
 
Another approach is using tar and excluding some dirs, you could do it like this:
  
Line 32: Line 68:
 
  /usr/src/*
 
  /usr/src/*
  
Then create the tar. But remember, when the system is 'not' using udev, you have to look into /proc/ after creating your VE because some devices might not exist. (/dev/ptmx or others)
+
Then create the tar. But remember, when the system is 'not' using udev, you have to look into /proc/ after creating your container because some devices might not exist. (/dev/ptmx or others)
  
  # tar cjpf /tmp/mysystem.tar.bz2 / -X /tmp/excludes.excl
+
  # tar --numeric-owner -cjpf /tmp/mysystem.tar.bz2 / -X /tmp/excludes.excl
  
 
Naturally, you can only do this when the critical services (MySQL, apache, ..) are stopped and your /tmp filesystem is big enough to contain your tar.
 
Naturally, you can only do this when the critical services (MySQL, apache, ..) are stopped and your /tmp filesystem is big enough to contain your tar.
  
'''Advantage:''' You don't need to boot from a livecd, so your system doesn't really go down.
+
'''Advantage:''' You don't need to boot from a live cd, so your system doesn't really go down.
  
== Set VE parameters ==
+
== Setting container parameters ==
  
 
=== OSTEMPLATE ===
 
=== OSTEMPLATE ===
 
You have to add <code>OSTEMPLATE=xxx</code> line to <code>/etc/vz/conf/123.conf</code> file, where <code>xxx</code> would be distribution name (like <code>debian-3.0</code>) for vzctl to be able to make changes specific for this distribution.
 
You have to add <code>OSTEMPLATE=xxx</code> line to <code>/etc/vz/conf/123.conf</code> file, where <code>xxx</code> would be distribution name (like <code>debian-3.0</code>) for vzctl to be able to make changes specific for this distribution.
 +
 +
{{Note|If you copied from the dummy container or are using it as basis for your migrated system then this step is already accomplished.}}
  
 
=== IP address(es) ===
 
=== IP address(es) ===
Also, you have to supply an IP for a new VE:
+
Also, you have to supply an IP for a new container:
 
   
 
   
 
  vzctl set 123 --ipadd x.x.x.x --save
 
  vzctl set 123 --ipadd x.x.x.x --save
 +
 +
=== venet vs. veth ===
 +
You may use veth interface instead of venet if you need just bring old server up for seamless migration of services.
 +
It may be nessessary if server you are migrating is badly configured and it is hard to find all hard-coded net interfaces settings and so on.
 +
 +
veth inteface may be included into bridge to allow seamless old installation access.
  
 
== Making adjustments ==
 
== Making adjustments ==
Since VE is a bit different than a real physical server, you have to edit some files inside your new VE.
+
Since container is a bit different to a real physical server, you have to edit some files inside your new container.
  
 
=== /etc/inittab ===
 
=== /etc/inittab ===
A VE 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>).
+
A 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 '/getty/d' /vz/private/123/etc/inittab
+
  sed -i -e 's/^[0-9].*getty.*tty/#&/g' /vz/private/123/etc/inittab
  
 
=== /etc/mtab ===
 
=== /etc/mtab ===
Link <code>/etc/mtab</code> to <code>/proc/mounts</code>:
+
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
  
rm -f /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.
ln -s /proc/mounts /vz/private/123/etc/mtab  
+
 
 +
Sure this is not the only way to fix df; you can just manually add a line to <code>/etc/mtab</code> telling <code>/</code> is mounted, and make sure this line will be there after a reboot.}}
  
 
=== /etc/fstab ===
 
=== /etc/fstab ===
Since you do not have any real disk partitions in a VE, /etc/fstab (or most part of it) is no longer needed. Empty it (excluding the line for /dev/pts):
+
Since you do not have any real disk partitions in a container, /etc/fstab (or most part of it) is no longer needed. Empty it (excluding the 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>
  
  cp /vz/private/123/etc/fstab /vz/private/123/etc/fstab.old
+
You can also mount a devpts in a running (but not fully functional) container:
grep devpts /vz/private/123/etc/fstab.old > /vz/private/123/etc/fstab
+
  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.
  
You can also mount a devpts in a running (but not fully functional) VE:
+
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.
vzctl exec 123 mount -t devpts none /dev/pts
+
 
 +
{{Note|Now comes the dummy container handy mentioned above: Simply copy the entire /dev directory of the dummy to your new migrated container - worked in my case at least with Debian Etch.}}
 +
 
 +
==== tty device nodes ====
  
=== /dev TTY devices ===
+
In order for vzctl enter to work, a container needs to have some entries in /dev. This can either be /dev/ttyp* and /dev/ptyp*, or /dev/ptmx and mounted /dev/pts.
In order for vzctl enter to work, a VE need to have some entries in /dev. This can either be /dev/ttyp* and /dev/ptyp*, or /dev/ptmx and mounted /dev/pts.
 
  
==== /dev/ptmx ====
+
===== /dev/ptmx =====
 
Check that /dev/ptmx exists. If it does not, create with:
 
Check that /dev/ptmx exists. If it does not, create with:
  mknod /vz/private/123/dev/ptmx c 5 2
+
  mknod --mode 666 /vz/private/123/dev/ptmx c 5 2
  
==== /dev/pts/ ====
+
===== /dev/pts/ =====
 
Check that /dev/pts exists. It's a directory, if it does not exist, create with:
 
Check that /dev/pts exists. It's a directory, if it does not exist, create with:
 
  mkdir /vz/private/123/dev/pts
 
  mkdir /vz/private/123/dev/pts
  
==== /dev/ttyp* and /dev/ptyp* ====
+
===== /dev/ttyp* and /dev/ptyp* =====
 
Check that /dev/ttyp* and /dev/ptyp* files are there. If not, you have to create those, either by using /sbin/MAKEDEV, or by copying them from the host system.
 
Check that /dev/ttyp* and /dev/ptyp* files are there. If not, you have to create those, either by using /sbin/MAKEDEV, or by copying them from the host system.
  
Line 95: Line 170:
 
  cd /vz/private/123/dev && /sbin/MAKEDEV ttyp
 
  cd /vz/private/123/dev && /sbin/MAKEDEV ttyp
  
=== Other ===
+
====/dev/null====
There might be other adjustments needed. Please add those here if you have more info.
+
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
 +
 
 +
==== /dev/urandom ====
 +
Check that /dev/urandom exists. If it does not, create with:
 +
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
 +
 
 +
=== /etc/init.d services ===
 +
 
 +
Some system services can (or in some cases should) be disabled and/or uninstaled. A few good candidates are:
 +
 
 +
* acpid, amd (not needed)
 +
* checkfs, checkroot (no filesystem checking is required in container)
 +
* clock (no clock setting is required/allowed in container)
 +
* consolefont (container does not have a console)
 +
* hdparm (container does not have real hard drives)
 +
* klogd (unless you use iptables to LOG some packets)
 +
* keymaps (container does not have a real keyboard)
 +
* kudzu (container does not have real hardware)
 +
* lm_sensors (container does not have access to hardware sensors)
 +
* microcodectl (container can not update CPU microcode)
 +
* netplugd (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)
 +
 
 +
To see which services are enabled:
 +
* RedHat/Fedora/SUSE: <code>/sbin/chkconfig --list</code>
 +
* Debian: Use '<code>rcconf</code>' (ncurses) or <code>update-rc.d</code>
 +
( See: http://www.debianadmin.com/manage-linux-init-or-startup-scripts.html )
 +
* Gentoo: <code>/sbin/rc-update show</code>
 +
 
 +
To disable the service:
 +
* RedHat/Fedora/SUSE: <code>/sbin/chkconfig SERVICENAME off </code>
 +
* Debian: <code>' update-rc.d -f hdparm remove '</code>
 +
* Gentoo: <code>/sbin/rc-update del SERVICENAME</code>
 +
 
 +
=== Disable old network interface ===
 +
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 used. These two files might exist if the 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 upgrading
 +
auto lo eth0
 +
iface 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 =====
  
Try to start your new VE:
+
Here what I have done for my Ubuntu server JEOS 8.04.2
 +
 
 +
<pre>
 +
rm /vz/private/123/etc/network/if-up.d/ntpdate
 +
rm /vz/private/123/etc/event.d/tty{1,2,3,4,5,6}
 +
vzctl exec 123 update-rc.d -f klogd remove
 +
vzctl 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.sysinit
 +
Comment 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 container:
 
   
 
   
 
  vzctl start 123
 
  vzctl start 123
  
 
Now check that everything works fine. If not, see [[#Troubleshooting]] below.
 
Now check that everything works fine. If not, see [[#Troubleshooting]] below.
 +
  
 
== Troubleshooting ==
 
== Troubleshooting ==
  
=== 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
  
If you can not enter your VE (using <code>vzctl enter</code>), you should be able to at least execute commands in it.
+
mkdir tmp
 +
chmod 1777 tmp
  
First, see the [[#/dev TTY devices]] section above.
+
=== 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 [[#tty device nodes]] section above.
  
 
Next, check if devpts is mounted:
 
Next, check if devpts is mounted:
Line 120: Line 317:
 
  vzctl exec 123 mount -t devpts none /dev/pts
 
  vzctl exec 123 mount -t devpts none /dev/pts
  
Then, add the appropriate mount command to VE's startup scripts. On some distros, you need to have the appropriate line in VE's /etc/fstab.
+
Then, add the appropriate mount command to container's startup scripts. On some distros, you need to have the appropriate line in container's /etc/fstab.
 +
 
 +
In Fedora, try commenting out any '''udev''' entries in /vz/private/{CTID}/etc/rc.sysinit
 +
vi /vz/private/{CTID}/etc/rc.sysinit
 +
Locate the '''udev''' entry from within vim
 +
/udev
 +
Then comment the line similar to this:
 +
#[ -x /sbin/start_udev ] && /sbin/start_udev
  
 
=== Other problems ===
 
=== Other problems ===
 
If anything goes wrong, try to find out why and fix. If you have enough Linux experience, it can be handled. Also check out IRC and please report back on this page.
 
If anything goes wrong, try to find out why and fix. If you have enough Linux experience, it can be handled. Also check out IRC and please report back on this page.
  
== Success Stories ==
+
== Scripting ==
- Debian 3.1 Sarge with MySQL, apache2, PowerDNS
+
For CentOS below are two scripts to help with the migration:
--[[User:Stoffell|stoffell]] 08:41, 8 February 2007 (EST)
+
* [http://pastebin.com/ehf8G3H6 pre-copy.sh]: Does the necessary configuration required for the migration of a server/VM to a CT.
 +
* [http://pastebin.com/thn0sezV post-copy.sh]: Performs steps 5 and 6.
 +
 
 +
== Success stories ==
 +
{{Note|please add your line to the bottom of this list, and do not forget to sign it using <code><nowiki>--~~~~</nowiki></code>}}
  
 +
* Debian 3.1 Sarge with MySQL, apache2, PowerDNS --[[User:Stoffell|stoffell]] 08:41, 8 February 2007 (EST)
 +
* Red Hat 7.2 with MySQL 3.23, apache, Chilisoft --[[User:Stoffell|stoffell]] 13:26, 9 February 2007 (EST)
 +
* Gentoo with Courier, Postfix, MySQL, Apache2 --[[User:bfrackie|bfrackie]] 19:00, 18 March 2007 (EST)
 +
* AltLinux Master with qmail, MySQL, Apache, etc - to Debian/testing with OpenVZ --[[User:alexkuklin|alexkuklin]] 16:16, 23 March 2007 (EST)
 +
* Centos 4.4 with apache2, SVN, TRAC, etc. --[[User:bitherder|bitherder]] 23:38, 26 February 2008 (EST)
 +
* Centos 4.6 with apache2, Tomcat 5.0.x, postgresql, etc on CentOS 5.1 64bit Host --[[User:laslos|laslos]] 17:35, 10 March 2008 (EST)
 +
* Debian Etch with apache2 etc... on CentOS 4.6 Host --[[User:laslos|laslos]] 19:46, 10 March 2008 (EST)
 +
* Debian 1:3.3.5-13 with apache2, PHP, etc. --[[User:Spawrks|spawrks]] 23:36, 10 April 2008 (EST)
 +
* Debian Etch with apache2, MySQL, etc. --[[User:Zhafrance|zhafrance]] 16:29, 20 April 2008 (EST)
 +
* Debian Etch i386 with apache2, MySQL, etc. --[[User:geejay|geejay]] 17:29, 26 May 2008 (GMT)
 +
* Centos 4.6 with apache2, MySQL, Qmail etc. --[[User:Bharathchari|Bharathchari]] 08:06, 13 June 2008 (EDT)
 +
* Centos 4.6 with cPanel/WHM (Apache2, Mysql, Exim, etc) --[[User:Zccopwrx|Zccopwrx]] 08:16, 30 July 2008 (EDT)
 +
* SlackWare 10.1 (Qmail) --[[User:defiancenl|defiancenl]]
 +
* SlackWare 10.0 (Qmail) --[[User:defiancenl|defiancenl]]
 +
* Ubuntu 8.04.3 LTS JEOS (Apache2, Mysql) --[[User:bougui|bougui]] Fri Aug 28 10:40:41 EDT 2009
 +
* CentOS 5.3 (Apache2, Mysql, Cacti) --[[User:kofl|kofl]] September 12 2009
 +
* Scientific Linux 3.0.9 (Macrovision FLEXlm) {{unsigned|137.226.90.94|11:34, 4 November 2009}}
 +
* Red Hat Enterprise Linux 4 (rhel4) --[[User:Bpuklich|Bpuklich]] 17:20, 15 February 2010 (UTC)
 +
* Debian SID up-to-date with apache2, MySQL, posgrey etc. --nyquist 14:04, 06 July 2010 (UTC)
 +
* Centos 5.x with Plesk -- 05:33, 17 August 2010 (UTC)
 +
* Redhat 4 -- 20:32, 18 August 2010 (UTC)
 +
* Fedora 4 -- 15:06, 20 August 2010 (UTC)
 +
* Fedora 9 x64 with FDS and samba PDC --burn 23:20 10 October 2010
 +
* Fedora 3 x32 with Plesk -- 23 October 2010 --[[User:Rexwickham|Rex Wickham (2020media.com)]] 13:15, 23 October 2010 (UTC)
 
[[Category:HOWTO]]
 
[[Category:HOWTO]]
 +
* Debian 6 (Squeeze) with Lighttpd, MySQL, nfs, smb, etc. --[[Special:Contributions/95.21.175.189|95.21.175.189]] 22:39, 30 July 2011 (UTC)
 +
* RedHat 9 (Shrike) with apache,nginx,mysql,qmail 09 August 2011 (UTC)
 +
* Centos 5.6 with Postresql and JitterBit 24 August 2011
 +
* Centos 4.9 with MySQL, Apache, ColdFusion, etc. 26 August 2011
 +
* Centos 5.6 with MySQL, Apache, BIND, Postfix, Mono, etc.  26 August 2011
 +
* Centos 5.7 with MySQL, Apache, Nginx, Memcached, Postfix, Openx, etc.  --[[User:juranas|Juranas]] 18 November 2011
 +
* RedHat Enterprise Linux 5 (rhel 5.6 - x86_64) 14:50, 18 November 2011
 +
* Debian 6.0.4 with DTC Hosting Contro Panel . 15:00, 14 May 2012
 +
* Debian 6, LAMP with ISPManager CP (no adjustments were made, just transferred the file structure and created  ctid.conf) 03:19, 15 Jun 2012
 +
* Debian 5.0.3, with Mysql, Apache, ISCP omega, Postfix, etc --[[Special:Contributions/91.143.222.253|91.143.222.253]] 19:47, 28 June 2012 (EDT)
 +
* Debian 6.0.5 with artica-zarafa, 20 Nov 2012

Latest revision as of 06:03, 26 October 2017

A rough description of how to migrate existing physical server into a container.

Preparing to migrate[edit]

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 bare minimum (including ssh daemon).

To 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. 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.

Yellowpin.svg Note: Still better is to use this container from the same Linux distribution you want to migrate as the starting point for the new installation. In this case, if we are carefull to copy only the needed files from the original system, we will be able to skip many of the following steps.

Prepare a new “empty” container[edit]

For OpenVZ this would mean the following (assume you chose CT ID of 123):

 mkdir /vz/root/123 /vz/private/123
 cat /etc/vz/conf/ve-basic.conf-sample > /etc/vz/conf/123.conf
Yellowpin.svg Note: Now comes the dummy container handy mentioned above: Simply copy the xxx.conf file of the dummy to your new yyy.conf and modify it.
Yellowpin.svg Note: If you have created a container from the same distro as the basis for the migration, simply take note of the CT ID and skip this step.

Copying the data[edit]

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

rsync[edit]

On the new HN create a file /tmp/exclude.txt with:

/tmp
/boot
/lib/modules
/etc/blkid
/etc/mtab
/etc/lvm
/etc/fstab
/etc/udev

and run rsync as follows:

 rsync -avz -H -X --one-file-system --numeric-ids --exclude-from=/tmp/exclude.txt -e ssh root@a.b.c.d:/ /vz/private/123/
Yellowpin.svg Note: You should add the -H option, so hardlinks will be preserved during sync and also include the -X option to preserve file extended attributes

If your source system have multiple partitions (for example /var or /home) repeat the command above for each partition in your system; for example:

rsync -avz -H -X --one-file-system --numeric-ids -e ssh root@a.b.c.d:/var/ /vz/private/123/var/

Advantage: Your system doesn't really go down.

Yellowpin.svg Note: To decrease the downtime, you can use double rsync approach. Run rsync for the first time before stopping most of the services, and then for the second time after stopping services. That way most of the data will be transferred while your server is fully working, and the second rsync will just "catch the latest changes" which is faster.

Live CD[edit]

Another way to do is using a live cd, booting up and use tar to dump the complete disk in a tar you save over the network or on a USB device.

Tar[edit]

Another approach is using tar and excluding some dirs, you could do it like this:

Create a file /tmp/excludes.excl with these contents:

.bash_history
/dev/*
/mnt/*
/tmp/*
/proc/*
/sys/*
/usr/src/*

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

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

Naturally, you can only do this when the critical services (MySQL, apache, ..) are stopped and your /tmp filesystem is big enough to contain your tar.

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

Setting container parameters[edit]

OSTEMPLATE[edit]

You have to add OSTEMPLATE=xxx line to /etc/vz/conf/123.conf file, where xxx would be distribution name (like debian-3.0) for vzctl to be able to make changes specific for this distribution.

Yellowpin.svg Note: If you copied from the dummy container or are using it as basis for your migrated system then this step is already accomplished.

IP address(es)[edit]

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

vzctl set 123 --ipadd x.x.x.x --save

venet vs. veth[edit]

You may use veth interface instead of venet if you need just bring old server up for seamless migration of services. It may be nessessary if server you are migrating is badly configured and it is hard to find all hard-coded net interfaces settings and so on.

veth inteface may be included into bridge to allow seamless old installation access.

Making adjustments[edit]

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

/etc/inittab[edit]

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


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

/etc/mtab[edit]

Link /etc/mtab to /proc/mounts, for df to work properly:

ln -sf /proc/mounts /vz/private/123/etc/mtab
The problem here is container's root filesystem (/) is mounted not from the container itself, but rather from the host system. That leaves /etc/mtab in container without a record for / being mounted, thus df doesn't show it. By linking /etc/mtab → /proc/mounts we make sure /etc/mtab shows what is really mounted in a container. Sure this is not the only way to fix df; you can just manually add a line to /etc/mtab telling / is mounted, and make sure this line will be there after a reboot.

/etc/fstab[edit]

Since you do not have any real disk partitions in a container, /etc/fstab (or most part of it) is no longer needed. Empty it (excluding the lines for /dev/pts, /proc, /sys and such):

 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

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 /etc/fstab from a previously created container from a template of the same or similar distribution. In the case of RedHat/CentOS 5 this is:

none    /dev/pts        devpts  rw      0       0

and for RedHat/CentOS 6:

none    /dev/pts        devpts  rw,gid=5,mode=620       0       0

/dev[edit]

Yellowpin.svg Note: Once again if you are using the container from the same distro as basis, and you were carefull to not overwrite /dev with rsync by using the --one-file-system option, you can skip this section

Introduction: static /dev[edit]

In order for container to work, some nodes should be present in container's /dev. 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 /dev is mounted on tmpfs — this will not work in case of static /dev. So what you need to do is find out where /dev is being mounted on tmpfs 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 /dev 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 umask (w:umask). You can use --mode option for mknod to set the desired permissions.

Yellowpin.svg Note: Now comes the dummy container handy mentioned above: Simply copy the entire /dev directory of the dummy to your new migrated container - worked in my case at least with Debian Etch.

tty device nodes[edit]

In order for vzctl enter to work, a 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[edit]

Check that /dev/ptmx exists. If it does not, create with:

mknod --mode 666 /vz/private/123/dev/ptmx c 5 2
/dev/pts/[edit]

Check that /dev/pts exists. It's a directory, if it does not exist, create with:

mkdir /vz/private/123/dev/pts
/dev/ttyp* and /dev/ptyp*[edit]

Check that /dev/ttyp* and /dev/ptyp* files are there. If not, you have to create those, either by using /sbin/MAKEDEV, or by copying them from the host system.

To copy:

cp -a /dev/ttyp* /dev/ptyp* /vz/private/123/dev/

To recreate with MAKEDEV, either

/sbin/MAKEDEV -d /vz/private/123/dev ttyp ptyp

or

cd /vz/private/123/dev && /sbin/MAKEDEV ttyp

/dev/null[edit]

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

/dev/urandom[edit]

Check that /dev/urandom exists. If it does not, create with:

mknod --mode 444 /vz/private/123/dev/urandom c 1 9

Using udev anyway[edit]

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[edit]

Yellowpin.svg 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

/etc/init.d services[edit]

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

  • acpid, amd (not needed)
  • checkfs, checkroot (no filesystem checking is required in container)
  • clock (no clock setting is required/allowed in container)
  • consolefont (container does not have a console)
  • hdparm (container does not have real hard drives)
  • klogd (unless you use iptables to LOG some packets)
  • keymaps (container does not have a real keyboard)
  • kudzu (container does not have real hardware)
  • lm_sensors (container does not have access to hardware sensors)
  • microcodectl (container can not update CPU microcode)
  • netplugd (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)

To see which services are enabled:

  • RedHat/Fedora/SUSE: /sbin/chkconfig --list
  • Debian: Use 'rcconf' (ncurses) or update-rc.d

( See: http://www.debianadmin.com/manage-linux-init-or-startup-scripts.html )

  • Gentoo: /sbin/rc-update show

To disable the service:

  • RedHat/Fedora/SUSE: /sbin/chkconfig SERVICENAME off
  • Debian: ' update-rc.d -f hdparm remove '
  • Gentoo: /sbin/rc-update del SERVICENAME

Disable old network interface[edit]

You should disable your old physical network interface from starting at boot time. This is distribution-dependant.

Fedora/CentOS/Red Hat[edit]

Edit /vz/private/{CTID}/etc/sysconfig/network-scripts/ifcfg-ethx

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 used. These two files might exist if the 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]

Edit /etc/network/interfaces

# /etc/network/interfaces -- configuration file for ifup(8),  ifdown(8)

# The loopback interface
# automatically added when upgrading
auto lo eth0
iface 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

You can either comment out the eth* interface stanza(s), or take it out of the "auto" line(s).

Ubuntu server 8.x[edit]

Here what I have done for my Ubuntu server JEOS 8.04.2

rm /vz/private/123/etc/network/if-up.d/ntpdate
rm /vz/private/123/etc/event.d/tty{1,2,3,4,5,6} 
vzctl exec 123 update-rc.d -f klogd remove
vzctl exec 123 update-rc.d -f udev remove

openSUSE/SLES[edit]

Use Yast.

Disable udev if you create DEVNODES devices[edit]

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.sysinit Comment the line similar to this:

#[ -x /sbin/start_udev ] && /sbin/start_udev

Other adjustments[edit]

There might be other adjustments needed. Please add those here (just above this section) if you have more info.

Starting a new container[edit]

Try to start your new container:

vzctl start 123

Now check that everything works fine. If not, see #Troubleshooting below.


Troubleshooting[edit]

PHP not serving pages / random issues[edit]

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[edit]

If you can not enter your container (using vzctl enter), you should be able to at least execute commands in it.

First, see the #tty device nodes section above.

Next, check if devpts is mounted:

vzctl exec 123 mount | grep pts

If it is not mounted, mount it:

vzctl exec 123 mount -t devpts none /dev/pts

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

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

vi /vz/private/{CTID}/etc/rc.sysinit

Locate the udev entry from within vim

/udev

Then comment the line similar to this:

#[ -x /sbin/start_udev ] && /sbin/start_udev

Other problems[edit]

If anything goes wrong, try to find out why and fix. If you have enough Linux experience, it can be handled. Also check out IRC and please report back on this page.

Scripting[edit]

For CentOS below are two scripts to help with the migration:

  • pre-copy.sh: Does the necessary configuration required for the migration of a server/VM to a CT.
  • post-copy.sh: Performs steps 5 and 6.

Success stories[edit]

Yellowpin.svg Note: please add your line to the bottom of this list, and do not forget to sign it using --~~~~
  • Debian 3.1 Sarge with MySQL, apache2, PowerDNS --stoffell 08:41, 8 February 2007 (EST)
  • Red Hat 7.2 with MySQL 3.23, apache, Chilisoft --stoffell 13:26, 9 February 2007 (EST)
  • Gentoo with Courier, Postfix, MySQL, Apache2 --bfrackie 19:00, 18 March 2007 (EST)
  • AltLinux Master with qmail, MySQL, Apache, etc - to Debian/testing with OpenVZ --alexkuklin 16:16, 23 March 2007 (EST)
  • Centos 4.4 with apache2, SVN, TRAC, etc. --bitherder 23:38, 26 February 2008 (EST)
  • Centos 4.6 with apache2, Tomcat 5.0.x, postgresql, etc on CentOS 5.1 64bit Host --laslos 17:35, 10 March 2008 (EST)
  • Debian Etch with apache2 etc... on CentOS 4.6 Host --laslos 19:46, 10 March 2008 (EST)
  • Debian 1:3.3.5-13 with apache2, PHP, etc. --spawrks 23:36, 10 April 2008 (EST)
  • Debian Etch with apache2, MySQL, etc. --zhafrance 16:29, 20 April 2008 (EST)
  • Debian Etch i386 with apache2, MySQL, etc. --geejay 17:29, 26 May 2008 (GMT)
  • Centos 4.6 with apache2, MySQL, Qmail etc. --Bharathchari 08:06, 13 June 2008 (EDT)
  • Centos 4.6 with cPanel/WHM (Apache2, Mysql, Exim, etc) --Zccopwrx 08:16, 30 July 2008 (EDT)
  • SlackWare 10.1 (Qmail) --defiancenl
  • SlackWare 10.0 (Qmail) --defiancenl
  • Ubuntu 8.04.3 LTS JEOS (Apache2, Mysql) --bougui Fri Aug 28 10:40:41 EDT 2009
  • CentOS 5.3 (Apache2, Mysql, Cacti) --kofl September 12 2009
  • Scientific Linux 3.0.9 (Macrovision FLEXlm) —The preceding unsigned comment was added by 137.226.90.94 (talkcontribs) 11:34, 4 November 2009.
  • Red Hat Enterprise Linux 4 (rhel4) --Bpuklich 17:20, 15 February 2010 (UTC)
  • Debian SID up-to-date with apache2, MySQL, posgrey etc. --nyquist 14:04, 06 July 2010 (UTC)
  • Centos 5.x with Plesk -- 05:33, 17 August 2010 (UTC)
  • Redhat 4 -- 20:32, 18 August 2010 (UTC)
  • Fedora 4 -- 15:06, 20 August 2010 (UTC)
  • Fedora 9 x64 with FDS and samba PDC --burn 23:20 10 October 2010
  • Fedora 3 x32 with Plesk -- 23 October 2010 --Rex Wickham (2020media.com) 13:15, 23 October 2010 (UTC)
  • Debian 6 (Squeeze) with Lighttpd, MySQL, nfs, smb, etc. --95.21.175.189 22:39, 30 July 2011 (UTC)
  • RedHat 9 (Shrike) with apache,nginx,mysql,qmail 09 August 2011 (UTC)
  • Centos 5.6 with Postresql and JitterBit 24 August 2011
  • Centos 4.9 with MySQL, Apache, ColdFusion, etc. 26 August 2011
  • Centos 5.6 with MySQL, Apache, BIND, Postfix, Mono, etc. 26 August 2011
  • Centos 5.7 with MySQL, Apache, Nginx, Memcached, Postfix, Openx, etc. --Juranas 18 November 2011
  • RedHat Enterprise Linux 5 (rhel 5.6 - x86_64) 14:50, 18 November 2011
  • Debian 6.0.4 with DTC Hosting Contro Panel . 15:00, 14 May 2012
  • Debian 6, LAMP with ISPManager CP (no adjustments were made, just transferred the file structure and created ctid.conf) 03:19, 15 Jun 2012
  • Debian 5.0.3, with Mysql, Apache, ISCP omega, Postfix, etc --91.143.222.253 19:47, 28 June 2012 (EDT)
  • Debian 6.0.5 with artica-zarafa, 20 Nov 2012