Piratenwiki Mirror

Archiv:2011/IT/Dokumentation/OVH-Grundinstallation

< Archiv:2011/IT/Dokumentation
Version vom 1. Februar 2019, 11:48 Uhr von imported>JanRei (JanRei verschob die Seite IT/Dokumentation/OVH-Grundinstallation nach Archiv:2011/IT/Dokumentation/OVH-Grundinstallation)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)

Grundinstallation

OVH-spezifische Vorbereitungen

Zuerst muss der Server über das OVH-Webinterface in den Rescue-Modus gesetzt werden. Dazu meldet man sich beim OVH-Manager an, wählt oben in der Leiste den Server aus, klickt links im Menü auf "Dienstleistungen", und im Hauptteil auf "Netboot". Im folgenden Konfigurationsmenü wählt man den Netboot "rescue-pro", gibt seine E-Mail-Adresse an, unter der man die Zugangsdaten für den Rescue-Modus erhalten will und bestätigt. Anschließend klickt man im Menü links wieder auf "Dienstleistungen" und dann auf "Reboot". Als Grund gibt man "Serverneuinstallation" ein und bestätigt. Sobald der server im Rescue-Modus ist, schickt er an die angegebene E-Mail-Adresse die Zugangsdaten. Das kann bis zu 10 Minuten dauern.

Partitionierung der Platten

Jetzt können wir die Festplatten "ganz normal" partitionieren: Zuerst löschen wir den Anfang der Festplatten, schreiben dann neue Master Boot Records und lesen die Partitionstabelle neu ein. Das ist leider oft genug mit einem Reboot verbunden. 

rescue:~# dd if=/dev/zero of=/dev/sda count=512 bs=1M
rescue:~# dd if=/dev/zero of=/dev/sdb count=512 bs=1M
rescue:~# sfdisk --force /dev/sda <<EOF
# partition table of /dev/sda
unit: sectors

/dev/sda1 : start=       63, size=   514017, Id=fd, bootable
/dev/sda2 : start=   514080, size=1464629985, Id=fd
/dev/sda3 : start=        0, size=        0, Id= 0
/dev/sda4 : start=        0, size=        0, Id= 0
EOF
rescue:~# sfdisk --force /dev/sdb <<EOF
# partition table of /dev/sdb
unit: sectors

/dev/sdb1 : start=       63, size=   514017, Id=fd, bootable
/dev/sdb2 : start=   514080, size=1464629985, Id=fd
/dev/sdb3 : start=        0, size=        0, Id= 0
/dev/sdb4 : start=        0, size=        0, Id= 0
EOF

Hier wird aller Wahrscheinlichkeit nach ein Reboot fällig: 

rescue:~# reboot

Dann kurz warten, und wir haben wieder Post vom Server: Neues root-Passwort.

Nun erstellen wir das Software-Raid, die LVM-Partitionen und die Dateisysteme. Auf dem Raid für /boot muss wegen grub die Metadata-Version 0.90 sein, sonst kann der nicht auf /boot installiert werden. 

rescue:~# mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda1 /dev/sdb1
rescue:~# mdadm --create /dev/md1 --metadata=1.2 --bitmap=internal --level=1 --raid-devices=2 /dev/sda2 /dev/sdb2

Dannach initialisieren wir die Partition für LVM, indem wir ein LVM-Physical-Volume erstellen, dannach eine Volume-Group (raid) und die ersten Logical Volumes und erstellen die Dateisysteme. 

rescue:~# pvcreate /dev/md1
rescue:~# vgcreate raid /dev/md1
rescue:~# lvcreate --size 2G --name blackpearl_root raid
rescue:~# lvcreate --size 1G --name blackpearl_swap raid
rescue:~# mke2fs -j -L blackpearl_root /dev/raid/blackpearl_root
rescue:~# mke2fs -j -L blackpearl_boot /dev/md0
rescue:~# mkswap -L blackpearl_swap /dev/raid/blackpearl_swap

Eigenes debootstrap notwendig?

Früher mussten Anpassungen speziell für das OVH-Rescue-System gemacht werden. Da OVH ein Sarge-Rescue-System verwendete, enthielt das natürlich keinen Lenny-fähigen debootstrap und wir mussten einen neuen herunterladen und installieren. Dummerweise ist das root-Filesystem ein read-only NFS-Share und wir mussten das Paket per Hand nach /tmp installieren, patchen und in den Pfad bringen: 

rescue:~# cd /tmp
rescue:/tmp# wget -q http://ftp.fr.debian.org/debian/pool/main/d/debootstrap/debootstrap_1.0.20_all.deb
rescue:/tmp# ar -x debootstrap_1.0.20_all.deb
rescue:/tmp# tar xzf data.tar.gz
rescue:/tmp# sed -i -e 's#DIR=/usr#DIR=/tmp/usr#' usr/sbin/debootstrap
rescue:/tmp# export PATH=/tmp/usr/sbin:$PATH

Installieren des Zielsystems

Wir hängen nun die vorbereiteten Partitionen in /mnt ein und starten das gepatchte debootstrap: 

rescue:~# mount /dev/raid/blackpearl_root /mnt/
rescue:~# mkdir /mnt/boot
rescue:~# mount /dev/md0 /mnt/boot/
rescue:~# debootstrap --arch=amd64 lenny /mnt/ http://ftp.fr.debian.org/debian

Anschliessend hängen wir noch die Dateisysteme /proc und /dev um, damit wir innerhalb des Zielsystems auch auf Geräte und Prozesse zugreifen können. Anschliessend gehen wir in das Zielsystem: 

rescue:~# mount -t proc proc /mnt/proc/
rescue:~# mount -o bind /dev/ /mnt/dev/
rescue:~# chroot /mnt/ /bin/bash

Konfiguration des Zielsystems

Ab jetzt sind wir im Zielsystem. Wir werden nun diverse Teile des Systems konfigurieren. Fangen wir mit der Zeitzone an, diese wurde bereits via debootstrap gesetzt, also müssen wir sie umsetzen und das System sich neu konfigurieren lassen: 

rescue:/# echo "Europe/Berlin" > /etc/timezone
rescue:/# dpkg-reconfigure -f noninteractive tzdata

Setzen wir gleich auch ein Passwort für root 

rescue:/# passwd

Wir müssen auch noch die Partitionen eintragen. Dafür editieren wir die /etc/fstab: 

rescue:/# cat > /etc/fstab <<EOF
proc /proc proc defaults 0 0
/dev/raid/blackpearl_root / ext3 errors=remount-ro 0 1
/dev/raid/blackpearl_swap none swap sw 0 0
/dev/md0 /boot ext3 defaults 0 2
EOF

Dann kümmern wir uns um das Datennetz. Wir setzen den Hostnamen und erstellen eine /etc/hosts und /etc/network/interfaces. Hier bitte auf die IP-Adressen, Gateways, Hostnamen etc aufpassen und die eigenen wählen! 

rescue:/# echo blackpearl > /etc/hostname
rescue:/# cat > /etc/hosts <<EOF
127.0.0.1       localhost
94.23.220.83    blackpearl.piratenpartei.de   blackpearl

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
EOF
rescue:/# cat >> /etc/network/interfaces <<EOF

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
iface eth0 inet static
        address 94.23.220.83
        netmask 255.255.255.0
        network 94.23.220.0
        broadcast 94.23.220.255
        gateway 94.23.220.254
        # dns-* options are implemented by the resolvconf package, if installed
        dns-nameservers 213.186.33.99
        dns-search piratenpartei.de
EOF

Anschließend konfigurieren wir apt. Da die OVH-Kisten in Frankreich stehen, ziehen sie vom französischen Debian-Mirror: 

rescue:/# cat > /etc/apt/sources.list <<EOF
deb http://ftp.fr.debian.org/debian lenny main contrib non-free
deb http://security.debian.org lenny/updates main contrib non-free
EOF

Installation von System-Paketen

Als erstes müssen wir aptitude die Paketlisten updaten lassen, anschließend upgraden wir die benötigten Pakete: 

rescue:/# aptitude update
rescue:/# aptitude safe-upgrade

Die locales sind noch nicht installiert, und um uns lästige Fragen zu ersparen, legen wir die Konfigurationsdateien bereits im Vorfeld an und installieren dannach: 

rescue:/# cat > /etc/locale.gen <<EOF
en_US.UTF-8 UTF-8
de_DE.UTF-8 UTF-8
en_GB.UTF-8 UTF-8
ja_JP.UTF-8 UTF-8
ru_RU.UTF-8 UTF-8
EOF
rescue:/# cat > /etc/default/locale <<EOF
LANG=de_DE.UTF-8
LC_MESSAGES=en_US.UTF-8
EOF
rescue:/# aptitude install locales

Wir müssen noch die LVM-Tools installieren, dass das System nach dem Neustart auf die LVM-Partition zugreifen kann: 

rescue:/# aptitude install -y lvm2

Ausserdem muss noch mdadm installiert werden, um auf die Raid-Partitionen zugreifen zu können. Dummerweise will der einen Mailer installieren, und zwar exim. Das ist uns aber zu viel, wir bevorzugen den kleinen nullmailer: 

rescue:/# echo blackpearl.piratenpartei.de > /etc/mailname
rescue:/# debconf-set-selections <<EOF
nullmailer      shared/mailname         string  blackpearl.piratenpartei.de
nullmailer      nullmailer/relayhost    string  mail.piratenpartei.de
nullmailer      nullmailer/adminaddr    string
EOF
rescue:/# aptitude install nullmailer
rescue:/# aptitude install mdadm

Weiter gehts mit dem Boot-Loader, ich bin ein grub-Fan, darum kommt der drauf: 

rescue:/# aptitude install -y grub

Achtung! Wenn /dev/md0 nicht komplett ist, scheitert folgender Befehl: 

rescue:/# grub-install /dev/md0
rescue:/# grub <<EOF
root (hd0,0)
setup (hd0)
setup (hd1)
quit
EOF

Dann installierten wir den Kernel, davor konfigurieren wir aber noch die Kernel-Image-Erstellung: 

rescue:/# cat > /etc/kernel-img.conf <<EOF
# Kernel image management overrides
# See kernel-img.conf(5) for details
do_symlinks = yes
relative_links = yes
do_bootloader = no
do_bootfloppy = no
do_initrd = yes
link_in_boot = no
postinst_hook = update-grub
postrm_hook   = update-grub
EOF
rescue:/# aptitude install -y linux-image-2.6-amd64

Installation der Administrations-Pakete

So, jetzt haben wir das neue System bootfertig, aber kommen noch nicht drauf. Dafür brauchen wir noch openssh-server, den wir anschliessend absichern: 

rescue:/# aptitude -y install openssh-server
rescue:/# sed -i -e 's/^PermitRootLogin yes$/#&\nPermitRootLogin no/' -e 's/^UsePAM yes$/#&\nUsePAM no/' -e 's/^#PasswordAuthentication yes$/&\nPasswordAuthentication no/' /etc/ssh/sshd_config

Damit die Rechte für den Root-Account sauber getrennt werden, verwenden wir sudo, das wir auch gleich konfigurieren: 

rescue:/# aptitude install sudo
rescue:/# sed -i -e 's/^root\tALL=(ALL) ALL$/&\ndyfa\tALL=(ALL) ALL\nsebi\tALL=(ALL) ALL\nchrit\tALL=(ALL) ALL\nunger\tALL=(ALL) ALL\njamasi\tALL=(ALL) ALL\nnhornung\tALL=(ALL) ALL/' /etc/sudoers

Um die Festplatten überwachen zu können, installieren wir noch smartmontools, die wir auch noch aktivieren müssen: 

rescue:/# aptitude install -y smartmontools
rescue:/# sed -i -e 's/^#\(start_smartd=yes\)$/\1/' /etc/default/smartmontools

Damit die Uhrzeit auf dem Server synchron zut Atomzeit läuft, installieren wir noch einen NTP-Dämon. Aus Sicherheitsaspekten und benötigten Features benutzen wir openntpd: 

rescue:/# aptitude install openntpd

Es gibt noch einige kleine, aber sehr hilfreiche Tools, die wir ebenfalls noch installieren:

  • file zeigt den Dateityp an
  • htop ist ein komfortableres top
  • iftop zeigt die momentane Auslastung der Netzwerk-Schnittstellen an
  • less ist ein komfortablerer pager als more
  • locate dient zum schnellen Auffinden von Dateinamen
  • lshw dient zur Anzeige der installierten Hardware
  • lsof zeigt offene Dateien an
  • mc ist ein Norton-Commander-Klon, ein Dateimanager
  • netcat-openbsd ist mächtiger als netcat-traditional, welches wir gleich deinstallieren
  • screen benutzt man, um Sitzungen oder Befehle auszuführen, die auch weiterlaufen, wenn man die Verbindung schließt; man kann sie später wieder aufnehmen
  • strace ist ein Tool, das die ausgeführten Systemcalls eines Programms anzeigt
  • sysstat dient zur Anzeige von IO-Statistiken
  • tcpdump benutzt man, um Netzwerkverkehr anzeigen zu können
rescue:/# aptitude install -y file htop iftop less locate lshw lsof mc netcat-openbsd netcat-traditional- screen strace sysstat tcpdump

Anlegen der User-Accounts

Nun müssen wir auch User-Accounts anlegen, sonst können wir uns nicht mehr einloggen, hier mal für 2 von der Leitung (auch gut für neuinstallationen): 

rescue:/# useradd -c "Sebastian Mohr" -m -s /bin/bash sebi
rescue:/# passwd sebi
rescue:/# su - sebi
sebi@rescue:~$ mkdir .ssh
sebi@rescue:~$ cat > .ssh/authorized_keys <<EOF
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAjtzKxPXNIlHzao8WeojHHCFvixMhDEFgt/4HlC+5DO+Vzned23Ymg6vKLKot+VtCR5qbshHbmvfiqFkj6qahPtZdzsMg7Git2lMd88MgvzDI8ao9f4o6NrPrP7nOTR/mk8zKzRPF79O/u2Pz2bRLiuaIn8fOCi3mqsnmUqA3zene9Hn/stURTHin+elcewQt2Q66YmhersY2nulXL6PVQsW1MhstVy02lMvbbaxdHmeG0FJY/e+ibZt1CR2l5OOZ6ZmbpfN/14Do5ebqB0lOoOSwvnSgnB78pg6cFDa/k8ugUnCMndbprBgxvGDHSBQf7dmCm4Pi2XnH6dltBnZwraewG3RsxmndqA2dGtSG7mLn9TjxjJ9W4LMOndtts9HzMFDXT1CY/Izv4PsaC8s3rAsvR6bT8lSyRDVdYkwmD/YmoX8dnpiNphmdJVO/4WiHWkL0j+BYVxGrd3dZ7yNhUSgftdvuVF99zWWoO1atZlN7xMMP2sI4Dz5NJvVLCy4nmKSYoDiKZ0s06fKzFMAoAePaBNawSNSei5I2eih/VyLq+qUvEbYrAtPcvApPaOT22MjP24LNf1+WWhlB8Zii+8cWNsW+58Ze2+Ku9/RqlmGltC9a7n2zVevkmCV4JJ8TBBW66IKuInixW6qs9sFYXiBWGi3Edwc1SYpz56Rc6U9h0pZiQJze7H4RH/PqowNifjPMEhO8Ci7xB59zzx1jQECo6UHs+2PDnPWnP+V8oiusrr9wu+ONcy6aStD sebi@sinkpad
EOF
sebi@rescue:~$ exit

rescue:/# useradd -c "Jan Simons" -m -s /bin/bash jamasi
rescue:/# passwd jamasi
rescue:/# su - jamasi
jamasi@rescue:~$ mkdir .ssh
jamasi@rescue:~$ cat > .ssh/authorized_keys <<EOF
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAx2olFDwlPhh1plmUn24IZBj86gq2SxiqKgkmHEFy3qLKr5ZxiwqbZgDXba7ThGmcTmTEPGg/MhHl2pbbKaQrPGCrKDbtdJA2+8A/l4MDWln92KANqedR9n2L1ubEzFf4LUxBRIYMcu9L8PgqtJKIXq8bVD/i99tyJlE9Tz1y6LU= jan@blood
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAuQQc/FK9lI1ZGecCkvf8PPl4Y/N+NW2GB/N8XSSf+1FQmNqqbGN5XhBOmzBWnTmEIjIOQVVsz6NH/ItT90Xxa0Tgu5BbLUc8WKqxIp5VjQI4/WYhJ3t+xopMDIdGqH5mMWUQpcGmUU/8/wgemMILahbQJXIeE9dP+BLFxTZ0UCFYNiuTDWLQxYeg46Kyg6AxVdNyOo6xIZG75vFuAVwoZRw3Z1UFEfWb+i2vwels2/CWAhGSJ8iWASCjlJTJCN4rPJUPDuHUC9s8w27064xyD/IeHtRlPRh3NzDcAhlACRd6HTjyy75iqXLEeRf5CFBiGSmqXQke6RdWnRoyfZHDPw== jan@subito
EOF
jamasi@rescue:~$ exit

Aufräumen

Am Schluss räumen wir noch alles auf: 

rescue:/# exit
rescue:~# killall ntpd
rescue:~# killall nullmailer-send
rescue:~# killall mdadm
rescue:~# umount /mnt/boot/
rescue:~# umount /mnt/dev/
rescue:~# umount /mnt/proc/
rescue:~# umount /mnt/

Und schalten im OVH-Manager wieder auf Festplatten-Boot, dannach das letzte Kommando: 

rescue:~# reboot

Und dann kommt die neue Kiste hoffentlich bald wieder hoch ;-)

Installation der Dual-Server-Lösung

Für einen professionellen Betrieb wollen wir mehrere Netze einrichten:

  • Externes Netz
    • Öffentliche IP-Adressen, Dienste für Benutzer
  • Internes Netz
    • Interner Datenaustausch, z.B. für DB-Abfragen, Mail zwischen den Kisten, usw.
    • Aus Performanzgründen sollte geroutet und nicht gebriged werden
  • Storage-Netz
    • Schaufelt die benötigten Daten zu den Kisten; hier kümmert es sich um die Synchronisation der VM-Platten zwischen den Kisten mit DRBD.
    • Hier sollte jeder DRBD-Link einzeln verschlüsselt sein.
  • Admin-Netz
    • Administration und Installation der Rechner. Hier müssen DHCP-Anfragen verschickt werden und die VMs sollen unabhängig von dem eingesetzten Netz direkt erreichbar sein können.
    • Hier muss ein gebridgdes Netz vorliegen.

Weiterhin haben wir uns für die Virtualisierungslösung KVM entschieden. Im Test von 3 verschiedenen Versionen hat sich kvm-72 bewährt.

Die Performanztests sind hier zu finden: IT/Dokumentation/OVH-Grundinstallation/Performanztests

bridge-utils oder Verbindungen zwischen den VMs

Damit unsere virtuellen Maschinen sinnvoll miteinander reden können, benötigen wir eine Bridge für das Admin-Netz, auf der sich dann die entsprechenden tap-Devices der Netzwerkkarten der KVM-Instanzen tummeln. Dadurch können sie bereits DHCP-Anfragen beantworten, was für den Installations-Server wichtig wird.

Wir installieren dafür bridge-utils und tragen dannach in der /etc/network/interfaces zwei zusätzliche Bridges ein und aktivieren sie. Wichtig dabei ist, das forward delay herabzusetzen, sonst können die KVM-Maschinen nicht übers Netz booten: 

sebi@blackpearl:~$ sudo aptitude install bridge-utils
sebi@blackpearl:~$ cat <<EOF | sudo sh -c 'cat >> /etc/network/interfaces'

# The administration network
auto bradmin
iface bradmin inet manual
        bridge_ports none
        bridge_fd 0
        bridge_maxwait 0
        bridge_stp on

# The internal data network
auto brdata
iface brdata inet manual
        bridge_ports none
        bridge_fd 0
        bridge_maxwait 0
        bridge_stp on
EOF
sebi@blackpearl:~$ sudo ifup bradmin
sebi@blackpearl:~$ sudo ifup brdata

Nun sollten wir noch netfilter (Kernel-Firewall) aus Sicherheits- und Effizienzgründen auf den Bridges abschalten und die Änderungen aktivieren: 

sebi@blackpearl:~$ cat <<EOF | sudo sh -c 'cat > /etc/sysctl.d/bridge-netfilter-off.conf'
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0
EOF
sebi@blackpearl:~$ sudo /etc/init.d/procps restart

openvpn oder Verbindungen zwischen den Servern

Damit sie auch mit den Maschinen auf dem anderen Host im selben Subnetz sind und nach einer Migration immer noch unter der selben IP-Adresse zu erreichen sind, müssen wir diese Brücken miteinander verbinden. Dazu benutzen wir OpenVPN im p2p-Modus (da nur zwei Maschinen), um eine sichere Verbindung zum anderen Server aufbauen zu können.

Also installieren wir erstmal openvpn: 

sebi@blackpearl:~$ sudo aptitude -y install openvpn

Dannach erstellen wir ein kleines Hilfs-Script zum Hinzufügen der Interfaces zu den jeweiligen Brücken, die Konfigurationsdateien und die gemeinsamen Schlüssel: 

sebi@blackpearl:~$ cat <<'EOF' | sudo sh -c 'cat >> /etc/openvpn/brctl-wrapper.sh'
#!/bin/sh
# $1: "addif", "delif"
# $2: bridge-name
# $3: interface-name
brctl $1 $2 $3
ip link set up $3
EOF
sebi@blackpearl:~$ sudo chmod 755 /etc/openvpn/brctl-wrapper.sh
sebi@blackpearl:~$ cat <<EOF | sudo sh -c 'cat >> /etc/openvpn/bounty-blackpearl-admin.conf'
local 94.23.220.83
remote 94.23.198.106
port 14139
dev tap
persist-tun
persist-key
up '/etc/openvpn/brctl-wrapper.sh addif bradmin '
script-security 2
user nobody
group nogroup
comp-lzo
secret bounty-blackpearl-admin_static.key
EOF
sebi@blackpearl:~$ cat <<EOF | sudo sh -c 'cat >> /etc/openvpn/bounty-blackpearl-data.conf'
local 94.23.220.83
remote 94.23.198.106
port 41201
dev tap
persist-tun
persist-key
up '/etc/openvpn/brctl-wrapper.sh addif brdata '
script-security 2
user nobody
group nogroup
comp-lzo
secret bounty-blackpearl-data_static.key
EOF
sebi@blackpearl:~$ sudo openvpn --genkey --secret /etc/openvpn/bounty-blackpearl-admin_static.key
sebi@blackpearl:~$ sudo openvpn --genkey --secret /etc/openvpn/bounty-blackpearl-data_static.key

Die .key-Dateien müssen nun verschlüsselt auf den 2. Host übertragen werden. Für die Konfigurationsdateien auf dem 2. Host müssen nur die Parameter von "local" und "remote" vertauscht werden.

drbd-modules oder Daten-Speicher-Syncronisation

Als erstes einmal installieren wir die DRBD-Module und die DRBD-Utilities 

sebi@blackpearl:~$ sudo aptitude -y install drbd8-modules-2.6-amd64 drbd8-utils

Dann schreiben wir noch den gemeinsam genutzten Teil der Konfigurationsdatei für DRBD. 

sebi@blackpearl:~$ cat <<EOF | sudo sh -c 'cat > /etc/drbd.conf'
global {
  usage-count no;
}
common {
  syncer { rate 80M; }
  startup {
    wfc-timeout 120;
    degr-wfc-timeout 60;
  }
}
EOF

Zum Schluss starten wir noch DRBD über die init-Scripte, damit die Module geladen werden können. 

sebi@blackpearl:~$ sudo /etc/init.d/drbd start

Beim nächsten Systemstart werden die automatisch ausgeführt.

kvm oder Virtuelle Maschinen

Wir installieren kvm und libvirt ohne recommends, das spart uns einige Pakete, die das System sehr aufblähen würden: 

sebi@blackpearl:~$ sudo aptitude -y --without-recommends install kvm libvirt-bin

Anschließend fügen wir die Nutzer der libvirt-Gruppe hinzu, so dass sie mit dem virt-manager arbeiten können. 

sebi@blackpearl:~$ sudo usermod -G libvirt dyfa
sebi@blackpearl:~$ sudo usermod -G libvirt sebi
sebi@blackpearl:~$ sudo usermod -G libvirt chrit
sebi@blackpearl:~$ sudo usermod -G libvirt unger
sebi@blackpearl:~$ sudo usermod -G libvirt jamasi
sebi@blackpearl:~$ sudo usermod -G libvirt nhornung

Wir erweitern KVM um die Möglichkeit des PXE-Netz-Boots, einmal per Boot-ROM, einmal per Boot-CD. 

sebi@blackpearl:~$ sudo wget http://rom-o-matic.net/gpxe/gpxe-0.9.9/contrib/rom-o-matic/build.php --post-data 'version=0.9.9&ofmt=ROM+binary+%28flashable%29+image+%28.rom%29&nic=virtio-net&pci_vendor_code=1af4&pci_device_code=1000&A=Get+Image' -O /usr/share/kvm/pxe-virtio.bin
sebi@blackpearl:~$ sudo wget http://rom-o-matic.net/gpxe/gpxe-0.9.9/contrib/rom-o-matic/build.php --post-data 'version=0.9.9&ofmt=ISO+bootable+image+%28.iso%29&nic=virtio-net&pci_vendor_code=1af4&pci_device_code=1000&A=Get+Image' -O /root/gpxe-0.9.9-virtio-net.iso

KVM-Standard-Host mit Anmerkungen

XML Aufspannen. 

<domain type='kvm'>

Domain benennen. 

  <name>changeme</name>

Wird generiert. 

  <uuid></uuid>

Benutzter Speicher; Ballooning (ändern von currentMemory) führte zu Abstürzen. 

  <memory>524288</memory>
  <currentMemory>524288</currentMemory>

Anzahl der CPUs 

  <vcpu>1</vcpu>

Wir fahren den Gast mit 64-Bit (x86_64) / 32-Bit (i686) und booten von Platte (hd) / CD-ROM (cdrom) / PXE aus dem Netzwerk (network). 

  <os>
    <type arch='x86_64' machine='pc'>hvm</type>
    <boot dev='hd'/>
  </os>

Wir können ACPI und APIC und werden das auch benutzen! 

  <features>
    <acpi/>
    <apic/>
  </features>

Unser Betriebssystem kann mit mehreren Zeitzonen gut umgehen. 

  <clock offset='utc'/>

Verhalten nach Beendigung des KVM-Prozesses 

  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>destroy</on_crash>

Wir verwenden /usr/bin/kvm fürs virtualisieren. 

  <devices>
    <emulator>/usr/bin/kvm</emulator>

Ein CD-Laufwerk am IDE-Bus. Können wir nach funktionierendem Netzboot weglassen. 

    <disk type='file' device='cdrom'>
      <source file='/path/to/image.iso'/>
      <target dev='hda' bus='ide'/>
      <readonly/>
    </disk>

Zwei Platten, am flotten virtio-Bus. changeme_disk ist die System-Platte, changeme_srv ist das Dateisystem mit den Daten, welches unter /srv im Zielsystem gemountet wird. Siehe auch IT/Dokumentation/Namenskonventionen 

    <disk type='block' device='disk'>
      <source dev='/dev/raid/changeme_disk'/>
      <target dev='vda' bus='virtio'/>
    </disk>
    <disk type='block' device='disk'>
      <source dev='/dev/raid/changeme_srv'/>
      <target dev='vdb' bus='virtio'/>
    </disk>

Die Netzwerk-Interfaces, wieder virtio. Netzwerk-Boot ist nur von der ersten definierten Karte möglich. Boot-ROM unter rom-o-matic.net besorgen, PCI-ID: 1af4:1000. 'bridge'-Interfaces werden gleich auf eine Brücke gelegt, 'ethernet'-Interfaces bleiben im Host sichtbar und können direkt geroutet werden. Maximale Länge des device-Namens beachten! 

    <interface type='bridge'>
      <source bridge='bradmin'/>
      <target dev='changeme_adm'/>
      <model type='virtio'/>
    </interface>
    <interface type='bridge'>
      <source bridge='brdata'/>
      <target dev='changeme_int'/>
      <model type='virtio'/>
    </interface>
    <interface type='ethernet'>
      <script path='no'/>
      <target dev='changeme_ext'/>
      <model type='virtio'/>
    </interface>

Grafische Ein- und Ausgabe. type='tablet' nimmt er nicht an. Nur Konsole (<console/>) nimmt er auch nicht an. 

    <input type='mouse' bus='ps2'/>
    <graphics type='vnc' autoport='yes' keymap='de'/>
  </devices>
</domain>

Bitte IT/Dokumentation/OVH-Grundinstallation/KVM-Erstellung beachten!

Abgerufen von „https://wikimirror.piraten.tools/wiki/index.php?title=Archiv:2011/IT/Dokumentation/OVH-Grundinstallation&oldid=55543137“