XENMASTER
Dieses Dokument beschreibt die erforderlichen Schritte zur Installation, Konfiguration und Wartung einer Citrix™ XenServer Umgebung. Besonders wird auf die Installation von Storage, Netzwerken und Ressource Pools sowie auf die Wartung und Administration über die CLI (Command Line Interface) eingegangen. Die nachfolgende Übersicht beschreibt die enthaltenen Kapitel, damit sie die Informationen, welche sie benötigen, schneller finden können.
Ein Ressource Pool ist eine Gruppe von Xen Servern, welche logisch miteinander gruppiert sind und sich ein gemeinsames Storage System teilen. Virtuelle Maschinen auf einem Xen Server innerhalb eines Ressource Pools können live und ohne downtime zwischen den Mitgliedern des Pools migriert werden. Damit reduziert sich der Bedarf an Wartungsfenstern. Das Kapitel XenServer Hosts und Resource Pools beschreibt die Konzepte von Ressource Pools.
Das Kapitel Netzwerk beschreibt die Konzepte von physischen und virtuellen Netzwerken.
Das Kapitel Storage beschreibt die Konzepte von physischen und virtuellen Speicher.
Das Kapitel Command Line Interface beschreibt das Kommando xe, mit dem sämtliche Wartungs- und Konfigurationsarbeiten über die Kommandozeile erledigt werden können. Unter anderem wird folgendes beschrieben:
Das Kapitel Command Line Interface wurde komplett in ein eigenes Dokument ausgelagert. 
Ein Ressource Pool fasst mehrere Xen Server Installationen zu einer einzigen, verwaltbaren Einheit zusammen, um virtuelle Maschinen auszuführen. Wenn innerhalb des Pools gemeinsam nutzbarer Speicher zur Verfügung steht, können virtuelle Maschinen innerhalb des Pools auf jeden anderen Server- vorausgesetzt erforderliches RAM ist vorhanden- verschoben werden (XenMotion). Bei einem Hardwarefehler eines Xen Servers können die virtuellen Maschinen auf einem anderen Server wieder gestartet werden und reduzieren hier die benötigte downtime zur Wiederherstellung des fehlerhaften Servers.
Dieses Kapitel beschreibt an Hand von Beispielen, wie Ressource Pools über das Command Line Interface für die unterschiedlichsten Anforderungen erstellt werden. Weiterhin wird beschrieben, wie im Fehlerfall eines XenServers virtuelle Maschinen auf anderen Server gestartet und weiter ausgeführt werden können. Jeder Ressource Pool besteht aus mindestens einem XenServer, der die Rolle des Masters erhält. Weitere Server können in den Pool aufgenommen werden und erfüllen dann die Rolle eines Slave-Servers. Nur der Master Server bietet eine Administrationsschnittstelle für das XenCenter oder das Command Line Interface. Der Master Server leitet alle Kommandos auf die entsprechenden Server weiter.
Ein Ressource Pool ist ein logischer Zusammenschluss von mehreren XenServern. Folgende Voraussetzungen müssen alle Server innerhalb des gleichen Pools erfüllen:
Ein Server kann weiterhin nur Mitglied eines bestehenden Pools werden wenn:
XenServer innerhalb eines Pools können eine unterschiedliche Anzahl von Netzwerkschnittstellen haben und auch die Größe der SR's (Storage Repositories) kann innerhalb eines Pools variieren. Es kommt oft vor, dass nicht alle Parameter auf allen Servern exakt gleich sind. Wenn sie sich sicher sind, dass kleine Unterschiede innerhalb eines Pools zu vernachlässigen sind, können sie die Aufnahme in einen Pool auch erzwingen.
Nicht nur die XenServer benötigen statische IP-Adressen. Auch die Systeme, die den shared Storage zur Verfügung stellen, müssen mit statischen IP-Adressen konfiguriert werden.
Technisch ist es nicht unbedingt erforderlich, dass alle Server innerhalb des Pools an einen shared Storage angebunden sind. Allerdings wird empfohlen, nach dem Erstellen eines Pools, alle Server, die noch virtuelle Maschinen mit local Storage haben, in den shared Storage zu migrieren. Dies kann mit der CLI und dem Kommando xe vm-copy oder mit dem XenCenter erledigt werden.
Ressource Pools können mit dem XenCenter oder über die CLI erstellt werden. Um einen Host über das Command Line Interface in einen bestehenden Pool aufzunehmen, sind folgende Kommandos erforderlich:
xe pool-join master-address=HOST-A master-username=root master-password=password
Die Adresse des Master Servers master-address= muss ein FQDN sein, dass verwendete Passwort master-password= ist das, welches bei der Installation angegeben wurde.
Dieser Abschnitt beschreibt, wie man einem bestehenden Ressource Pool shared Storage (hier SR - Storage Repository) hinzufügt. In diesem Beispiel wird über die CLI SR von einem existierenden NFS Server zugefügt.
xe sr-create content-type=user type=nfs name-label="Example SR" ∠ shared=true device-config-server=server device-config-serverpath=path
Rückgabewert ist die UUID des SR's, die dann im 4. Schritt benötigt wird.
xe pool-param-set uuid=<pool-uuid> default-SR=<sr-uuid>
Nachdem das SR als poolweit angelegt wurde, werden alle neuen virtuellen Maschinen per Default in dieses Storage Repository installiert.
Installieren einer virtuellen Maschine über das CLI, basierend auf dem Debian Etch (4.0) Template:
Das Kommando xe vm-start startet die virtuelle Maschine auf irgendeinem Host innerhalb des Pools. Um einen bestimmten Server auszuwählen, muss das Kommando mit dem Parameter on=<Name des Servers> ausgeführt werden. Um eine virtuelle Maschine immer auf einen bestimmten Xen Server zu starten, muss das Kommando xe vm-param-set affinity=<UUID des Xen Servers> ausgeführt werden. Sollte der Start der Maschine auf diesem Server fehlschlagen, wird die virtuelle Maschine auf einem anderen Server im Pool gestartet.
Um eine virtuelle Maschine nach dem Start auf einen anderen Xen Server zu migrieren, kann auch XenMotion benutzt werden. Mit folgendem Kommando wird die virtuelle Maschine VM1 auf den Host HOST-B migriert: xe vm-migrate vm=VM1 host=HOST-B –live. Während dieses Prozesses läuft die virtuelle Maschine weiter.
Wird ein Xen Server aus einem Pool entfernt, reinitialisiert er sich zuerst und bleibt dann im frisch installierten Status. Befinden sich noch wichtige Daten auf dem lokalen SR, sollte der Server nicht aus dem Pool entfernt werden. Beim Pool Eject wird die lokale iSCSI IQN ebenfalls neu initialisiert.
Um z.B. den HOST-B aus dem Pool zu entfernen, sind folgende Schritte erforderlich:
Wenn ein Server mit virtuellen Maschinen im local SR des Servers aus dem Pool entfernt wird, bleiben die Datenbankeinträge dieser VMs erhalten. Sie können dann von anderen Hosts noch gesehen jedoch nicht gestartet werden. Um Datenverluste zu verhindern, sollten alle VMs vor einem Pool Eject auf shared SR's kopiert werden.
Fehler im Xen Server Umfeld lassen sich in zwei Kategorien einteilen, die im Nachfolgenden separat behandelt werden.
Der Master Server eines Pools endeckt fehlerhafte Slave Server über einen Heartbeat Mechanismus. Wenn der Master innerhalb von 30 Sekunden keinen Heartbeat von einem Slave bekommt, ist dieser für ihn „tot“. Es gibt hier zwei Möglichkeiten das Problem zu beseitigen:
xe host-forget uuid=**<UUID des Slave Server>
Laufende virtuelle Maschinen (im shared SR) werden nach einem xe host-forget als offline markiert und können auf anderen Servern wieder gestartet werden. Stellen sie sicher, dass der Host tatsächlich offline ist, da es sonst zu fehlerhaften virtuellen Maschinen und Datenverlust kommen kann. In manchen Fällen haben virtuelle Maschinen noch den Status „Running“. Wenn sichergestellt ist, dass der entsprechende Server offline ist, können sie mit folgendem Kommando die VM's in den „Halted“ Status versetzen:
xe vm-reset-powerstate force=true vm=<UUID der virtuellen Maschine>
Jeder Slave Server in einem Pool ist im Besitz sämtlicher Informationen, um im Fehlerfall die Rolle des Master Server zu übernehmen. Fällt ein Master Server aus, passiert folgendes:
Sollte der Master Server wieder erreichbar sein (z.B. durch einen Reboot), stellen die Slave Server dies automatisch fest und verlassen den Emergency Mode. Danach ist die normale Funktion wieder gegeben.
Wenn der Master Server nicht mehr funktioniert, muss manuell ein Slave Server diese Rolle übernehmen (siehe auch XenServer Pool-Master Probleme). Folgende Schritte sind dazu erforderlich:
xe pool-emergency-transition-to-master
xe pool-recover-slaves
Dieser Vorgang geschieht nicht automatisch, sondern muss immer manuell durchgeführt werden. Solange kein Master Server im Pool vorhanden ist, erfolgt keine Kommunikation mit dem Pool.
Sollte der ehemalige Master Server repariert oder ersetzt werden, kann er ohne weiteres als neuer Slave Server in den Pool aufgenommen werden. Es besteht kein Grund, diesen Server wieder zum Master Server zu machen.
Wenn ein Slave Server über die pool-emergency Kommandos zu einem Master gemacht wird, ist es notwendig auch das default Storage Repository zu kontrollieren. Dies geschieht mit dem folgenden Kommando:
xe pool-param-list
Der Parameter default-SR muss auf ein gültiges Storage Repository zeigen.
Dieses Kapitel beschreibt die Abhängigkeiten zwischen physischen Netzwerkschnittstellen auf XenServer Host und den virtuellen Netzwerkschnittstellen in den virtuellen Maschinen, damit diese untereinander sowie mit externen Netzwerk Ressourcen kommunizieren können.
XenServer Host Netzwerke sind virtuelle Ethernet Switches. Jedes Netzwerk kann mit einem extern Interface (mit oder ohne VLAN Tag) oder einem internen virtuellen Netzwerk verbunden sein. Bei der Installation eines XenServers wird jedem physischen Interface ein Netzwerk zugewiesen. Wird ein Server zu einem Ressource Pool hinzugefügt, werden die Netzwerke zusammengefasst. Netzwerkinterfaces mit gleichem Namen befinden sich dann auch im gleichen Netzwerk.
In den meisten Fällen müssen neue Netzwerke nur dann manuell erstellt werden, wenn ein internes Netzwerk benötigt wird oder ein neues VLAN auf einer bestehenden physikalischen Netzwerkschnittstelle erzeugt werden soll. Wenn eine neue virtuelle Maschine unter Verwendung des Command Line Interfaces erstellt wird, ist dieser VM erstmal kein Netwerk zugewiesen. Dies muss in einem weiteren Schritt erstellt werden. Bei der Verwendung des XenCenter zum Erstellen der neuen virtuellen Maschine, führt ein Wizzard durch die Erstellung der benötigten virtuellen Netzwerkschnittstellen.
XenServer unterstützten bis zu sechs physische Netzwerkschnittstellen pro XenServer Host und jede virtuelle Maschine unterstützt bis zu sieben virtuelle Netzwerkschnittstellen.
Das Xen Command Line Interface kann benutzt werden, um drei Typen von Objekten zu konfigurieren:
Es können manuell zusätzliche Netzwerke angelegt werden, u.a. interne Netzwerke (Netzwerke die keiner physikalischen NIC zugewiesen werden, sondern nur intern auf dem XenServer Host vorhanden sind). Diese Netzwerke verbinden z.B. virtuelle Maschinen untereinander, ohne eine Verbindung zum Rest der Welt zu haben.
Neue externe Netzwerk können angelegt werden, wenn z.B. eine zusätzliche physische Netzwerkkarte in einem XenServer Host hinzugefügt wird. In diesem Fall muss natürlich zuerst die Netzwerk Konfiguration angepasst werden (siehe Kapitel 3.3). Ausführliche Angaben zum hinzufügen oder entfernen von Netzwerken mit dem XenCenter sind in der Online Hilfe zu finden.
Um Netzwerke mit dem Comman Line Interface zu erstellen, sind folgende Schritte erforderlich:
xe network-create name-label=mynewnetwork
Auf der Konsole wird dann die UUID des neuen Netzwerkes ausgegeben.
Um das neue Netzwerk einem externen VLAN zuzuweisen sind folgende Kommandos erforderlich:
xe pif-list
xe vlan-create- network-uuid=uuid pif-uuid=uuid vlan=5
Auf der Konsole wird dann die UUID des neuen VLANs ausgegeben.
Nachfolgende Schritte sind nötig um ein virtuelles Interface für eine virtuellen Maschine mit dem Namen WINDOWS zu erstellen:
xe vm-list params=uuid name-label=WINDOWS
xe vif-create vm-uuid=uuid network-uuid=uuid device=0
Der Parameter device identifiziert die virtuale Netzwerkschnittstelle (0,1,2,3 usw.). Als Ausgabe wird die UUID des neuen Interfaces auf der Konsole ausgegeben.
Falls die virtuelle Maschine online ist, wird das Interface zwar hinzugefügt bleibt aber bis zum nächsten Restart im Status *unpluged
Um ein virtuelles Interface per „Hotplug“ einer virtuellen Maschine mit dem Namen WINDOWS zu erstellen ist folgendes erforderlich:
xe vif-plug uuid=vif-uuid
Für diesen Schritt müssen die XenTools in der virtuellen Maschine installiert sein.
Die initiale Konfiguration der physischen Netzwerke wird bereits beim Installieren des Servers vorgenommen. Um nachträglich Änderungen an der Netzwerkkonfiguration vorzunehmen, müssen die Network Configuration Files angepasst werden (erfordert Linux Kentnisse).
Ändern sie in der Datei /etc/sysconfig/network den Parameter Hostname.
HOSTNAME=servername
DNS Server sind in der Datei /etc/resolv.conf definiert. Bearbeiten sie diese Datei um diese zu ändern bzw. zu ergänzen.
nameserver=192.168.0.1 nameserver=192.168.0.2
Die Konfiguration von Netzwerkschnittstellen wird in den Konfigurationsdateien unter /etc/sysconfig/network-scripts definiert. Jedes Interface hat seine eigene Konfigurationsdatei mit dem Namen ifcfg-device_name. Jedes physische Interface sowie die verbundenen Linux Bridges haben jeweils eine eigene Konfigurationsdatei. Heißt z.B. das erste physikalische Interface eth0 und die damit verbundene Linux Bridge xenbr0, so sind die Konfigurattionsdateien unter /etc/sysconfig/network-scripts/ifcfg-eth0 und /etc/sysconfig/network-scripts/ifcfg-xenbr0 zu finden.
Bei einem XenServer Host mit mehreren physikalischen Netzwerkschnittstellen, wird nur die Schnittstelle mit einer IP-Adresse konfiguriert die bei der Installation als Management Interface eingestellt wurde. Die Konfiguration der anderen Interfaces ist ebenfalls unter /etc/sysconfig/network-scripts zu finden. Wenn andere Netzwerkschnittstellen benutzt werden sollen, muss in der entsprechenden ifcfg-xenbrX folgendes hinzugefügt werden.
NETMASK=<Netzwerkmaske> IPADDR=<IP-Adresse> GATEWAY=<Gateway IP-Adresse>
Eine Netzwerkschnittstelle, die die Adressinformationen von einem DHCP Server erhält hat natürlich keine IP-Adresse in der Konfigurationsdatei. Hier muss dann der folgende Parameter gesetzt werden.
BOOTPROTO=dhcp
Der Parameter definiert, ob das Interface beim Boot eines XenServer Host aktiviert oder deaktiviert ist.
ONBOOT=no
Beispiel für eine ifcfg-xenbrX mit statischer IP-Adresse.
DEVICE=xenbr1 BOOTPROTO=none ONBOOT=yes TYPE=Bridge NETMASK=255.255.255.0 IPADDR=10.100.2.6 GATEWAY=10.100.2.1 PEERDNS=yes DELAY=0 STP=off
Beispiel für eine ifcfg-xenbrX mit dynamischer IP-Adresse über DHCP.
DEVICE=xenbr1 BOOTPROTO=dhcp ONBOOT=no TYPE=Bridge DELAY=0 STP=off
Um ein Interface zu deaktivieren, können einfach die entsprechenden Konfigurationsdateien gelöscht oder umbenannt werden.
Nach jeder Änderung an den Konfigurationsdateien muss der Netzwerkdienst mit service network restart neu gestartet werden. Zusätzlich sollte noch der Host-Agent mit xe-toolstack-restart neu gestartet werden.
XenServer Hosts in einem Ressource Pool benutzen eine einzige Management IP-Adresse zur Kommunikation miteinander. Dies muss berücksichtigt werden, wenn Änderungen an der IP-Konfiguration innerhalb eines Ressource Pools vorgenommen werden.
Ändern der IP-Adresse eines Slave Servers
Das Ändern der IP-Konfiguration des Master Servers ist ein wenig komplizierter, da alle Slave Server über die bekannte IP-Adresse mit dem Master kommunizieren. Ändert sich die IP-Adresse des Master Servers sind die Slave Server nicht mehr in der Lage mit dem Master Server zu kommunizieren. Wenn es irgendwie möglich ist, sollte man die IP-Adresse des Master Server so wählen, dass sie sich innerhalb des Lebenszyklus eines Pools nicht mehr ändert.
Ändern der IP-Adresse eines Master Servers
Siehe auch 2.6.2 Master Server Fehler
Beim XenServer, ausschließlich in der Enterprise Version, können VLANs optional mit I/O optimierten QoS Einstellungen für besseren Netzwerkdurchsatz (in KB/s) konfigurieren.
Derzeit existieren zwei Parameter um den QoS Algorithmus zu konfigurieren. Der erste lautet qos_algorithm_type und kann zur Zeit nur vom Typ ratelimit sein. Um diese Parameter sinnvoll zu ergänzen, beschreibt der zweite Parameter qos_algorithm_params:kbps den Durchsatz in KB/s.
Das folgende Beispiel limitiert ein virtuelles Interface (VIF) auf eine Transferrate von 100 KB/s.
xe vif-param-set uuid=<VIF UUID> qos_algorithm_type=ratelimit xe vif-param-set uuid=<VIF UUID> qos_algorithm_params:kbps=100
XenServer unterstützt eine Vielzahl von unterschiedlicher Storage Hardware. Die Bezeichnung Storage Repository (SR) bezeichnet eine Storage Hardware, die benutzt wird um virtuelle Disk Images (VDI) zu speichern. Ein VDI ist eine virtuelle Festplatte, die vergleichbar mit einer physischen Festplatte, den virtuellen Maschinen zur Verfügung gestellt wird um Daten zu speichern. XenServer biete eine Schnittstelle um SRs auf einer großen Zahl von Hardware Storage Typen, unter anderem Lokale Festplatten im XenServer (ATA, SCSI, SATA oder SAS), NFS Speicher, Fiber Channel SAN oder auch iSCSI LUNs zu benutzen. Abhängig vom verwendeten Speichersystem werden Features wie Thin Provisioning, VDI Snapshots oder Fast Cloning (siehe 4.1 Eigenschaften von XenServer Storage) unterstützt.
Insgesamt gibt es vier Klassen von Objekten die konfiguriert werden können.
Nachfolgend eine kurze Aufstellung der vom XenServer unterstützten Storage Typen und deren Eigenschaften. Interessant ist die Spalte SR Typ, bei der Konfiguration von Storage Repositories über die CLI wird diese Typ-Bezeichnung verwendet.
| Local | Local | FC | iSCSI (Hardware) | iSCSI (Software) | NFS | NetApp | |
|---|---|---|---|---|---|---|---|
| SR Typ | LVM | EXT | LVMOHBA | LVMOHBA | LVMOISCSI | NFS | NETAPP |
| Virtuelle Maschinen | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| Shared SR | ✔ | ✔ | ✔ | ✔ | ✔ | ||
| Disk Image Rezise | ✔ | ✔ | ✔ | ✔ | ✔ | ||
| Auto VM Platzierung | ✔ | ✔ | ✔ | ✔ | ✔ | ||
| XenMotion | ✔ | ✔ | ✔ | ✔ | ✔ | ||
| Fast Clone | ✔ | ✔ | ✔ | ||||
| Thin Provisioning | ✔ | ✔ | ✔ |
Standardmäßig benutzt der XenServer für die virtuellen Maschinen, Storage auf den lokal installierten Platten über den Linux Logical Volume Manager (LVM). Lokaler LVM Storage ist sehr performant und erlaubt es die virtuellen Festplatten dynamisch zu vergrößern. LVM Storage werden in voller Größe angelegt als ein isoliertes Volume auf dem darunter liegendem Filesystem. Für hochperformante VDIs ist LVM eine gute Wahl, man verzichtet aber auf die Vorteile von File basierten VDIs.
Der XenServer unterstützt aber auch VDIs im Microsoft VHD Format. Dies lässt sich relativ einfach über das CLI konfigurieren. Lokale SRs können, wie der Name schon sagt, nicht gemeinsam in Pools genutzt werden.
NFS basierte Systeme stehen in vielen Umgebungen als Fileserver (Linux sowie Windows) zur Verfügung. Der XenServer ist in der Lage, vorhandene NFS System sofort als SRs für VDIs zu nutzen. Der Vorteil von NFS ist, dass gleich das Microsoft VHD Format verwedet wird. Eine 100 GB große VDI belegt nur soviel Platz auf dem Share wie auch Daten vorhanden sind (bei einer frisch Installierten VM nur ein paar GB für das OS). VHD Files können außerdem verbunden werden (chained) und nutzen dadurch gemeinsame Daten. Beim klonen von virtuellen Maschinen benutzen die geklonten VMs die gemeinsamen Daten und schreiben Änderungen in eine „copy-on-write“ Kopie des VDI. Dieser Vorgan wird als fast cloning / fast provisioning bezeichnet.
Da NFS gerade für solche Operationen diverse Metadaten verwalten muss, ist NFS nicht so performant wie z.B. LVM SR. XenServer setzt bei NFS und VHD Implementierungen die volle Kontrolle über das verwendete SR hat. Manuelle Eingriffe in die File Struktur sollten vermieden werden, da es sonst zu Datenverlusten kommen kann. XenServer kann ohne weiteres mit NFS Systemen auf Linux oder Windows Fileserver zusammen arbeiten. Das Design ist allerdings auf Enterprise NFS Filer ausgelegt, welche über nicht flüchtigen RAM verfügen der schreib- und lese Prozesse verwaltet und gleichzeitig einen hohen Schutz vor Schreibfehlern bietet. XenServer wurde speziell mit einer Vielzahl von Filer der Firma Network Appliance getestet.
Ergänzend zu NFS unterstützt der XenServer auch shared SR's auf iSCSI LUNs, basierend auf dem Open iSCSI Software Initiator. Shared iSCSI SR benutzt LVM und ist vergleichbar mit LVM auf einem lokalen SR. Jeder XenServer wird automatisch mit einer iSCSI Adapter Initiator ID (IQN) konfiguriert. Die IQN wird zufällig erstellt und stellt sicher, das jeder Host eine einzigartige ID erhält. Die iSCSI IQN kann über das XenCenter oder über das CLI geändert werden.
Über das CLI kann die iSCSI IQN wie folgt geändert werden:
xe host-param-set uuid=[HOST_ID] other-config-iscsi_iqn=[NEUE_IQN]
Ändern sie niemals die IQN, wenn noch iSCSI SRs verbunden sind.
Der XenServer unterstützt nur einen iSCSI Adapter. Dieser kann sich jedoch auf mehrere unterschiedliche iSCSI Targets verbinden und die Target IQNs parallel nutzen. Auf dem Host lässt sich nur eine Host Initiator IQN konfigurieren, deshalb muss auf der Target Seite der Zugriff von einer Host IQN auf mehrere Target IQNs konfiguriert werden.
Einige iSCSI Targets unterstützen keine „pro Initiator ACL“. Hier muss sichergestellt werden, dass ein multi-initiator Zugriff möglich ist wenn LUNs von mehr als einem Host im Pool genutzt werden sollen.
XenServer unterstützt CHAP zur User Authentifizierung für Datenpfad Initialisierung sowie LUN Discovery.
XenServer unterstützt Fibre Channel SAN mit Emulex oder QLogic Host Bus Adapter (HBA). Logical Unit Numbers (LUNs) werden von der SAN wie normale physische Platten verbunden (z.B. /dev/sdx). Das CLI zur Konfiguration von HBAs sind unter folgenden Pfaden zu finden:
Bei der Verwendung von „Boot von SAN“ muss sämtlich Konfiguration vor der Installation von XenServer erfolgen. Während der Installation vom XenServer müssen dann nur die entsprechenden LUNs ausgewählt werden. nach Abschluss der Installation bootet der XenServer von der entfernten LUN. Jede FC LUN wird innerhalb des XenServers als SCSI Disk verbunden und erscheinen unter /dev/disks/by_id mit ihrer eindeutigen SCSI ID. Wenn sie sich nicht sicher sind, welche Disk zu welcher SCSI ID gehört können sie sich mit dem Tool sginfo die Verbindungen anzeigen lassen.
sginfo /dev/disk/by_id/ {scsi_id}
Wenn sie nach der Installation eines XenServers einen FC HBA hinzufügen, müssen sie in der Datei /etc/modprobe.conf folgende Zeile hinzufügen.
alias scsi_hostadapter{n} {module_name}
Wobei der Parameter {n} die nächst verfügbare SCSI Hostadapter Nummer angibt und {module_name} den zu benutzenden Modulnamen.
Mehr Informationen zu den unterstützten HBAs finden Sie ind der Hardware Compatibility List.
Grundlage dieses Dokument ist der XenSource - XenServer Administrator’s Guide, Version 4.01 vom 08. Oktober 2007, der hier von mir ins deutsche übersetzt, an die aktuellen Versionen angepasst und mit HowTo's und Hinweisen ergänzt wurde.