Hier wird beschrieben, wie man eine physikalische Maschine "kopiert". Bei einer virtuelle Maschine kann man einiges, was hier beschrieben wird, überspringen.
Es wird hier vorausgesetzt, dass die physikalische Maschine bereits installiert ist.
In diesem Beispiel hat die openQRM-Management-Maschine die IP "10.10.5.80";
und die zu duplizierende physikalische Maschine die IP "10.10.5.243".
Die zu duplizierende physikalische Maschine hat in diesem Beispiel die MAC-Adr. "01:84:2b:2b:4c:5c:6d".
Zur Sicherheit (siehe "6. Schritt") legen wie eine Sicherheitskopie der Datei "/etc/fstab" an:
# cp /etc/fstab /etc/fstab.sik
Die physikalische Maschine muss dem openQRM-Management als Client hinzugefühgt werden:
# scp /usr/share/openqrm/plugins/local-server/bin/openqrm-local-server root@10.10.5.243:/tmp/ # ssh root@10.10.5.243 '/tmp/openqrm-local-server integrate -u openqrm -p openqrm -q 10.10.5.80 -i eth0'
Jetzt ist die physikalische Maschine als "Resource" verfügbar.
Jetzt stellen wir die physikalische Maschine im BIOS auf "PXE-Boot" um, damit wir diese Maschine komplett von openQRM aus kontrollieren können.
Ob die physikalische Maschine von einem Image oder von der lokalen Platte booten soll, wird hier eingestellt:
# vi /usr/share/openqrm/tftpboot/pxelinux.cfg/01-84-2b-2b-4c-5c-6d
default local label linux kernel boot/vmlinuz-default append ramdisk_size=131072 apm=off initrd=boot/initrd-default.img id=8 openqrm=10.10.5.80 selinux=0 ipappend 3 label local LOCALBOOT 0
Das "label" definiert den Namen der Sektion. In der ersten Zeile wird mit dem Schlüsselwort "default" das gewünschte Label und somit die gewünschte Sektion festgelegt.
Jetzt brauchen wir ein "Storage" für den Platteninhalt der physikalischen Maschine.
In Schritt "1" wurde es zwar schon unter "Base / Components / Storage" angelegt, wir überprüfen allerdings hier (Knopf "Mgmt") die Größe und können auch den Namen in einen sprechenden Namen ändern.
Wenn wir den Namen geändert haben, dann sollte er auf jeden Fall auch im "Image" unter "Base / Components / Images" entsprechend angepasst werden!
Wichtig ist auch, dass das Image immer die Bezeichnung für das "Root-device" verliert!
Aus dem Grund sollte die Bezeichnung für das lokale "Root-device" immer auch unter "Comment" angegeben werden!!!
Nur so kann jeder, der hier eine Anpassung vornehmen muss auch das richtige "Root-device" wieder angeben!
Jetzt müssen wir den PXE-Kernel noch um die fehlenden Module ergänzen, die nötig sind, damit die lokale Festplatte gelesen werden kann.
Unter openQRM - PXE-Kernel wird beschrieben, wie der Kernel um die Module "mptsas" (für den LSI/DELL-RAID-Kontroller) und "jfs" (für das lokale Dateisystem) erweitert wird.
Erst danach kann man einen PXE-Bootvorgang erfolgreich durchführen!
Jetzt sollte der PXE-Bootvorgang problemlos funktionieren. Wenn nicht, dann sind die Probleme erst zu lösen!
Denken Sie daran, das ein unsauberes JFS-Dateisystem nur Read-Only oder garnicht gemountet werden kann!!!
Damit der Platteninhalt von der lokalen Platte in das entsprechende Storage geschrieben wird, müssen wir im "Image" (unter "Base / Components / Images") unserer physikalischen Maschine folgende Eintragungen vornehmen:
Jetzt können wir über die "Base / Appliances / List" unsere physikalische Maschine einmal "stoppen" und gleich wieder "starten", damit der Kopiervorgang durchgeführt wird.
Nachdem die physikalische Maschine vollständig gebootet ist, sollten die entsprechenden Daten im Storage liegen. Sicherheitshalber sollten wir im Image überprüfen ob die Variablen unter "Deployment parameter" auch leer sind.
Sind sie es nicht, dann würde der Kopiervorgang nach einem neustart wiederholt werden, was ja blödsinn wäre. In soeinem Fall machen wir sie selber leer:
In den Daten, die in unserem neuen Storage liegen, müssen wir noch ein paar Änderungen vornehmen:
# echo "" > /data/default_physik_nfs/etc/udev/rules.d/70-persistent-net.rules
# vi /data/default_physik_nfs/etc/network/interfaces
# The loopback network interface auto lo iface lo inet loopback # The primary network interface auto eth0 iface eth0 inet dhcp
Bei Bedarf kann man hier einen Defaultschlüssel eintragen:
# mkdir -p /data/default_physik_nfs/root/.ssh/ # chmod 0700 /data/default_physik_nfs/root/.ssh/ # vi /data/default_physik_nfs/root/.ssh/authorized_keys
Leider kann es sein, das der openQRM-Client auf der physikalische Maschine die "/etc/fstab" überschrieben wurde.
In soeinem Fall würde sie dann so aussehen, wie die Datei, die im NFS-Verzeichnis liegt:
# vi /data/default_physik_nfs/etc/fstab
/dev/sda1 / jfs defaults 0 0 none /dev/pts devpts gid=5,mode=620 0 0 none /proc proc defaults 0 0 none /dev/shm tmpfs defaults 0 0 none /dev tmpfs rw 0 0 /dev/fd0 /mnt/floppy auto noauto,owner,kudzu 0 0 /tmp/mini-swap.swap swap swap noauto 0 0
Mit Hilfe von "lvs" und "blkid" kann man die originale aber wieder herstellen. Besser wäre es, wenn man vorher eine Sicherheitskopie angelegt hätte (siehe "1. Schritt").
# lvs LV VG Attr LSize Origin Snap% Move Log Copy% Convert swap system -wi-ao 7,45g tmp system -wi-ao 7,45g
# blkid /dev/sda1: UUID="4c78723e-11fc-4947-8e2a-58f0e3bdb8df" TYPE="jfs" /dev/sda2: UUID="Uj2Tyr-JL33-NEYo-TIAT-z1NP-OiqA-cmtw1D" TYPE="LVM2_member" /dev/mapper/system-tmp: LABEL="tmp" UUID="c8b5d7df-fd8a-448f-b4c5-3d24293909cf" TYPE="jfs" /dev/mapper/system-swap: UUID="16eee6e7-0897-442f-8427-588f4734da32" TYPE="swap"
# blkid | fgrep 'TYPE="swap"' | sed -e 's/\/t/ /g' -e 's/ /\n/g' | fgrep UUID UUID="16eee6e7-0897-442f-8427-588f4734da32"
In diesem Fall würde die "/etc/fstab" so aussehen:
/dev/sda1 / jfs defaults 0 0 none /dev/pts devpts gid=5,mode=620 0 0 none /proc proc defaults 0 0 none /dev/shm tmpfs defaults 0 0 none /dev tmpfs rw 0 0 /dev/fd0 /mnt/floppy auto noauto,owner,kudzu 0 0 LABEL=tmp /tmp jfs errors=remount-ro 0 0 UUID=16eee6e7-0897-442f-8427-588f4734da32 none swap sw 0 0
Die Mount-Option "noexec" darf für "tmp" nicht verwendet werden, da es sonst in Ubuntu bei Updates Probleme gibt!
Nachdem die "/etc/fstab" jetzt wieder passt, sollten wir das "/tmp/" sauber machen, damit nachher keine Daten unter dem Mount-Point verbleiben:
# swapoff # rm -fr /tmp # mkdir /tmp # mount /tmp
Jetzt widmen wir uns der neuen, 2. physikalischen Maschine.
Als erstes stellen wir hier im BIOS die Bootreihenfolge so um, das die Maschine als erstes per PXE bootet.
Nachdem diese Maschine dann per PXE gebootet ist, steht sie auch schon in der openQRM-Oberfläche unter "Base / Components / Resources" zur Verfügung.
Hier muss auf der neuen Maschine nur die lokale Platte, von Hand, so partitioniert werden, wie wir sie brauchen.
Zum Beispiel so:
Leider gibt es an dieser Stelle ein kleines Problem. OpenQRM kann nur mit den "ext*"-Dateisystemen umgehen.
OpenQRM versucht das angegebene Dateisystem zu mounten, wenn das nicht geht, wird versucht die Partition mit dem angegebene Dateisystem zu formatieren, leider enthält dieses einfache PXE-Image aber nur die ext-Tools und kann keine JFS-Partition formatieren. Aus dem Grund wird sie mit ext3 formatiert und anschließend versucht openQRM sie dann als JFS-Partition (bzw. mit dem angegebenen Dateisystem) zu mounten… das geht natürlich nur dann, wenn man ein "ext*"-Dateisystem angegeben hat!
Da wir kein "ext*"-Dateisystem verwenden wollen, sondern "JFS", müssen wir diese Installation in zwei Schritte aufteilen.
Damit wir mit dieser Maschine etwas anfangen können, müssen wir ein "Storage" (Deployment: Local-installed-server) und ein "Image" erstellen.
Hilfs-Installation auf der ext4-Partition:
Damit wir das Teil auch neu starten können, brauchen wir jetzt nur noch eine "Appliance":
Der einzige Zweck dieser Installation ist es, das wir "/dev/sda1" mit JFS formatieren können, um dann darauf die finale Installation vorzunehmen.
Mehr brauchen wir zu diesem Zeitpunkt nicht unbedingt angeben, das kann man auch später noch "tunen".
Jetzt stoppen und starten wir die Appliance einmal, dann sollten die Daten auf die Platte (/dev/sda2) geschrieben werden.
Nachdem diese (erste) Installation abgeschlossen ist, müssen wir uns auf der Maschine anmelden und "/dev/sda1" mit JFS formatieren.
Dann stellen wir das Image wieder wie folgt um:
Nachdem die (neue bzw. 2.) physikalische Maschine vollständig (von /dev/sda1) gebootet ist, sollten die Variablen unter "Deployment parameter" auch leer sind.
Sind sie es nicht, dann würde der Kopiervorgang nach einem neustart wiederholt werden, was ja blödsinn wäre. In soeinem Fall machen wir sie selber leer:
Jetzt müssen wir auf der neuen Maschine Partitionierung vollenden.
Dazu werden wir als erstes (mit fdisk) die ID der Hilfs-Partition (/dev/sda2) auf der lokalen Platte ändern und das Bootflag auf "/dev/sda1" (Taste "a").
Zum Beispiel so:
Dann schreiben wir den Bootloader noch in den MBR der Platte:
# grub-install -v /dev/sda # grub-setup -v /dev/sda # update-grub
Oder man kann das auch automatisch machen lassen (empfohlen):
# aptitude reinstall grub-common grub-pc os-prober
Allerdings funktioniert das in der Praxis aus irgendwelchen Gründen nicht!
Und dann wie folgt fortfahren:
# pvcreate /dev/sda2 # vgcreate system /dev/sda2 # lvcreate -L 8G -n tmp system # lvcreate -L 8G -n swap system # mkfs -t jfs -L tmp /dev/system/tmp # mkswap -L swap /dev/system/swap
Zum Schluss passen wir noch die Datei "/etc/fstab" an:
Im Moment sieht sie noch so aus:
/dev/sda1 / jfs defaults 0 0 none /dev/pts devpts gid=5,mode=620 0 0 none /proc proc defaults 0 0 none /dev/shm tmpfs defaults 0 0 none /dev tmpfs rw 0 0 /dev/fd0 /mnt/floppy auto noauto,owner,kudzu 0 0 /tmp/mini-swap.swap swap swap noauto 0 0
Nun ermitteln wir die speziellen Daten der Partitionen:
# blkid /dev/sda1: UUID="f9d2faf7-025e-4d35-bc9c-a133c1050d68" TYPE="jfs" /dev/sda2: UUID="3emYHr-lGyS-aUIk-blQJ-bN5o-zP4m-dAzjfM" TYPE="LVM2_member" /dev/mapper/system-tmp: LABEL="tmp" UUID="f7709934-6096-4457-b8ea-6771775be2eb" TYPE="jfs" /dev/mapper/system-swap: UUID="6be8d342-a6e8-48dd-bf96-ac8c5fc825dd" TYPE="swap" LABEL="swap"
Danach sollte unsere "/etc/fstab" so aussehen:
/dev/sda1 / jfs errors=remount-ro 0 0 none /dev/pts devpts gid=5,mode=620 0 0 none /proc proc defaults 0 0 none /dev/shm tmpfs defaults 0 0 none /dev tmpfs rw 0 0 /dev/fd0 /mnt/floppy auto noauto,owner,kudzu 0 0 LABEL="tmp" /tmp jfs errors=remount-ro 0 0 LABEL="swap" none swap noauto 0 0
Die Mount-Option "noexec" darf für "tmp" nicht verwendet werden, da es sonst in Ubuntu bei Updates Probleme gibt!
Und zum Schluss aktivieren wir unsere Änderungen noch:
# rm -fr /tmp/ # mkdir /tmp/ # mount /tmp/ # swapon -a
Man sollte jetzt sicherheitshalber noch einen Reboot durchführen um zu sehen, das auch alles mit Sicherheit so funktioniert wie es gewünscht ist… und damit das Root-Dateisystem ("/") auch mit den richtigen Mount-Optionen gemountet wird, denn da haben wird ja auch etwas korrigieren müssen.
# ps wwwaux|fgrep -v grep|fgrep -i dhcpd.conf dhcpd 24225 0.0 0.0 20048 3652 ? Ss 10:49 0:00 /usr/sbin/dhcpd3 br0 -cf /usr/share/openqrm/plugins/dhcpd/etc/dhcpd.conf -lf /usr/share/openqrm/plugins/dhcpd/var/state/dhcp/dhcpd.leases
# vi /usr/share/openqrm/plugins/dhcpd/etc/dhcpd.conf
noch sieht es z.B. so aus:
host resource11 {
hardware ethernet 84:2B:2B:4C:5A:DF;
fixed-address 10.10.5.21;
filename "/pxelinux.0";
}
wir ändern das (HOST und Address) zu so:
host server01 {
hardware ethernet 84:2B:2B:4C:5A:DF;
fixed-address server01.domain.de;
filename "/pxelinux.0";
}
Jetzt stoppen und starten wir das DHCPD-Plugin im "Plugin Manager" einmal.
# ps wwwaux|fgrep -v grep|fgrep -i bind bind 9970 0.0 0.5 208888 21856 ? Ssl Sep20 0:00 /usr/sbin/named -u bind
# vi /usr/share/openqrm/plugins/dns/etc/bind/zones/oqrm.net.in.db
....
774 ; Serial
....
rblb02 IN A 10.10.5.244
....
# vi /usr/share/openqrm/plugins/dns/etc/bind/zones/oqrm.net.rev.db
....
774 ; Serial
....
244 IN PTR rblb02.oqrm.net
....
Jetzt müssen wir uns wieder auf der (neuen) physikalischen Maschine einloggen und die Netzwerkkonfiguration vornehmen.
Eigentlich sollten diese Pakete schon drauf sein, aber sicher ist sicher…
# aptitude update && aptitude install ifenslave bridge-utils mii-tool ethtool bmon
Jetzt die Netzwerkkonfigurationsdatei:
# vi /etc/network/interfaces
# The primary network interface #auto eth0 #iface eth0 inet dhcp auto bond0 iface bond0 inet static address 10.10.5.244 netmask 255.255.255.0 network 10.10.5.0 broadcast 10.10.5.255 dns-nameservers 10.10.5.80 slaves eth0 eth1 bond_mode 0 bond_miimon 100 bond_updelay 200 bond_downdelay 200
Als allerletztes ist es noch ratsam, dem Bootmode wieder auf "local" umzustellen.
Wie das geht, wird im "2. Schritt" beschrieben.