OpenVZ

OpenVZ ist eine Art Virtualisierungssystem; Dabei kommt es nicht zu einer echten Virtualisierung wie bei KVM/XEN sondern das ganze ist eher vergleichbar mit Chroot-Jails unter FreeBSD oder Zones unter Solaris. User-Mode-Linux funktioniert ähnlich.

Bei OpenVZ werden virtuelle container (VE's) erzeugt, in welchen ein anderes Linux-System ähnlich einem chrooted-environment laufen. Die virtuellen Container sind separiert voneinander.

 

Anmerkungen zum Hostsystem

In diesem Artikel wird ein spezieller Kernel genutzt, welcher die Patches zu vswap beinhaltet. Diese sind im default Debian Kernel nicht vorhanden, werden aber benötigt. Die Patches sorgen dafür, dass den "Guests" Swap zugewiesen werden kann. Dies heißt, dass ein Update des Kernels nicht mittels apt-get durchgeführt werden sollte; der Kernel muss stattdessen mittels Debians tools und entsprechenden Patches als .deb zur Verfügung stehen. Auf dem Host finden sich im Verzeichnis "/root/openvz/" Pakete von der letzten Kernel-Installation.

Da alle Prozesse sämtlicher Container auf dem Host auftauchen, ist von einem killall im Host unbedingt abzusehen. Zum Beenden eines Prozesses muss die entsprechende PID ermittelt werden und dann ein kill -X PID ausgeführt werden.

Ein Überblick über die vorhandenen images, welche installiert werden können, findet sich auf dem Host im Verzeichnis "/vz/template/cache". Mögliche weitere Images finden sich hier.

Auf dem Host ist ein Software Raid 1 eingerichtet. In /home existiert ein symlink namens "virtualservers" welcher auf /vz zeigt. Das Verzeichnis /vz wiederrum ist ein Symlink, der auf /var/lib/vz zeigt. Das Verzeichnis /var/lib/vz liegt direkt auf dem Software Raid 1. Somit liegen ausschliesslich die virtuellen Container auf dem Software Raid, nicht jedoch das Host-System oder das /home Verzeichnis.

OpenVZ bietet eine Livemigration - Diese funktioniert auch. Das heißt, im Falle eines neuen Servers oder eines Umzuges, können sofern OpenVZ auf beiden Systemen eingerichtet ist, die Systeme unproblematisch migriert werden.

 

Anleitungen zu OpenVZ

Nachfolgend einige kleinere Anleitungen zu OpenVZ auf unserem Host-System.

Anlegen, Editieren und Löschen eines virtuellen containers

Das Anlegen eines virtuellen Containers ist einfach. Hierzu werden lediglich ein paar Informationen benötigt:

  1. Distribution die genutzt werden soll (32 oder 64bit?)
  2. Speicherplatz der zur Verfügung stehen soll
  3. Ram der zur Verfügung stehen soll
  4. IP(s) die hierfür genutzt werden sollen
  5. Hostnamen (Am besten den Kunden nach seiner Hauptdomain fragen - ansonsten vserverX.ip-minds.de wobei das X für die VEID steht, z.b. 200)
  6. Nameserver (84.201.38.3, 84.201.0.34, 194.187.164.20)

Für RAM/Swap stehen vordefinierte templates zur Verfügung, und zwar:

  1. ve-vswap-1024m.conf-sample
  2. ve-vswap-512m.conf-sample
  3. ve-vswap-256m.conf-sample
  4. ve-vswap-128m.conf-sample

Syntax

vzctl [flags] create CTID [--ostemplate name] [--config name] [--private path]
                  [--root path] [--ipadd addr] [--hostname name]

Anlegen des Containers:

alia:~# vzctl create 700 --ostemplate ubuntu-12.04-x86_64 --config vswap-256m
--ipadd 84.200.240.20 --hostname vserver700.domain.tld
Creating container private area (ubuntu-12.04-x86_64)
Performing postcreate actions
CT configuration saved to /etc/vz/conf/700.conf
Container private area was created

Das ostemplate ergibt sich aus den verfügbaren unter /vz/cache/templates/. Hier muss nichts entpackt werden. Die Konfiguration ergibt sich aus den obigen, es wird nur ve- am Anfang und .conf-sample am Ende weggelassen.

Setzen der initialen Konfiguration

alia:~# vzctl set 700 --onboot yes --userpasswd root:foobar --name vserver700
--description "some description" --nameserver 84.201.38.3
--nameserver 84.201.0.34 --nameserver 194.187.164.20 --diskspace 15G:16G
--diskinodes unlimited:unlimited --noatime yes --save
Name vserver700 assigned
Starting container ...
Container is mounted
Container start in progress...
Stopping container ...
Container was stopped
Container is unmounted
CT configuration saved to /etc/vz/conf/700.conf

Wichtig ist hierbei das die inodes auf unlimited gesetzt werden, es gibt sonst filesystem Probleme. Nameserver können soviele geaddet werden wie gewünscht. Das –save am Ende ist wichtig.

Editieren eines virtuellen Containers ist entweder über die Konfigurationsdateien in /etc/vz/conf möglich (VEID.conf z.B. 700.conf) oder mithilfe der vzctl set Befehle (siehe man vzctl). Wichtig ist bei vzctl immer ein –save am Ende zu haben, ansonsten speichert er die neuen Settings nicht.

Entfernen eines virtuellen Containers

Um einen virtuellen Container zu entfernen, benutzt man destroy:

alia:~# vzctl destroy 106
Destroying container private area: /vz/private/106
Container private area was destroyed

Wechseln in einen virtuellen Container

Mittels "vzctl enter" kann man in einen virtuellen Container aus dem Host herraus wechseln und so beispielsweise das Rootpasswort mittels passwd ändern, aber auch beliebige andere Dinge erledigen.

alia:~# vzctl enter 200
entered into CT 200
alia:/# whoami
root
alia:/#

Mittels "exit" verlässt man den Guest wie gewohnt.

Auflisten der virtuellen container

Nebst den eigens geschriebenen Scripten gibt es noch den Befehl vzlist:

Alle laufenden VEs

alia:~# vzlist
CTID      NPROC STATUS    IP_ADDR         HOSTNAME
101         62 running   84.200.xx.xx   mail.example.de
102         14 running   84.200.xx.x    kais
103          7 running   84.200.xx.xx   seti.example.de
104         68 running   84.200.xx.xx   example.de
200        229 running   84.201.xx.x    a.example.de
300         20 running   84.201.xx.x    example.example.de

Alle VEs

alia:~# vzlist --all
CTID      NPROC STATUS    IP_ADDR         HOSTNAME
101         62 running   84.200.xxx.xx   mail.example.de
102         14 running   84.200.xxx.x    kais
103          7 running   84.200.xxx.xx   seti.example.de
104         68 running   84.200.xxx.xx   example.de
106          - stopped   84.200.xxx.xx   news.xxx
107          - stopped   84.200.xxx.x    irule.example.de
200        229 running   84.201.xx.x     a.example.de
300         20 running   84.201.xx.xx    fln.example.de

Starten, Re-Starten und Stoppen eines virtuellen containers

Das Starten und Stoppen eines virtuellen Containers funktioniert mit dem Kommandozeilen Tool "vzctl". Dieses bekommt als ersten Parameter den Befehl "stop", "start" oder "restart" und anschließend die ID des Containers, welcher gestoppt respektive gestartet werden soll.

Beispiele:

alia:~# vzctl restart 103
Restarting container
Stopping container ...
Container was stopped
Container is unmounted
Starting container ...
Container is mounted
Adding IP address(es): 84.200.240.20
Setting CPU limit: 100
Setting CPU units: 1000
Setting CPUs: 3
Container start in progress...

Firewall, Traffic, Drosselung und Schutzmaßnahmen

Als Drosselung ist zu verstehen, einem Benutzer, der eine Bandbreite oder ein Transfervolumen überschreitet die Konnektivität einzuschränken. Eine einfache, dynamische Möglichkeit der Drosselung ist ohne Weiteres nicht möglich. Lediglich eine Bandbreitengrenze ist sinnvoll realisierbar, wird aber den Rest des Monats dafür sorgen, dass die Verbindung bedeutend langsamer ist. Dies erleichtert es natürlich möglichen Angreifern, einen virtuellen Server gezielt einzuschränken.

Als sinnvolle Schutzmaßnahmen kann man hostseitig mit fail2ban und iptables arbeiten. Dadurch lassen sich Attacken abwehren, bevor diese den Gast erreichen. Eine weitere Firewall innerhalb der Guests, die präziser auf das vorhandene System eingestellt ist, kann ebenfalls von Vorteil sein. In diesem Fall würde man von einer zweistufigen Absicherung sprechen.

Hostfirewall

Die Hostseitige Firewall sollte nicht zu einschränkend sein, aber grundsätzlichen Schutz vor allgemeinen Attacken bieten. Ein möglicher Ansatz ist dabei eine stateful firewall, welche grundsätzlich versucht portscans, spoofing und smurf attacken zu unterbinden.

Das Firewall Script wird zunächst alle vorhandenen Filter löschen/flushen:

### flush old rules
echo "Flushing old rules...";
# Reset Default Policies
$IPT -P INPUT ACCEPT
$IPT -P FORWARD ACCEPT
$IPT -P OUTPUT ACCEPT
$IPT -t nat -P PREROUTING ACCEPT
$IPT -t nat -P POSTROUTING ACCEPT
$IPT -t nat -P OUTPUT ACCEPT
$IPT -t mangle -P PREROUTING ACCEPT
$IPT -t mangle -P OUTPUT ACCEPT
# Flush all rules
$IPT -F
$IPT -t nat -F
$IPT -t mangle -F
# Erase all non-default chains
$IPT -X
$IPT -t nat -X
$IPT -t mangle -X

Dannach werden die einzelnen benötigten "custom" chains angelegt. Dabei handelt es sich um allgemeine Regeln zum Filtern von Paketen sowie ein IN- und ein OUT chain für jeden vServer.

### generate chains
echo "Generating custom chains...";
# general chains
chains="stateful spoofing portscan bad_tcp_packets bad_icmp_packets bad_udp_packets"
for i in $chains; do
$IPT -N $i;
done

# one in- and out chain for each veid
for i in `vzlist --all -o veid -H`; do
$IPT -N "$i"in;
$IPT -N "$i"out;
done

Als nächstes geht es an das Füllen der einzelnen Chains. Beginnend mit dem stateful Chain, welcher aus der Firewall eine stateful Firewall macht. Dieser Chain wird später auf jeden IN- und OUT- Chain eines vServers, sowie auf INPUT und OUTPUT des Hosts angewendet. Um nach wie vor eine Traffickontrolle nutzen zu können wird explizit nicht der FORWARD Chain genutzt, da so die Anzahl der Pakete je virtueller Instanz transparent sichtbar bleiben. Um den stateful Chain zu verstehen, sollte man die verwendeten Protokolle näher betrachten und die möglichen Stadien beachten. Diese sind: ESTABLISHED, RELATED, NEW und INVALID. New heißt neue Verbindung, established bezeichnet eine Verbindung, welche bereits etabliert ist, related ist eine dazugehörige Verbindung, die von vielen Firewalls direkt aktzeptiert wird.

TCP Verbindungen fangen immer mit einem SYN an und sind dann NEW. Als nächstes kommt ein SYN/ACK und sie sind ESTABLISHED. Zuletzt folgt ein ACK. Das bedeutet in Konsequenz:

  1. Alle TCP Pakete ,die bereits ESTABLISHED sind können angenommen werden.
  2. Alle TCP Pakete, die neu aber nicht Syn sind, können direkt abgelehnt werden.

UDP ist ein stateless Protokol. IPtables erlaubt dennoch eine Nutzung von Stadien. Auf grund der Protokollart ist jedoch weder eine SYN Prüfung ist relevant, noch muss RELATED beachtet werden - lediglich ESTABLISHED und NEW.

  1. Alle UDP Pakete, die bereits ESTABLISHED sind können angenommen werden.

Anders als bei TCP und UDP werden hier ESTABLISHED und RELATED zugelassen; Ist ein Ziel nicht erreichbar, wird beispielsweise per ICMP die Antwort "network not reachable" ausgegeben - Diese Antwort gehört zu related. Folglich:

### stateful
echo "filling stateful chain...";
$IPT -A stateful -p TCP -m conntrack --ctstate ESTABLISHED -j ACCEPT
$IPT -A stateful -p UDP -m conntrack --ctstate ESTABLISHED -j ACCEPT
$IPT -A stateful -p ICMP -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
# invalid
$IPT -A stateful -p ALL -m conntrack --ctstate INVALID -j DROP
# new not syn
$IPT -A stateful -p TCP ! --syn -m conntrack --ctstate NEW -j 
 REJECT --reject-with tcp-rst
# not dropped or accepted yet, still new? return to our filter chain
$IPT -A stateful -p ALL -m conntrack --ctstate NEW -j RETURN
# still no match? drop
$IPT -A stateful -p ALL -j DROP

Als nächstes geht es an den Anti-Spoofing Chain, in welchem illegal-source Netzwerke blockiert werden. Spoofing bezeichnet das Senden von Paketen mit falscher Quell IP Adresse, um nicht rückverfolgbar zu sein und auch keine Antworten zu erhalten, die ja ebenfalls verarbeitet werden müssten. Immer wenn ein Paket von einer IP empfangen wird, die nicht im Internet geroutet wird, handelt es sich um gespoofte Pakete. Diese können unmittelbar abgelehnt werden. Eine Übersicht dieser Netze findet sich online. Wichtig ist es natürlich, lokale devices, welche solche Netze nutzen vorher zu erlauben. z.b. das loopback Netz.

### spoofing
echo "filling spoofing chain...";
networks="0.0.0.0/8 10.0.0.0/8 100.64.0.0/10 127.0.0.0/8 169.254.0.0/16 
 172.16.0.0/12 192.0.2.0/24 192.168.0.0/16 198.18.0.0/15 198.51.100.0/24 
 203.0.113.0/24 240.0.0.0/4 255.255.255.255/32"
$IPT -A spoofing -i lo -j RETURN
$IPT -A spoofing -i venet0 -j RETURN
for i in $networks; do
$IPT -A spoofing -s $i -j LOG --log-prefix "Illegal source: "
$IPT -A spoofing -s $i -j DROP
done
# no match? return
$IPT -A spoofing -j RETURN

Im Anschluss lassen sich einige Varianten von Portscans blockieren. Interessanterweise handelt es sich dabei immer um TCP Pakete - auf UDP und ICMP Pakete kann in diesen Chain also verzichtet werden. Die ersten drei Regeln sorgen dafür, dass der Versuch eine Verbindung zu Port 139 aufzubauen zu einer vierundzwangstündigen Bannung der Quell-IP führt, da es sich dabei im Regelfall um Bots handelt.

### portscan
$IPT -A portscan -m recent --name portscan --rcheck --seconds 300 -j DROP
$IPT -A portscan -p tcp -m tcp --dport 139 -m recent --name portscan --set -j 
 LOG --log-prefix "Portscan: "
$IPT -A portscan -p tcp -m tcp --dport 139 -m recent --name portscan --set -j DROP
# nmap null scan
$IPT -A portscan -p tcp --tcp-flags ALL NONE -j LOG --log-prefix "Stealth scan: "
$IPT -A portscan -p tcp --tcp-flags ALL NONE -j DROP
# ALL
$IPT -A portscan -p tcp --tcp-flags ALL ALL -j LOG --log-prefix "Stealth scan: "
$IPT -A portscan -p tcp --tcp-flags ALL ALL -j DROP
# nmap fin stealth scan
$IPT -A portscan -p tcp --tcp-flags ALL FIN -j LOG --log-prefix "Stealth scan: "
$IPT -A portscan -p tcp --tcp-flags ALL FIN -j DROP
# FIN-URG+PSH
$IPT -A portscan -p tcp --tcp-flags ALL FIN,URG,PSH -j LOG 
 --log-prefix "Stealth scan: "
$IPT -A portscan -p tcp --tcp-flags ALL FIN,URG,PSH -j DROP
# xmas
$IPT -A portscan -p tcp --tcp-flags ALL URG,ACK,PSH,RST,SYN,FIN -j LOG 
 --log-prefix "Stealth scan: "
$IPT -A portscan -p tcp --tcp-flags ALL URG,ACK,PSH,RST,SYN,FIN -j DROP
#
$IPT -A portscan -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j LOG 
 --log-prefix "Stealth scan: "
$IPT -A portscan -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP
# SYN+RST
$IPT -A portscan -p tcp --tcp-flags SYN,RST SYN,RST -j LOG 
 --log-prefix "Stealth scan: "
$IPT -A portscan -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
# SYN+FIN
$IPT -A portscan -p tcp --tcp-flags SYN,FIN SYN,FIN -j LOG 
 --log-prefix "Stealth scan: "
$IPT -A portscan -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
# no match? return
$IPT -A portscan -j RETURN

Weiter geht es mit "bösen" TCP-Paketen. Derzeit ist hier primär eine Regel gegen die exzessive Nutzung von RST Paketen zum Schutz vor Smurfattacken ratsam. Unter letzteren versteht man die Ausnutzung von Broadcast zur gezielten Störung vieler Hosts in einem Netzwerk. Im Anschluss folgen "böse" UDP Pakete gefolgt von "bösen" ICMP Paketen.

### bad_tcp_packets
# drop excessive RST packets to avoid smurf attacks
$IPT -A bad_tcp_packets -p tcp -m tcp --tcp-flags RST RST -m limit 
 --limit 2/second --limit-burst 2 -j ACCEPT
# no match? return
$IPT -A bad_tcp_packets -j RETURN

### bad_udp_packets
$IPT -A bad_udp_packets -p UDP -s 0/0 --destination-port 137 -j DROP
$IPT -A bad_udp_packets -p UDP -s 0/0 --destination-port 138 -j DROP
# no match? return
$IPT -A bad_udp_packets -j RETURN

## bad_icmp_packets
# ICMP packets should fit in a Layer 2 frame, thus they should
# never be fragmented.  Fragmented ICMP packets are a typical sign
# of a denial of service attack.
$IPT -A bad_icmp_packets --fragment -p ICMP -j DROP
# limit pings
$IPT -A bad_icmp_packets -p icmp --icmp-type 8 -m limit --limit 2/second -j ACCEPT
$IPT -A bad_icmp_packets -p icmp --icmp-type 8 -j DROP
# limit all remaining icmp packets
$IPT -A bad_icmp_packets -p icmp -m limit --limit 1/second -j ACCEPT
$IPT -A bad_icmp_packets -p icmp -j DROP
# no match? return
$IPT -A bad_icmp_packets -j RETURN

Nun kommen wir zum Input und Output Chain:

### input
$IPT -A INPUT -p ALL -j stateful
$IPT -A INPUT -p ALL -j spoofing
$IPT -A INPUT -p TCP -j portscan
$IPT -A INPUT -p TCP -j bad_tcp_packets
$IPT -A INPUT -p UDP -j bad_udp_packets
$IPT -A INPUT -p ICMP -j bad_icmp_packets
$IPT -A INPUT -j ACCEPT

### output
$IPT -A OUTPUT -p ALL -j stateful
$IPT -A OUTPUT -p UDP -j bad_udp_packets
$IPT -A OUTPUT -p ICMP -j bad_icmp_packets
$IPT -A OUTPUT -j ACCEPT

.. gefolgt von den IN und OUT Chains eines jeden virtuellen Servers:

### one in- and out chain for each veid
for i in `vzlist --all -o veid -H`; do
### in
$IPT -A "$i"in -p ALL -j stateful;
$IPT -A "$i"in -p ALL -j spoofing;
$IPT -A "$i"in -p TCP -j portscan;
$IPT -A "$i"in -p TCP -j bad_tcp_packets;
$IPT -A "$i"in -p UDP -j bad_udp_packets;
$IPT -A "$i"in -p ICMP -j bad_icmp_packets;
# accept remaining packets
$IPT -A "$i"in -p ALL -j ACCEPT
### out
$IPT -A "$i"out -p ALL -j stateful;
$IPT -A "$i"out -p UDP -j bad_udp_packets;
$IPT -A "$i"out -p ICMP -j bad_icmp_packets;
# accept remaining packets
$IPT -A "$i"out -p ALL -j ACCEPT
done

Abschließend müssen die IPs des jeweiligen vServers in den entsprechenden Chain geleitet werden:

### forward
$IPT -A FORWARD -s 84.200.xxx.xx -j 101out
$IPT -A FORWARD -d 84.200.xxx.xx -j 101in
$IPT -A FORWARD -s 84.200.xxx.xx -j 101out
$IPT -A FORWARD -d 84.200.xxx.xx -j 101in
$IPT -A FORWARD -s 84.200.xxx.x -j 102out
$IPT -A FORWARD -d 84.200.xxx.x -j 102in
$IPT -A FORWARD -s 84.201.xx.x -j 102out
$IPT -A FORWARD -d 84.201.xx.x -j 102in
etc
$IPT -A FORWARD -j DROP

Guest firewall

Innerhalb der Guests bietet sich eine simple firewall an, die nur jene Ports erlaubt, welche auch wirklich vorhanden sind und alle anderen entsprechend dropped. Beispielsweise:

$IPT -A INPUT -p TCP --dport 80 -j ACCEPT

und als letzte Regel dann ein:

$IPT -A INPUT -p ALL -j DROP

Beim FORWARD Chain sollte generell die policy DROP eingestellt werden:

$IPT -P FORWARD DROP

Im Output Chain koennte man jetzt noch limitierungen eingeben, z.B: ICMP Pakete auf eines pro Sekunde limitieren.

Statistiken und eigene Scripts

Mit der Zeit sind ein paar Scripte entstanden, welche die weitere Verarbeitung von Container/OpenVZ Daten vereinfachen sollten. Diese Scripte finden sich im /root Verzeichnis.

VEIDs aller laufenden Container

alia:~# ./vz-all-running.sh 
101
102
103
104
200
300

IPs aller laufenden Container

./vz-all-running-ip.sh 
84.200.xxx.xx 84.200.xxx.xx
84.200.xxx.x 84.201.xx.x
84.200.xxx.xx
84.200.xxx.xx 84.201.xx.x
84.201.xx.x
84.201.xx.xx

Statistiken zu den Containern (Über Memory/Resourcen) finden sich in "/proc/user_beancounters". Dazu hilft die folgende Website: User Beancounters. Auf der Webseite finden sich zahlreiche Informationen dazu.

Eine Möglichkeit Statistiken zur Auslastung des Netzwerks zu erheben wäre iptables. Hierzu müsste im FORWARD chain zu jeder IP eines Containers eine Regel mit -d und eine mit -s erstellt werden. Im Anschluss lässt sich der Traffic ermitteln. Eine Beispiel Regel anhand der IP 84.200.xxx.xx:

iptables -A FORWARD -s 84.200.xxx.xx -j ACCEPT
iptables -A FORWARD -d 84.200.xxx.xx -j ACCEPT

Der folgende Befehl listet dann entsprechendes:

iptables --list -vn

OpenVZ bringt auch eigene Tools mit für Statistiken:

 

Migration von virtuellen OpenVZ Containern

Von Migration spricht man, wenn ein virtueller Container von einer HN (Hardware Node) zu einer anderen umgezogen wird. Dies funktioniert sowohl im Betrieb (live) als auch im ausgeschalteten (offline) Zustand. Bei der Livemigration kommt es zu einem kurzen "Hänger" von wenigen Sekunden. OpenVZ arbeitet dabei mit einen initialen Sync - nach Abschluss des Transfers wird der virtuelle Container kurz angehalten, um während des Migrationsvorgangs geänderte Daten zu synchronisieren. Ist dies erfolgreich erfolgt, wird der virtuelle Container auf der neuen HN wieder gestartet.

Der Vorteil in einer solchen Migration liegt darin, dass vorhandene Container im Notfall auf einen Ersatzserver gespielt werden können, eine Form der automatisierten Lastverteilung möglich wäre und ohne viel Aufwand auf einen neuen, leistungsstärkeren Server umgezogen werden kann.

Vorbereitungen

Zunächst werden auf allen Servern SSH Keys benötigt, so dass SSH Verbindungen zwischen den Servern ohne Passwort möglich sind. Dafür wird auf dem jetzigen Server ein SSH Key angelegt und dieser auf den neuen Server kopiert.

# ssh-keygen -t rsa
    # cd .ssh/
    # scp id_rsa.pub root@neuer-server:./id_rsa.pub

Auf dem neuen Server wird der Key dann in die authorized list eingetragen:

# cd .ssh/
    # touch authorized_keys2
    # chmod 600 authorized_keys2
    # cat ../id_rsa.pub >> authorized_keys2
    # rm ../id_rsa.pub
    # rm: remove regular file `../id_rsa.pub'? y

Nun auf dem alten Server testen ob eine SSH-Verbindung mittels Key zum neuen Server möglich ist:

# ssh -2 root@10.1.5.6

Hat alles geklappt, kann dies auch vom neuen Server zum alten durchgeführt werden (Falls es sich um einen dauerhaften Umzug handelt, ist dies nicht nötig).

Migration

Das Tool "vzmigrate" bietet die folgenden Optionen:

  -r, --remove-area yes|no
    Whether to remove container on source HN for successfully migrated container.
    --ssh=<ssh options>
    Additional options that will be passed to ssh while establishing
    connection to destination HN. Please be careful with options
    passed, DO NOT pass destination hostname.
    --keep-dst
    Do not clean synced destination container private area in case of some
    error. It makes sense to use this option on big container migration to
    avoid syncing container private area again in case some error
    (on container stop for example) occurs during first migration attempt.
    --online
    Perform online (zero-downtime) migration: during the migration the
    container hangs for a while and after the migration it continues working
    as though nothing has happened.
    -v
    Verbose mode. Causes vzmigrate to print debugging messages about
    its progress (including some time statistics).

Die Syntax ist:

vzmigrate [-r yes|no] [--ssh=<options>] [--keep-dst] [--online] [-v]
destination_address <CTID>

Zum Testen sollte zunächst remove-area no genutzt werden. Dies stellt sicher das der Container nicht vom Source-Rechner entfernt wird und das das private area nicht gesäubert wird. Falls etwas schief geht, ist es so nach wie vor möglich, den alten Container weiter zu benutzen.

Mithilfe von -- online lässt sich dann eine Live-Migration durchführen. Beispiel:

vzmigrate --online neuer-server 101

Dieser Befehl wird den virtuellen Container 101 auf den neuen Server live-migrieren.

Um alle virtuellen Container zu migrieren, liesse sich der folgende Befehl nutzen:

for CT in $(vzlist -H -o veid); 
do vzmigrate --remove-area no --keep-dst --online $1 $CT; 
done
 

Manuelles Erstellen eines OpenVZ-Debian-Kernels mit RHEL6 Patchset für VSwap

Für erfahrene Anwender kann auch ein eigener Kernel für VSwap eingerichtet werden. Damit können die virtuellen Container Swap nutzen. Zunächst sollte sichergestellt werden, dass alles funktioniert bevor das System neugestartet wird. Nicht alle RPMs lassen sich konvertieren; das stellt nicht unbedingt ein Problem dar. Wichtig sind der Kernel, vzctl und vzquota - Diese müssen zwingend erfolgreich installiert sein.

  • Zunächst müssen aktuelle Utils und der aktuelle Kernel aus der RHEL6-Testing Branch in RPM Form heruntergeladen werden
  • Dann werden diese mittels alien von RPM zu DEB konvertiert werden.
  • Nun lassen sich die DEBs mittels dpkg -i *.deb installieren.

Downloads:

Konvertierung (Beispiel vzkernel und vzkernel-devel)

  • fakeroot alien --to-deb --scripts --keep-version vzkernel-2.6.32-042stab039.3.x86_64.rpm vzkernel-devel-2.6.32-042stab039.3.x86_64.rpm

Sonstiges

  1. Normalerweise werden alle Prozesse im Host angezeigt. Dies lässt sich mit sysctl -w 'kernel.pid_ns_hide_child=1' bzw. einem kernel.pid_ns_hide_child=1 in /etc/sysctl.conf vermeiden.
 

Hotline
 
Hotline des Rechenzentrums

Fragen? Rufen Sie uns an!
Montag - Freitag 10:00 - 19:00 Uhr

+49 69 - 900 180 - 0

 
Aktionen & News
 

Dedizierte Supermicro Xeon Server - ab 70,00 Euro

Angebote

 

Zweiter Standort
 
Hotline des Rechenzentrums

Erfahren Sie mehr über unseren zweiten Standort in der Hanauer Landstrasse in Frankfurt am Main.

mehr erfahren

Zertifizierungen
 
TüV geprüftes Rechenzentrum
ISO 27001 zertifiziertes Rechenzentrum
ISO 9001 zertifiziertes Rechenzentrum


Knowledge Base
 

Hilfreiche Artikel zum Thema Netzwerk, Server & IT.

mehr erfahren


Galerie
 

Sehen Sie sich in einem virtuellen Rundgang in unserem Rechenzentrum um:

Niederspannungshauptverteilung Unterbrechungsfreie Strom Versorgung
Kaltwassererzeuger Bereitstellung individueller SAT-Dienstleistungen


100% Ökostrom
 
100% Öko-Strom