Hetzner - DokuWiki

Citrix XenServer

Inhaltsverzeichnis

Installation von ISO-Datei mit KVM-Konsole

Mit der für 3 Stunden kostenlos nutzbaren KVM-Konsole ist es möglich, XenServer relativ unkompliziert zu installieren. Dazu muss man die XenServer-xxx-Install.iso-Datei von einem SMB/CIFS Share einbinden. Also platziert man erst die Datei XenServer-6.5.0-xenserver.org-install-cd.iso auf einem Server (z.B. auf dem eigenen Backup-Space bei Hetzner, der auch per SMB erreichbar ist) und gibt sie per SMB/Windows-Share frei. Anschließend trägt man die Zugangsdaten im KVM-Konsole Webinterface unter "Interfaces" => "Virtual Media" ein. Der "Share Name" für den Fall, dass die Datei im Backup Space liegt, zwingend "backup". Nun startet man den Server neu, er bootet nun die ISO-Datei und die Installation des XenServers kann mittels Spider KVM Konsole erledigt werden.

XenServer per PXE-Boot installieren

Zunächst wird auf dem Server ein Minimal-OS mit GPT (Debian oder Ubuntu) installiert. Anschließend kann man sich einloggen und dann die Netzwerkkonfiguration (/etc/networking/interfaces) notieren. Wichtig ist u.a. auch die Gateway-IP.

Xenserver Download + auf Webserver entpacken

Xenserver ISO von hier auf einen eigenen, separaten Webserver downloaden: xenserver.org

wget http://downloadns.citrix.com.edgesuite.net/10175/XenServer-6.5.0-xenserver.org-install-cd.iso
mount -o loop XenServer-6.5.0-xenserver.org-install-cd.iso /mnt
mkdir /var/www/xenserver
cp -a /mnt/* /var/www/xenserver

Answerfile generieren und nach /var/www/xenserver kopieren

Hier als Beispiel eine XML-Datei, die man z.B. xenserver.xml nennen kann. Achtung: Unbedingt die richtige IP-Adresse für den Server und den Gateway eintragen!

<installation mode="fresh" srtype="lvm">
<primary-disk gueststorage="yes">sda</primary-disk>
<keymap>de</keymap>
<hostname>xenserver-6-5</hostname>
<root-password>my_password</root-password>
<source type ="url">http://xx.xx.xx.xx/xenserver/</source>
<!-- No Post install scripts configured -->
<admin-interface name="eth0" proto="static">
<ip>Hetzner Server IP</ip>
<subnet-mask>255.255.255.224</subnet-mask>
<gateway>Hetzner Gateway IP</gateway>
</admin-interface>
<nameserver>213.133.98.98</nameserver>
<nameserver>213.133.99.99</nameserver>
<nameserver>213.133.100.100</nameserver>
<timezone>Europe/Berlin</timezone>
<time-config-method>ntp</time-config-method>
<ntp-servers>ntp</ntp-servers>
<ntpservers>213.239.239.164</ntpservers>
<ntpservers>213.239.239.165</ntpservers>
<ntpservers>213.239.239.166</ntpservers>
</installation>

Diese Datei sollte im gleichen Verzeichnis gespeichert werden, wie der Rest des Hauptverzeichnisses der Xenserver-CD.

Anpassungen für den PXE-Boot

Auf dem neuen Server: folgende Dateien vom eigenen Webserver auf den für die XenServer-Installation vorgesehene Server kopieren:

cd /boot
wget http://www.example.com/xenserver/install.img
wget http://www.example.com/xenserver/boot/vmlinuz
wget http://www.example.com/xenserver/boot/xen.gz

Nun auf dem neuen Hetzner-Server die Bootloader-Konfiguration anpassen. Bei Ubuntu 12.04 minimal kommt GRUB2 zum Einsatz. In der /boot/grub/grub.cfg wird der erste menuentry angepasst (siehe letzte 3 Zeilen):

if [ "${linux_gfx_mode}" != "text" ]; then load_video; fi
menuentry 'Ubuntu, with Linux 3.2.0-24-generic' --class ubuntu --class gnu-linux --class gnu --class os {
recordfail
gfxmode $linux_gfx_mode
insmod gzio
insmod raid
insmod mdraid1x
insmod part_gpt
insmod part_gpt
insmod ext2
set root='(mduuid/xxxxxxxxxxxxx)'
search --no-floppy --fs-uuid --set=root xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxx
multiboot /xen.gz dom0_mem=752M acpi=off nosmp noapic noirqbalance
module /vmlinuz answerfile=http://<IP-des-Remote-Servers>/xenserver/xenserver.xml install
module /install.img
}

Achtung: Die URL vom answerfile muss mit der IP des Servers angegeben werden, nicht mit dem Hostnamen. Daher aufpassen, wenn man NameVirtualHosts o.ä. einsetzt!

Reboot

Mit reboot den Server neu starten. Nun sollte die XenServer-Installation starten, was man leicht auf dem externen Webserver per “tail -f /var/log/apache2/access.log” prüfen kann.

Sollte da auch nach einigen Minuten noch keine Aktivität erscheinen, hängt der Server wahrscheinlich im Boot-Menü! In diesem Fall einfach mittels KVM-Konsole den ersten Eintrag mit <ENTER> bestätigen.

Nach der Installation sollte der Xenserver per SSH mit dem im Answerfile eingegebenen Passwort erreichbar sein.


Alternative Installation mit dem VKVM Rescue-System

Mit dem neuen VKVM Rescue System kann man die XenServer Iso auch direkt Booten und mit der VNC Konsole den Installationsprozess durchführen. Dazu meldet man sich per ssh am KVM Rescue System an:

ssh root@<IP> -p 47772

Dort lädt man sich das gewünschte Iso herunter, z.B. nach /root/image.iso. Das eigentliche System wird mit dem Skript /opt/vkvm/startqemu gestartet. Dessen Kommandozeile ergänzt man mit:

-boot d -cdrom /root/image.iso

Startet man jetzt die VM neu, sollte das Iso Image booten.

Software-RAID1

XenServer 6.5 nutzt GPT statt MBR zur Einrichtung der Partitionen. Die 3 TB Festplatten eines EX4 etc. werden damit voll ausgenutzt.

zweite Festplatte sdb einrichten

/dev/sda sollte nach der Installation 3 Partitionen enthalten. Um das zu überprüfen lässt man sich die Partitionen auf /dev/sda anzeigen:

sgdisk -p /dev/sda

Fehlt die Partition sda3, so muss man sie nachträglich anlegen. Dazu ruft man

gdisk /dev/sda

auf und legt mit "n" eine neue Partition mit der Nummer 3 an. Anfang und Ende einfach bestätigen und anschließend mit "w" die Partitionstabelle speichern. Danach rebooten um die geänderte Partitionstabelle zu laden.

RAID anlegen

sgdisk --zap-all /dev/sdb # Partitionen auf /dev/sdb loeschen
sgdisk --mbrtogpt --clear /dev/sdb
sgdisk -R/dev/sdb /dev/sda # Replicate partion table from /dev/sda to /dev/sdb  with unique identifier
sgdisk --typecode=1:fd00 /dev/sdb
sgdisk --typecode=2:fd00 /dev/sdb
sgdisk --typecode=3:fd00 /dev/sdb
modprobe md_mod # load raid, because it isn't load by default (XS6.5 only)
yes|mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdb1 missing # Create md0 (root)
yes|mdadm --create /dev/md1 --level=1 --raid-devices=2 /dev/sdb2 missing # Create md0 (swap)
yes|mdadm --create /dev/md2 --level=1 --raid-devices=2 /dev/sdb3 missing # Create md0 (storage)
mdadm --grow /dev/md0 -b internal
mdadm --grow /dev/md1 -b internal
mdadm --grow /dev/md2 -b internal

Die neue RAID-Konfiguration in eine aktualisierte mdadm.conf speichern:

mdadm --examine --scan > /etc/mdadm.conf

Copy Store Manager Data to RAID

pvcreate -ff /dev/md2
vgextend VG_<TAB> /dev/md2
pvmove /dev/sda3 /dev/md2

Remove /dev/sda3 from the SR volume group

vgreduce VG_<TAB> /dev/sda3
pvremove /dev/sda3

Mounte /dev/md0 und kopiere das Filesystem

mkfs.ext3 /dev/md0
mount /dev/md0 /mnt
cd /
cp -xR --preserve=all / /mnt # Replicate root files

Nun muss die Datei /mnt/etc/fstab angepasst werden

sed -i 's/LABEL=[a-zA-Z\-]*/\/dev\/md0/' /mnt/etc/fstab # Update fstab for new RAID device

Neue Initrd erstellen:

mount --bind /dev /mnt/dev
mount -t sysfs none /mnt/sys
mount -t proc none /mnt/proc
chroot /mnt /sbin/extlinux --install /boot
dd if=/mnt/usr/share/syslinux/gptmbr.bin of=/dev/sdb
chroot /mnt
mkinitrd -v -f --theme=/usr/share/splash --without-multipath /boot/initrd-`uname -r`.img `uname -r`
exit
sed -i 's/LABEL=[a-zA-Z\-]*/\/dev\/md0/' /mnt/boot/extlinux.conf # Update extlinux for new RAID device
cd /mnt && extlinux --raid -i boot/
sgdisk /dev/sdb --attributes=1:set:2
umount /dev/md0
sync

Das RAID-Array ist nun fast komplett, es müssen nur noch die Partitionen auf /dev/sda hinzugefügt werden. Wenn einem noch die KVM-Konsole zur Verfügung steht, kann man nun per Neustart und der Taste F11 (bei manchen Servern F8) ins BIOS oder Bootmenü kommen und dort die zweite Festplatte als Bootmedium auswählen. Hat man keine KVM-Konsole zur Verfügung, muss man ins Rescue System rebooten (im Robot Rescue System aktivieren, Passwort kopieren, Server per Hardware-Reset neu booten). Im Rescue System ausführen:

gdisk -R/dev/sda /dev/sdb # Replicate partition table from /dev/sdb to /dev/sda with unique identifier
sgdisk /dev/sda --attributes=1:set:2
mdadm -a /dev/md0 /dev/sda1
mdadm -a /dev/md1 /dev/sda2
mdadm -a /dev/md2 /dev/sda3

Das RAID-Array muss sich nun erstmals synchronisieren, was einen Augenblick lang(!) dauert (Nach dieser Anleitung bei 3TB Platten ca. 6 Stunden). Den Fortschritt kann man wie folgt beobachten: watch -n 1 cat /proc/mdstat Falls das letzte Kommando einen Fehler ausgibt, muss man erst ein bestehendes SR löschen und den Befehl dann wiederholen.

Das folgende Kommando legt ein neues SR an. Dazu benötigt man die Host UUID, die man einfach per Autovervollständigung mittels Tab erhält, wenn man den Befehl bis "host-uuid=" eingibt. Danach den Rest des Befehls anhängen.

#This next command is the only command you have to manually update before pasting in. Find the UUID of your xenserver host and paste it between the <> below
xe sr-create content-type=user device-config:device=/dev/md2 host-uuid=<UUID of xenserver host> name-label="RAID 1" shared=false type=lvm

Dieser Aufruf funktioniert erst, wenn man das Rescue System verlassen und den XenServer gestartet hat.

Einbinden von ISO Libraries

ISO Library vom Backup Server einbinden

Am einfachsten geht es eine ISO Library direkt vom Backup Server einzubinden, da XenServer CIFS Freigaben dafuer unterstuetzt. Dafuer klickt man im XenCenter auf "New Storage", waehlt dann unter "ISO library" den Eintrag "Windows File Sharing (CIFS)".

Jetzt geht man einfach durch den Wizard und traegt seine Zugangsdaten fuer den Backup Server ein.

Share: //<Benutzername>.your-backup.de/backup
Username: <Benutzername>
Password: <Passwort>

Lokale ISO Library einbinden

XenServer 6.0 bietet keine Moeglichkeit ISO Images im lokalen Storage anzubieten. Um dies dennoch zu ermoeglichen, wird im LVM des Datenbereiches ein neues LV angelegt und per lokalem NFS Server durchgereicht. Es ist nicht performant, aber es erfüllt seinen Zweck. Quelle: http://forums.citrix.com/thread.jspa?messageID=1393861&tstart=0

Eigene VG finden

vgscan
#Reading all physical volumes. This may take a while...
#Found volume group "VG_XenStorage-709d46ed-8193-d470-4ab8-21953af4f863" using metadata type lvm2

Neues LVM anlegen

(bsp mit 20 GB)

lvcreate -L 20G -n ISO VG_XenStorage-<meineid>
#Logical volume "ISO" created

Filesystem anlegen

mkfs.ext3 /dev/VG_XenStorage-<meineid>/ISO

/etc/exports anpassen

mkdir /ISO
echo "/ISO 127.0.0.1(rw,no_root_squash,sync)" >> /etc/exports

NFS und Portmappen starten und rebootfest aktivieren

chkconfig --level 345 nfs on
chkconfig --level 345 portmap on
service nfs start
service portmap start

Mount beim boot

Am Ende des Files /etc/rc.local folgendes hinzufuegen:

lvchange -a y /dev/VG_XenStorage-<meineid>/ISO
mount /dev/VG_XenStorage-<meineid>/ISO /ISO

ISO Libray in XenCenter eintragen

Im XenCenter kann man nun eine neue Storage-Library hinzufügen, Typ “NFS ISO”. Als Mountpoint "localhost:/ISO" angeben

Netzwerkkonfiguration

Host als Router konfigurieren

Der XenServer wird durch Änderungen in der Datei /etc/sysctl.conf als Router konfiguriert (die ersten paar Zeilen bis einschließlich net.ipv4.ip_forward = 0 durch die folgenden ersetzen):

# Kernel sysctl configuration file for Red Hat Linux
#
# For binary values, 0 is disabled, 1 is enabled.  See sysctl(8) and
# sysctl.conf(5) for more details.

# Controls IP packet forwarding
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding=1

# Controls proxy arp
net.ipv4.conf.default.proxy_arp = 0

# Turn off redirects
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.lo.send_redirects = 0
net.ipv4.conf.xenbr0.send_redirects = 0

Die Einstellungen sind nun nach jedem Neustart aktiv. Sie lassen sich aber auch ohne Neustart direkt mit dem sysctl -p Befehl anwenden:

sysctl -p

IPv4

Konfiguration der zusätzlichen IP-Adressen

Mit einem dedizierten Server bekommt man automatisch 1 IPv4-Adresse. Man kann bis zu 3 IPv4-Adressen zusätzlich bestellen. Siehe dazu: IP-Adressen

Konfiguration einer Failover IP-Adresse

Eine Failover IP-Adresse ist eine Adresse, die auf einen beliebigen anderen physischen Hetzner-Server geschaltet werden kann.

Konfiguration eines zusätzlichen Subnetzes

In der Standardkonfiguration kann man mit den 3 zusätzlichen IPv4-Adressen bis zu 3 virtuelle Server gleichzeitig betreiben. Man hat auch die Möglichkeit, Subnetze zu bestellen. Siehe dazu: IP-Adressen

Für ein zusätzliches Subnetz gilt im wesentlichen dasselbe wie oben. Eine IP-Adresse des Subnetzes fungiert als Gateway, die anderen kann man für die Guests verwenden.

Damit der Host auch weiß, dass er die Pakete aus dem Subnetz routen soll, weisen wir dem xenbr0-Interface die erste IP-Adresse aus dem Subnetz (hier xx.yy.177.160/27) zu:

ip addr add xx.yy.177.161/27 dev xenbr0

Routing zu benachbarten Servern

Falls man mehrere Server gleichzeitig bestellt hat, die übereinander im Rack stehen und aufeinanderfolgende IP-Adressen haben, wird man feststellen, dass kein Ping oder ssh-Zugang zu den benachbarten Systemen möglich ist. Dies liegt daran, dass normalerweise alle Systeme im selben Subnetz ohne Gateway erreichbar sein sollten, aber bei Hetzner ist das aus Sicherheitsgründen nicht möglich. Die benachbarten Server sind nur über's Hetzner-Gateway zu erreichen. Die Routing-Konfiguration sieht so aus:

route add -net xx.yy.44.64 netmask 255.255.255.192 gw xx.yy.44.65 xenbr0

xx.yy.44.65 ist in diesem Fall die IP-Adresse des Hetzner-Gateways, um die IP-Adresse des gesamten Subnetzes zu erhalten, zieht man einfach 1 ab, was xx.yy.44.64 ergibt.

Diese beiden Befehle müssen nach jedem Neustart des Hosts ausgeführt werden, sonst bekommen die virtual machines keine Verbindung in die große weite Internet-Welt.

Konfigurationsbeispiel:
Dem Server wurden seitens des Rechenzentrums folgende IP-Adressen zugewiesen: xx.yy.44.76, xx.yy.44.105, xx.yy.44.108 und xx.yy.44.110. Diese Adressen liegen alle im selben Subnetz xx.yy.44.64/26. Das für dieses Subnetz zuständige Gateway hat die Adresse xx.yy.44.65.
Die XenServer virtual machines bekommen also die IP-Adressen xx.yy.44.105, xx.yy.44.108 und xx.yy.44.110, als zuständiges Gateway wird xx.yy.44.76 eingetragen.
Das dazubestellte Subnetz mit 32 Adressen ist xx.yy.177.160/27 . Die erste und die letzte IP-Adresse sind nicht nutzbar, da es sich um die Subnetz- bzw. die Broadcast-Adresse handelt. Die IP-Adresse xx.yy.177.161 fungiert als Gateway, es stehen also 29 IP-Adressen für die Guests zur Verfügung: xx.yy.177.162 - xx.yy.177.191. Das Gateway für Guests in diesem Adressbereich ist xx.yy.177.161.

Rebootfest macht man dies durch Einträge in der Datei /etc/sysconfig/networking-scripts/ifcfg-xenbr0:

up ip addr add xx.yy.177.161/27 dev xenbr0
down ip addr del xx.yy.177.161/27 dev xenbr0
up route add -net xx.yy.44.64 netmask 255.255.255.192 gw xx.yy.44.65 xenbr0
down route del -net xx.yy.44.64 netmask 255.255.255.192 gw xx.yy.44.65 xenbr0

IPv6

Mit einem kostenlos erhältlichen (und bei neuen Servern automatisch aktivierten) IPv6-Subnetz in der Form 2a01:4f8:xxx:xxxx::/64 hat man fast 2^64 IPv6-Adressen - mehr als genug.

Der XenServer soll in seinem Subnetz die IP 2a01:4f8:xxx:xxxx::2/112 bekommen. Da der XenServer weder auf dem Management-Interface in der xsconsole noch im XenCenter IPv6-Einstellungen unterstützt, muss man erst IPv6 mit dem folgenden Befehl auf der Kommandozeile dauerhaft aktivieren:

/opt/xensource/bin/xe-enable-ipv6 enable

Dann folgende Zeilen in der Datei /etc/sysctl.conf ändern:

# disable ipv6 on interfaces
#net.ipv6.conf.all.disable_ipv6 = 1
#net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.all.forwarding=1

(die ersten 2 einfach auskommentieren)

Anschließend neu starten Nun prüft man, ob xenbro0 eine link-lokale IPv6-Adresse erhalten hat:

ip -6 addr show dev xenbr0

Man sollte eine /64 Adresse sehen, die mit fe80 beginnt (z.B.: fe80::20c:29ff:fe48:5bc9/64). Nun noch die eigentliche IPv6-Adresse auf dem XenServer mittels (Achtung: Kommando anpassen!)

xe pif-reconfigure-ipv6 mode=static uuid=<ersetze mit PIF_UUID einfach Autovervollständigung mit Tab nutzen> ipv6=2a01:4f8:xxx:xxxx::2/112

hinzufügen. Das war's schon für den Host.

In den jeweiligen VMs (so sie denn mit Linux laufen) nimmt man dann folgende Einstellungen vor:

ip addr add 2a01:4f8:xxx:xxxx::y/64 dev eth0
ip route add default via 2a01:4f8:xxx:xxxx::2

Treiber für die Netzwerkkarte austauschen (optional)

Der standardmäßig im XenServer geladene Treiber (r8169) für die Realtek-Netzwerkkarte produziert unter Umständen Paketverluste. Daher muss auf einen alternative Treiber umgesattelt werden: r8168. Um den Netzwerkkartentreiber zu kompilieren, benötigt man das zur eigenen XenServer-Version passende Driver Development Kit (DDK), welches auf der Citrix Seite heruntergeladen werden kann: http://downloadns.citrix.com.edgesuite.net/10106/XenServer-6.5.0-DDK.iso (für XenServer 6.5.0)

Ich gehe davon aus das das ISO von euch bereits nach /ISO kopiert wurde. Vorerst sollte zusätzlich mittels XenCenter das VM Storage als Default markiert werden (Rechtsklick -> Default Storage) da sonst der xe vm-import Befehl nicht funktioniert.

ISO Mounten:

mkdir /mnt/iso
mount -o loop /local/iso/XenServer-6.5.0-DDK.iso /mnt/iso

DDK VM Importieren:

xe vm-import filename=/mnt/iso/ddk/ova.xml

Im XenCenter muss dann noch ein Netzwerkdevice zur Virtuellen Maschine hinzugefügt werden, danach kann man die Maschine starten und ein root Passwort setzen mit dem man sich dann einloggen kann.

Nun tragen wir die richtigen Netzwerkeinstellungen für die VM ein: /etc/sysconfig/network-scripts/ifcfg-eth0

DEVICE=eth0
BOOTPROTO=static
IPADDR=IP-ADRESSE-DER-VM
NETMASK=255.255.255.224
ONBOOT=yes
TYPE=ethernet

/etc/sysconfig/network-scripts/route-eth0

IP-ADRESSE-DER_VM dev eth0 scope link
default via IP-DES-XENSERVERS-BZW-BEI-IP-NETZ-DIE-DES-xenbr0:1

/etc/resolv.conf

nameserver 213.133.99.99
nameserver 213.133.100.100

Nun den Treiber ziehen, entpacken und kompilieren:

cd /root
wget http://r8168.googlecode.com/files/r8168-8.037.00.tar.bz2
tar xjf r8168-8.037.00.tar.bz2
cd r8168-8.037.00
make all

Den neuen Treiber (src/r8168.ko) auf das Hostsystem übertragen nach: /lib/modules/<neueste Kernelversion>/kernel/drivers/net/

Dem Treiber dann die richtigen Rechte geben:

chmod 0744 /lib/modules/<neueste Kernelversion>/kernel/drivers/net/r8168.ko

Nun den neuen Treiber in die /etc/modprobe.conf eintragen:

echo "alias eth0 r8168" > /etc/modprobe.conf

Der kompilierte Treiber muss nun noch aktiviert werden. Da der Server währenddessen für einige Sekunden nicht übers Netzwerk erreichbar sein wird, werden die nötigen Befehle in eine Zeile geschrieben.

rmmod r8169 && depmod -a && modprobe r8168 && service network restart && service ipaliases restart

Nach wenigen Sekunden sollte der Server mit dem neuen Netzwerkkartentreiber wieder übers Netzwerk erreichbar sein. Wenn alles richtig gelaufen ist, wird der neue Treiber für die Netzwerkschnittstelle genutzt:

lspci -nnk | grep -i net -A2

In der letzten Zeile sollte stehen: "Kernel driver in use: r8168"

TCP Offloading deaktivieren (optional)

Wenn es auch mit dem neuen Treiber noch Performance-Probleme mit dem Netzwerk gibt, dann ist wahrscheinlich das TCP Offloading die Ursache. Eigentlich geht es dabei darum den Prozessor zu entlasten und fuer den Netzwerkverkehr notwendige Rechenlast von der Netzwerkkarte machen zu lassen. In XenServer 6.5 gibt es damit anscheinend Probleme, die zu erheblichen Paketverlusten fuehren, aber zum Glueck ist es abschaltbar.

Fuer ein einzelnes Interface kann man das mit dem ethtool konfigurieren:

ethtool -K xenbr0 rx off tx off sg off tso off ufo off gso off gro off lro off

Fuer die vom XenServer verwalteten virtuellen Netzwerkkarten (VIF/PIF) geht das mit xe entsprechend. Hier ist ein Script, mit dem man Offloading fuer alle Interfaces auf allen VMs abschalten kann:

#!/bin/bash

ethtool -K xenbr0 rx off tx off sg off tso off ufo off gso off gro off lro off

for PIFUUID in `xe pif-list | awk '/uuid/ {print $5}' | sed '/^$/d'`
  do
    xe pif-param-set uuid=$PIFUUID other-config:ethtool-gso="off";
    xe pif-param-set uuid=$PIFUUID other-config:ethtool-ufo="off";
    xe pif-param-set uuid=$PIFUUID other-config:ethtool-tso="off";
    xe pif-param-set uuid=$PIFUUID other-config:ethtool-sg="off";
    xe pif-param-set uuid=$PIFUUID other-config:ethtool-tx="off";
    xe pif-param-set uuid=$PIFUUID other-config:ethtool-rx="off";
done

for INSTANCEID in `xe vm-list | awk '/name-label/' | grep -v "Control domain" | awk '{print $4}'`
  do
    VMUUID=`xe vm-list name-label=${INSTANCEID} | awk '/uuid/ {print $5}'`
      for VIFUUID in `xe vif-list vm-uuid=$VMUUID | awk '/uuid/ {print $5}' | sed '/^$/d'`
        do
          xe vif-param-set uuid=$VIFUUID other-config:ethtool-gso="off"
          xe vif-param-set uuid=$VIFUUID other-config:ethtool-ufo="off"
          xe vif-param-set uuid=$VIFUUID other-config:ethtool-tso="off"
          xe vif-param-set uuid=$VIFUUID other-config:ethtool-sg="off"
          xe vif-param-set uuid=$VIFUUID other-config:ethtool-tx="off"
          xe vif-param-set uuid=$VIFUUID other-config:ethtool-rx="off"
      done
done

Virtuelle Maschinen von einem anderen (älteren) XenServer übertragen

Der XenServer ist zum Glück recht flexibel, was die Übertragung von virtuellen Maschinen eines anderen XenServer-Hosts angeht. Im Grunde gibt es viele Möglichkeiten, eine davon ist z.B. das remote-mounten eines Verzeichnisses (per NFS) auf dem neuen XenServer-Host vom alten XenServer-Host aus. In dieses Verzeichnis wird dann eine VM nach der anderen exportiert (per "xe vm-export uuid=xxx-xxx filename=vm1.xva") und jeweils auf dem neuen Host wieder importiert ("xe vm-import filename=vm1.xva").

Quellen:



© 2017. Hetzner Online GmbH. Alle Rechte vorbehalten.