Changes

Jump to: navigation, search

Physical to container

238 bytes added, 11:07, 11 March 2008
m
Robot: Automated text replacement (-VE +container)
A rough description of how to migrate existing physical server into a [[VEcontainer]].
== Prepare a new “empty” VE container ==
For OpenVZ this would mean the following (assume you chose CT ID of 123):
== Copying the data ==
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 ===
/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 container because some devices might not exist. (/dev/ptmx or others)
# tar cjpf /tmp/mysystem.tar.bz2 / -X /tmp/excludes.excl
'''Advantage:''' You don't need to boot from a live cd, so your system doesn't really go down.
== Setting VE container parameters ==
=== OSTEMPLATE ===
=== IP address(es) ===
Also, you have to supply an IP for a new VEcontainer:
vzctl set 123 --ipadd x.x.x.x --save
== Making adjustments ==
Since VE container is a bit different to a real physical server, you have to edit some files inside your new VEcontainer.
=== /etc/inittab ===
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 '/getty/d' /vz/private/123/etc/inittab
ln -s /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.
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 ===
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 for /dev/pts):
cp /vz/private/123/etc/fstab /vz/private/123/etc/fstab.old
grep devpts /vz/private/123/etc/fstab.old > /vz/private/123/etc/fstab
You can also mount a devpts in a running (but not fully functional) VEcontainer:
vzctl exec 123 mount -t devpts none /dev/pts
==== Introduction: static /dev ====
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.
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.
==== tty device nodes ====
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.
===== /dev/ptmx =====
* acpid, amd (not needed)
* 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)
* klogd (unless you use iptables to LOG some packets)
* 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)
To see which services are enabled:
There might be other adjustments needed. Please add those here (just above this section) if you have more info.
== Starting a new VE container ==
Try to start your new VEcontainer:
vzctl start 123
== Troubleshooting ==
=== Can't enter VE 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.
First, see the [[#tty device nodes]] section above.
vzctl exec 123 mount -t devpts none /dev/pts
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
2,253
edits

Navigation menu