In einem XEN-Cluster können nur bestimmte HW-Komponenten miteinander in einem Pool betrieben werden

CPU: Laut Compatability List von XEN können i.d.R. CPUs eines Herstellers (z.B. Intel → z.B. IBM Server X3630M4: XEON E5-2407 v2, 4,2GHz, x3650M3: Xeon E5645 2,4 GHz und x3650: XEON E5405 2 GHz) zusammen in einem Pool arbeiten. Einschränkungen gibt es für die älteren CPUs, da diese z.B. das CPU-Masking nicht unterstützen. Ein Server mit älterer CPU kann dennoch auf der Konsole dem Pool hinzugefügt werden (force), ggf. kann keine live migration einer VM durchgeführt werden.

Strategie: Server mit neuester CPU ist Pool-Master. Server mit älteren CPUs werden später hinzugefügt und das Masking für die CPU, muss dann so eingestellt werden, dass die neueren Server, das Masking der älteren CPUs erhalten.

Es sind 2 GB pro Server für das XEN OS selbst einzuplanen. Hinzu kommt der Speicher für die auf dem Server zu betreibenden VMs. Ein Server sollte soviel Speicher haben, dass ggf. alle VMs hierauf konsolidiert werden könnten (im Fehlerfall).

Alle Server sollten mit gleich vielen Netzwerkkarten bestückt sein, die alle identisch zu konfigurieren sind.

Beispiel: Server verfügen über 1-2 eingebaute 1GB NICs, 1x Intel Quad NIC und 1x QLogic iSCSI HBA → es können pro Server also 5 Netzwerkkarten zugeordnet und 1xiSCSI HBA genutzt werden.

Hinweis: In einem Resource Pools ist die NIC-Abfolge gleich zu wählen, da die Netzwerkeinstellungen für alle Server gleich gesetzt werden - ggf. kann die Reihenfolge der NICs manuell auf der Konsole gesetzt werden.

XEN unterstützt das Einrichten von LACP Bonds (Link Aggregation Control Protocol - 802.3ad). Ziel ist es, mehrere Netzwerkkarten zu einem Link zusammenzufassen, so dass mehr Bandbreite für die Übertragung zur Verfügung steht. Hierbei muss der LACP einmal auf Seite des XEN-Servers (pro Server) eingerichtet werden (z.B. drei NIcs werden zu einem Bond zusammengefasst), dann müssen alle gewünschten VLANs auf dem Server unter XEN definiert werden und die UUID des BONDS den jeweiligen VLANs zugeordnet werden. Die VLANs können dann, den einzelnen NICs in den VMs zugeordnet werden. Als Gegenstück dird die gleiche Anzahl an Ports auf dem Switch benötigt, die ebenfalls als Bond zu konfigurieren sind und als Trunk (also untagged) definiert sein müssen. So erreicht man eine sehr hohe Flexibilität.

Alle Server im Pool müssen über CPUs mit identischem Hersteller verfügen. Zudem sollten die CPUs auf der HCL von XEN stehen. Der neueste Server mit der aktuellsten CPU übernimmt die Rolle des Pool Masters. In einem Pool muss die Netzwerkkonfiguration und die Zahl und Bezeichnung der Netzwerkkarten pro Server identisch sein. Sollte letzteres nicht der Fall sein, so kann die Reihenfolge der Netzwerkkarten unter XEN umbenannt und ggf. NICs deaktiviert werden. Zudem muss die sog. Feature List der CPUs übereinstimmen. In einem heterogenen Pool ist dies nicht der Fall. Daher müssen alle CPUs bei den Servern mit neueren CPUs ein sog. CPU-Masking erhalten, das die eigenen CPU Features denen der ältesten CPU anpasst. Gemäß Citrix handelt es sich hierbei um einen sog. Typ 2 Pool. Auf dem Master wird also die Maskierung für die älteren CPUs eingetragen und der Server neu gestartet. Danach können die Server mit den älteren CPUs dem Pool hinzugefügt werden. Für alle Server muss ein identisches CPU-Masking bzw. Feature List eingestellt sein. Weiter Hinweise finden sich unter: Heterogene Resource Pools XEN