====== openQRM - Maschine duplizieren ====== Hier wird beschrieben, wie man eine //physikalische// Maschine "kopiert". Bei einer //virtuelle// Maschine kann man einiges, was hier beschrieben wird, überspringen. ===== Vorraussetzungen ===== Es wird hier vorausgesetzt, dass die //physikalische// Maschine bereits installiert ist. ===== Maschine duplizieren ===== 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". ==== 1. Schritt ==== 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. ==== 2. Schrtitt ==== 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. ==== 3. Schritt ==== 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! ==== 4. Schritt ==== 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! ==== 5. Schritt ==== 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: - Root password: "ysexdr" (muss nicht unbedingt angegeben werden) - Root-device: "/dev/sda1" (muss IMMER angegeben werden!) - Root-fs type: "jfs" (der richtige Dateisystem-Typ sollte schon da stehen) - Transfer-to-NFS "default_physik_nfs" (der richtige Name des Storage, den haben wir evtl. geändert!) - Comment: "Root-device: /dev/sda1" (damit es in Bezug auf das Root-device, nicht einmal zu einem Fehler kommt!) 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: - Root password: "ysexdr" (muss nicht unbedingt angegeben werden) - Root-device: "/dev/sda1" (muss IMMER angegeben werden!) - Root-fs type: "jfs" (der richtige Dateisystem-Typ sollte schon da stehen) - Install-from-NFS "" (das muss jetzt leer sein!) - Transfer-to-NFS "" (das muss jetzt leer sein!) - Comment: "Root-device: /dev/sda1" (damit es in Bezug auf das Root-device, nicht einmal zu einem Fehler kommt!) ==== 6. Schritt ==== 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 ==== 7. Schritt ==== 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: - /dev/sda1: 20 GB / ID=83 (Linux) - /dev/sda2: [Rest] / ID=83 (Linux) ==== 8. Schritt ==== 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. === installation eines Hilfs-Betriebssystems auf eine ext4-Partition === Hilfs-Installation auf der ext4-Partition: - Name: rblb02 (bitte einen sprechenden Namen verwenden) - Root password: "ysexdr" (muss nicht unbedingt angegeben werden) - Root-device: "/dev/sda2" (Hilfspartition, sie wird später anderweitig verwendet) - Root-fs type: "ext4" (ein FS-Typ, der von openQRM unterstützt wird) - Install-from-NFS "default_physik_nfs" (hier kann eine beliebige Installation angegeben werden, sie muss nur lauffähig sein) - Comment: "Root-device: /dev/sda1" (damit es in Bezug auf das Root-device, nicht einmal zu einem Fehler kommt!) Damit wir das Teil auch neu starten können, brauchen wir jetzt nur noch eine "Appliance": - Name: "rblb02" (bitte einen sprechenden Namen verwenden) - Kernel: "default" - Image: "rblb02" (den Image-Namen haben wir ja gerade eben erst vergeben) - Resource: "Physical System" 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. === finale Installation === 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: - Name: rblb02 (bitte einen sprechenden Namen verwenden) - Root password: "ysexdr" (muss nicht unbedingt angegeben werden) - Root-device: "/dev/sda1" (muss IMMER angegeben werden!) - Root-fs type: "jfs" (der richtige Dateisystem-Typ sollte schon da stehen) - Install-from-NFS "default_physik_nfs" (hier muss das Storage angegeben werden, welches wir im 4. bzw. 5. Schritt befüllt haben!) - Comment: "Root-device: /dev/sda1" (damit es in Bezug auf das Root-device, nicht einmal zu einem Fehler kommt!) 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: - Root password: "ysexdr" (muss nicht unbedingt angegeben werden) - Root-device: "/dev/sda1" (muss IMMER angegeben werden!) - Root-fs type: "jfs" (der richtige Dateisystem-Typ sollte schon da stehen) - Install-from-NFS "" (das muss jetzt leer sein!) - Transfer-to-NFS "" (das muss jetzt leer sein!) - Comment: "Root-device: /dev/sda1" (damit es in Bezug auf das Root-device, nicht einmal zu einem Fehler kommt!) ==== 9. Schritt ==== 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: - /dev/sda1: 20 GB / ID=83 (Linux) - /dev/sda2: [Rest] / ID=8e (Linux LVM) 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. ==== individuelle Nacharbeiten ==== === gewünschte IP im DHCP-Server hinterlegen === # 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. === gewünschte IP im DNS-Server hinterlegen === # 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 .... === Bonding einrichten === 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 === Bootmode === Als allerletztes ist es noch ratsam, dem Bootmode wieder auf "local" umzustellen. Wie das geht, wird im "2. Schritt" beschrieben.