IT security, FreeBSD, Linux, mail server hardening, post-quantum crypto, DNS, retro computing & hands-on hardware hacks. Privater Tech-Blog seit 2003.

Schlagwort: Citrix

Citrix XenServer: Festplattenpriorität im Storage-Pool konfigurieren​

Veraltet: Citrix XenServer wird seit 2024 nicht mehr in dieser Form angeboten. Die Storage-Pool-Konfiguration hat sich grundlegend geändert. Alternativen: Proxmox VE oder XCP-ng.

Hat man in seinem Citrix XenServer mehrere virtuelle Festplatte in einem Storage liegen, kann es vorkommen dass man einzelnen davon eine höhere Priorität zuweisen möchte als anderen.

Leider gibt es diese Option nicht klickbar im Citrix XenCenter, sondern man muss die Konsole (CLI) bemühen.

Das Einstellen dieser Prioritäten ist etwas komplexer, ich beschränke mich in meinem Beispiel auf die „schnell und einfach“ Version. Damit möchte ich sagen, bitte selbst damit beschäftigen.

Zum Thema… Es gibt verschiedene Algorithmen, welche man für sein QOS der virtuellen Festplatten wählen kann. Ich nehme gerne ionice, da es bei mehreren Systemen eher um IO-Probleme als reine Durchsatzprobleme geht. Diesem Algorithmus gebe ich die Information mit das es hier um realtime geht und die Klasse in welche die virtuelle Festplatte gesteckt werden soll. Bei der Klassifizierung ist zu beachten, dass es ein ganzzahliger Wert zwischen 0 und 7 sein muss. Die Klasse 0 hat dabei die höchste Priorität und die Klasse 7 die geringste.

Kleines Beispiel gefällig?

Wir sind auf der root Konsole des XenServers. Ich lasse mir die VMs mit ihren Platten anzeigen, in diesem Fall gibt es keine Snapshots. Würde es welche geben, gleiches Vorgehen, es sieht nur etwas „unübersichtlicher“ aus.

[root@fra.srv.ha.xen.05 ~]# xe vbd-list
uuid ( RO)             : 66a3903c-8eba-4d8a-92d9-c435d399d3ac
          vm-uuid ( RO): 577e39d4-e771-477b-8829-8648b05b682b
    vm-name-label ( RO): VM-Kennzeichnung
         vdi-uuid ( RO): <not in database>
            empty ( RO): true
           device ( RO):

uuid ( RO)             : 4e004302-c32e-4c90-b986-9efc0b1995a1
          vm-uuid ( RO): 577e39d4-e771-477b-8829-8648b05b682b
    vm-name-label ( RO): Laufwerkskennzeichnung
         vdi-uuid ( RO): 47e5ab14-9cf8-4e7f-88b8-fe20247efa85
            empty ( RO): false
           device ( RO): xvdb

uuid ( RO)             : 5b4f70ec-07cb-47a5-aa05-91647cf38b78
          vm-uuid ( RO): 577e39d4-e771-477b-8829-8648b05b682b
    vm-name-label ( RO): Laufwerkskennzeichnung
         vdi-uuid ( RO): e6796376-995f-4a99-8ba6-893c30aa6a14
            empty ( RO): false
           device ( RO): xvda

Zu erkennen ist ein System (577e39d4-e771-477b-8829-8648b05b682b) mit zwei virtuellen Festplatten (4e004302-c32e-4c90-b986-9efc0b1995a1 / 5b4f70ec-07cb-47a5-aa05-91647cf38b78).

Versorgt mit diesen Informationen kann ich nun direkt die beiden Platten mit neuer Priorität versehen.

$ xe vbd-param-set uuid=4e004302-c32e-4c90-b986-9efc0b1995a1 qos_algorithm_type=ionice
$ xe vbd-param-set uuid=4e004302-c32e-4c90-b986-9efc0b1995a1 qos_algorithm_paramsched=rt
$ xe vbd-param-set uuid=4e004302-c32e-4c90-b986-9efc0b1995a1 qos_algorithm_params:class=5

$ xe vbd-param-set uuid=5b4f70ec-07cb-47a5-aa05-91647cf38b78 qos_algorithm_type=ionice
$ xe vbd-param-set uuid=5b4f70ec-07cb-47a5-aa05-91647cf38b78 qos_algorithm_paramsched=rt
$ xe vbd-param-set uuid=5b4f70ec-07cb-47a5-aa05-91647cf38b78 qos_algorithm_params:class=5

Als Test lasse ich mir nun noch einmal die gesetzten Einstellungen auf der Konsole ausgeben. Einmal den gewählten QOS-Algorithmus und dann dessen gesetzte Optionen.

$ xe vbd-param-get uuid=5b4f70ec-07cb-47a5-aa05-91647cf38b78 param-name=qos_algorithm_type
ionice
$ xe vbd-param-get uuid=5b4f70ec-07cb-47a5-aa05-91647cf38b78 param-name=qos_algorithm_params
class: 5; sched: rt

Noch Fragen? Dann fragen…

 

Citrix XenServer Updates manuell über Bash installieren

Veraltet: Citrix XenServer wird seit 2024 nicht mehr in dieser Form angeboten. Das hier beschriebene manuelle Update-Verfahren gilt für XenServer 6.x/7.x und funktioniert mit aktuellen Versionen nicht mehr. Alternativen: Proxmox VE oder XCP-ng.

Der Citrix XenServer 6.2 ist zwar nun frei, Updates lassen sich aber nicht so einfach über das XenCenter installieren. Sie werden einem zwar noch angezeigt (so weiß man zumindest welche man installieren sollte) aber einfach durchklicken ist nicht mehr.

Über die Konsole ist es denn noch schnell erledigt, wie ich hier kurz beschreiben möchte! Um die Installation per Kommandozeile zu zeigen nehme ich folgenden Patch als Beispiel: Hotfix XS61E013 – For XenServer 6.1.0 Nun aber los zur commandline action…

Zuerst den jeweiligen Patch von support.citrix.com herunterladen.

$ wget http://support.citrix.com/servlet/KbServlet/download/33649-102-705213/XS61E013.zip

Dann das Zipfile auspacken:

$ unzip XS61E013.zip
Archive:  XS61E013.zip
  inflating: XS61E013.xsupdate       
  inflating: XS61E013-src-pkgs.tar.bz2
Als nächstes das xsupdate File auf den Server kopieren:
$ scp XS61E013.xsupdate root@10.8.4.66:/update/
XS61E013.xsupdate                                                                                                                      100% 1678KB   1.6MB/s   1.6MB/s   00:00
/update/ ist dabei ein Verzeichnis auf dem Citrix XenServer, welches ich zuvor angelegt habe.

Nun auf dem XenServer als root anmelden und in das passende Verzeichnis wechseln:

$ ssh root@10.8.4.66
Last login: Wed Apr  2 17:32:12 2014 from 10.33.45.21

XenServer dom0 configuration is tuned for maximum performance and reliability.

Configuration changes which are not explicitly documented or approved by Citrix
Technical Support, may not have been tested and are therefore not supported. In
addition, configuration changes may not persist after installation of a hotfix
or upgrade, and could also cause a hotfix or upgrade to fail.

Third party tools, which require modification to dom0 configuration, or
installation into dom0, may cease to function correctly after upgrade or hotfix
installation. Please consult Citrix Technical Support for advice regarding
specific tools.

Type "xsconsole" for access to the management console.
[root@dom0-sdb35 ~]# cd /update
[root@dom0-sdb35 update]# 

Ich schaue nun gerne immer zuerst welche Patches bereits installiert wurden:

[root@dom0-sdb35 update]# xe patch-list
uuid ( RO)                    : 7fd1ba20-1582-4b02-a61d-c251ad0b637c
              name-label ( RO): XS61E001
        name-description ( RO): Public Availability: fix for ISCSI multipathing
                    size ( RO): 862376
                   hosts (SRO): 427c6c42-a193-4740-8ed7-c664b5ace02c
    after-apply-guidance (SRO):

uuid ( RO)                    : c5354c77-4643-4e79-8cdf-fac914fc6c85
              name-label ( RO): XS61E003
        name-description ( RO): Public Availability: Xapi fixes
                    size ( RO): 6631433
                   hosts (SRO): 427c6c42-a193-4740-8ed7-c664b5ace02c
    after-apply-guidance (SRO): restartXAPI

uuid ( RO)

Wie man sehen kann sind auch bereits Patches eingespielt, was daran zu erkennen ist das sie dem host „zugewiesen“ sind. Um nun zuerst den gerade kopieren Patch in die Liste zu packen reicht folgender Befehl:

[root@dom0-sdb35 update]# xe patch-upload file-name=XS61E013.xsupdate
55aa7129-a5ff-4e90-899b-f89248d1182e
Und noch kontrollieren ob er in der Liste ist:
[root@dom0-sdb35 update]# xe patch-list
uuid ( RO)                    : 55aa7129-a5ff-4e90-899b-f89248d1182e
              name-label ( RO): XS61E013
        name-description ( RO): Public Availability: security fixes to Xen and xenstored
                    size ( RO): 1717976
                   hosts (SRO):
    after-apply-guidance (SRO): restartHost

Perfekt… Nun kann der Patch schon eingespielt werden. Dabei ist immer der Punkt: after-apply-guidance (SRO): zu beachten. In diesem Fall restartHost. Also am besten vorher brav alle VMs abschalten, Patch wie noch folgt einspielen und die Kiste einmal durchstarten.

[root@dom0-sdb35 update]# xe patch-apply uuid=55aa7129-a5ff-4e90-899b-f89248d1182e host-uuid=427c6c42-a193-4740-8ed7-c664b5ace02c
Preparing...                ##################################################
xen-hypervisor              ##################################################
Preparing...                ##################################################
xen-tools                   ##################################################

Etwas aufwendiger als mit dem XenCenter, denn noch gut und problemlos machbar! Ist der Patch eingespielt kann die Patch-Datei natürlich wieder vom Server gelöscht werden. Wenn sein Server direkt ins Internet darf, kann man ebenfalls direkt auf der Kiste den wget ausführen. Auf was man aber immer achten sollte ist der freie Plattenplatz. Denn wenn man so viele Updates auf die Kiste legt das dem dom0 plötzlich ein Platz mehr bleibt… Tja, dann hat man andere Probleme.

Noch Fragen?

Siehe auch: Citrix XenServer local storage größer >2TB, XenServer mit Nagios überwachen, XenServer Linux Softwareraid, Local ISO Repository

Citrix XenServer Kernel Module automatisch beim Booten starten

Veraltet: Citrix XenServer wird seit 2024 nicht mehr in dieser Form angeboten. Alternativen: Proxmox VE oder XCP-ng.

Möchte man bei seinem Citrix Xen Server bestimmte Kernelmodule automatisch beim Booten laden, hilft folgendes.

Einfach unter /etc/sysconfig/modules/ ein passendes Konfigurationsfile für das Module anlegen und es ausführbar machen. Ich habe hier ein Beispiel für die IPMI Module:

$ echo "modprobe ipmi_si" > /etc/sysconfig/modules/ipmi_si.modules
$ echo "modprobe ipmi_devintf" > /etc/sysconfig/modules/ipmi_devintf.modules
$ chmod +x /etc/sysconfig/modules/ipmi_si.modules
$ chmod +x /etc/sysconfig/modules/ipmi_devintf.modules

 Schon werden die beiden Module ipmi_si und ipmi_devintf beim Boot des Servers geladen!

Siehe auch: Citrix XenServer Updates manuell über Bash installieren, Citrix XenServer: VM fährt nicht herunter – Force Shutdown erzwingen

Citrix XenServer: VM fährt nicht herunter – Force Shutdown erzwingen

Veraltet: Citrix XenServer wird seit 2024 nicht mehr in dieser Form angeboten. Alternativen: Proxmox VE oder XCP-ng.

Hin und wieder bleibt beim Herunterfahren eine VM irgendwie hängen. Dann hat man über das XenCenter keine Möglichkeit mehr diese VM zum Leben zu erwecken. Damit man nun nicht den kompletten VM-Host dom0 neustarten muss, kann man erst folgenden Weg probieren.

Als erstes kann man einen force shutdown der vm probieren:

$ xe vm-shutdown –force vm=“VM-NAME“

Wenn es nicht hilft, kann man versuchen die “wartenden” pending Prozesse am XenServer zu killen:

$ xe task-list

 Dann die Prozesse abbrechen welche den Shutdown zu verhindern scheinen:

$ xe task-cancel uuid=“TASK-UUID“

 Bringt das alles nichts kann man als letztes noch folgendes probieren:

$ xe-toolstack-restart

 Nun kann man noch einmal einen force shutdown probieren. Klappt es auch nicht, muss man wohl doch den VM-Host durchstarten!

Siehe auch: Citrix XenServer Updates manuell über Bash installieren, Citrix XenServer Kernel Module automatisch beim Booten starten

Citrix XenServer local storage größer >2TB

Veraltet: Citrix XenServer wird seit 2024 nicht mehr in dieser Form angeboten. Die Storage-Konfiguration hat sich grundlegend geändert. Alternativen: Proxmox VE oder XCP-ng.

Hat man in seinem Citrix XenServer eine Festplatte welche größer ist als 2 Terabyte, egal ob logisch durch RAID oder physikalisch als echte Hardware. So wird diese vom XenServer nicht vollständig genutzt. Das liegt daran, dass der XenServer noch aufs alte Pferd MBR setzt. Der eingesetzte Kernel kann aber bereits mit GUID Partition Table (GPT) partitionierten Speichern umgehen. Alleine die mitgelieferten Boardmittel (fdisk….) können es auch nicht. Zusammengefasst bedeutet es: –    Ich kann am Citrix XenServer einen lokalen Speicher der größer ist als 2TB einbinden und benutzen. –    Ich kann diesen Speicher aber nicht anlegen 🙁 Damit wäre also nur das Problem des Anlegens zu lösen! Voraussetzung ist dass es sich dabei um eine weitere HDD handelt, also nicht die Platte auf welcher das eigentliche Hostsystem Dom0 installiert wurde. Diesen weitern Speicher schraubt man nun also in seinen XenServer. Nun bootet man diesen mit der Hilfe von Parted Magic. Dieses Livesystem ist darauf ausgelegt mit Platten und Partitionen umzugehen. Daher ist es selbst kein Problem auf ein bereits eingerichtetes Linux Sofwareraid zuzugreifen und es bringt das Programm gparted mit. Gparted wird nun die Hauptarbeit übernehmen, denn es ist schon länger in der Lage GUID Partition Tables (GPT) anzulegen.   Festhalten, es geht los… –    gparted öffnen –    den >2TB Datenspeicher auswählen Cirtix Xen Server local Storage lokaler Speicher bigger 2TB groesser 2TB GUID GPT –    über den Menüpunkt Device den Unterpunkt Create Partition Table auswählen  Cirtix Xen Server local Storage lokaler Speicher bigger 2TB groesser 2TB GUID GPT –    unter Advanced den Type der neuen Partitionstabelle auf gpt setzten und (Warnung beachten) anwenden –    den neuen unallocated Speicher markieren Cirtix Xen Server local Storage lokaler Speicher bigger 2TB groesser 2TB GUID GPT –    über den Menüpunkt Partition den Unterpunkt New auswählen Cirtix Xen Server local Storage lokaler Speicher bigger 2TB groesser 2TB GUID GPT –    nun den File system Type auf lvm2 pv setzten und Hinzufügen Cirtix Xen Server local Storage lokaler Speicher bigger 2TB groesser 2TB GUID GPT –    Abschließend noch diese Änderungen anwenden über den Button Apply Jetzt haben wir eine GUID Partitionstabelle auf der großen Festplatte mit einer Partition größer 2TB und diese bereits mit dem Dateisystem Logical Volume Manager (LVM). Nun können wir wieder den Citrix XenServer booten und ihn mit seinem neuen 3TB oder 4TB oder was weiß ich Storage bekannt machen. Nachdem der XenServer hochgefahren ist melden wir uns als Root auf der Shell an. Um den Speicher nutzbar zu machen genügen nun zwei kleine Befehle:
$ pvcreate /dev/sda1
$ xe sr-create type=lvm content-type=user device-config:device=/dev/sda1 name-label="4TB-SPEICHER"
 Ab jetzt ist der Store wie jeder andere nutzbar.
* U-P-D-A-T-E * Zusammen mit gdisk lassen sich nun auch GPT Partitionen anlegen.

Siehe auch: Citrix XenServer Updates manuell über Bash installieren, XenServer mit Nagios überwachen, XenServer Linux Softwareraid

XenServer mit Nagios überwachen

Veraltet: Citrix XenServer wird seit 2024 nicht mehr in dieser Form angeboten. Die hier beschriebene Nagios-Überwachung bezieht sich auf XenServer 6.x/7.x. Wer heute Virtualisierung überwachen will, sollte sich Proxmox VE oder XCP-ng anschauen.

Das folgende habe ich auf den Citrix XenServer in Version 5.6SP2 bis 6.2.0 anwenden können.
Im Grunde geht es darum auf dem „freien“ Citrix XenServer nrpe (Nagios Remote Plugin Executor) zu installieren um diesen mit Nagios auf einfache Weise überwachen zu können. Natürlich bietet der Cirtix XenServer ebenfalls die Möglichkeit ihn per SNMP zu überwachen und diese Version zu zu bevorzugen…. Für das eine oder andere Script ist die Ausführung per nrpe denn noch einfacher und schneller umzusetzen, als per snmp. Denn noch bitte beachten… Diese Version ist zwar absolut funktionsfähig und fast gefahrlos für das System, denn noch ist es „hereingefummelt“ und muss nach Versionsupgrade wieder (passend für die jeweilige Version) eingespielt werden. Die eigentliche Nagiosanbindung soll hier nicht Thema sein. Beispiele dazu kann man gerne bei mir erfragen.

So dann wollen wir mal:

Ich habe eine -schlechte- Angewohnheit. Ich erstelle immer gerne im Root das Verzeichnis 001 um dort meine Daten „herum zu würfeln“.

$ mkdir /001
$ cd /001

Im Grunde basiert der Citrix XenServer auf Redhat Linux/Fedora… Also können wir für diesen Fall auch die (Extra Packages for Enterprise Linux) epel nutzen.

$ wget http://dl.fedoraproject.org/pub/epel/5/x86_64/epel-release-5-4.noarch.rpm
$ rpm -hiv epel-release-5-4.noarch.rpm
$ sed -i 's/enabled=1/enabled=0/g' /etc/yum.repos.d/epel.repo

So und schon sollten wir die zusätzlichen Pakete nutzen können. In diesen findet sich sinnigerweise auch direkt nrpe, was wir gleich installieren:

$ yum install --enablerepo=epel nrpe
$ chkconfig nrpe on

Das chkconfig nrpe on sorgt dafür dass der Service direkt beim Start des Systems mitgestartet wird. Wichtig ist nun noch die passenden Löcher in die Firewall des XenServers zu schießen. Sonst läuft zwar der Dienst, wir bekommen von außen aber keine Verbindung. Hier muss nur in der folgenden Datei eine Zeile ergänzt werden:

$ nano -w /etc/sysconfig/iptables
…..
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 5666 -j ACCEPT
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
COMMIT
….

Damit wären wir schon feritg. Natürlich sollte man nun noch die Nagios Plugins installieren, Programme und Temperaturen von Festplatten oder IPMI auszulesen.

$ yum install --enablerepo=epel nagios-plugins hddtemp ….

Für IPMI (Intelligent Platform Management Interface) müssen ggf. noch die nötigen Kernelmodule geladen werden:

$ modprobe ipmi_devintf
$ modprobe ipmi_si

Konfigurieren lässt sich nrpe nun wie bekannt über:

$ nano -w /etc/nagios/nrpe.cfg

Die Konfiguration von nrpe und Nagios ist aber unabhängig von der Installation auf dem XenServer.


Ich habe gerade den Hinweis bekommen, dass es helfen könnte wenn ich hier erwähne dass man sich die Nagios Plugins noch zusätzlich installieren muss. Dieses Stimmt natürlich. Ich habe mir mit der Zeit einen Satz recht weit „angepasste“ Nagios Plugins zusammengestellt. Diese schiebe ich mir oft (unter Berücksichtigung der Abhängigkeiten) einfach passend hin und her kopiere. Vielleicht ein Grund warum ich das -vergessen- habe zu erwähnen.


Siehe auch: Citrix XenServer Updates manuell über Bash installieren, Citrix XenServer local storage größer >2TB, XenServer Linux Softwareraid

XenServer Linux Softwareraid

Veraltet: Citrix XenServer wird seit 2024 nicht mehr in dieser Form angeboten. XenServer 8 hat ein anderes Lizenzmodell, Software-RAID wird dort anders gehandhabt. Alternativen: Proxmox VE oder XCP-ng.

Wer die Freie Version des Citrix XenServers einsetzt hat in den meisten Fällen seine virtuellen Maschinen im Local Storage liegen. Natürlich hat ein Hardwareraid für diesen Speicherplatz Vorteile, aber er hat auch Nachteile.
Wie man hier dem XenServer nun einen Local Storage auf der Basis eine Softwarraids unterschieben kann, darum geht es hier!

Alle nötigen Schritte lassen sich direkt auf der Konsole des XenServers ausführen und ist vollständig mit Boardmitteln realisierbar. Die Konfiguration überlebt auch jegliche Updates/Upgrades von der Citrix XenServer Version 5.6 bis 6.1.0.

Wir gehen nun mal davon aus, eine 60GB SSD als Systemplatte für den eigentlichen Citrix XenServer zu haben und ein Softwareraid Level 5 aus drei Festplatten bauen zu wollen.
Damit hätten wir folgende Konfiguration:

/dev/sda    =>    Systemplatte
/dev/sdb    =>    Erste Festplatte RAID
/dev/sdc    =>    Zweite Festplatte RAID
/dev/sdd    =>    Dritte Festplatte RAID

Die für das Softwareraid vorgesehenen Festplatten sollten natürlich keine Daten enthalten und keine Informationen im MBR (Master Boot Record) haben. Diesen löschen wir also zur Sicherheit mit:

$ dd if=/dev/zero of=/dev/sdb bs=1 count=1024
$ dd if=/dev/zero of=/dev/sdc bs=1 count=1024
$ dd if=/dev/zero of=/dev/sdd bs=1 count=1024

Auf den drei Festplatten muss anschließend jeweils eine neue Partition angelegt werden. Diese Partition muss vom Type FD (Linux Raid Autodetect) sein.

$ fdisk /dev/sd[b,c,d]
N => neue Partition
T => Type setzten => FD
W => neue Partitionstabelle auf Platte schreiben
Q => fdisk beenden

Mit diesen vorbereiteten Platten kann nun das eigentliche Softwarraid erstellt werden:

$ mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1

Nun heißt es warten bis das Resilvering durchgelaufen ist. Wie weit es fortgeschritten ist lässt sich so beobachten:

$ watch –n 1 'cat /proc/mdstat'

Natürlich können wir jetzt schon auf das neue Softwareraid Laufwerk zugreifen. Ein Reboot sollte man aber erst nach dem ersten korrekten Resilvering durchführen.

Damit nun der Citrix XenServer Kenntnis von diesem neuen Speicherplatz erzählt, müssen wir es ihm noch „schmackhaft“ machen!
Zuerst legen wir auf diesem neuen Laufwerk nun eine Partition vom Type 8E (Linux LVM) an:

$ fdisk /dev/md0
N => neue Partition
T => Type setzten => 8E
W => neue Partitionstabelle auf Platte schreiben
Q => fdisk beenden

Wunderbar. Dann schieben wir es mal dem XenServer unter:

$ mdadm --examine --scan > /etc/mdadm.conf
$ pvcreate /dev/md0p1
$ xe sr-create type=lvm content-type=user device-config:device=/dev/md0p1 name-label="RAID-5"

Fertig…. Nun kann man schon im XenCenter den neuen lokalen Speicher RAID-5 finden und nutzen.

Citrix XenCenter management console showing software RAID

Es ist auch möglich dem Citrix XenServer einen lokalen Storage auf dieser Basis unter zu schiebe, der größer ist als 2TB. Dieses geht leider nicht mehr ganz mit Boardmitteln, da fdisk einfach die nötige Struktur nicht mehr anlegen kann. Der eingesetzte Kernel kann es aber sehr wohl ansprechen und verwalten. Hierzu schreibe ich sich später noch mal was..


* U-P-D-A-T-E *

Zusammen mit gdisk lassen sich nun auch GPT Partitionen anlegen.

Siehe auch: Citrix XenServer Updates manuell über Bash installieren, Citrix XenServer local storage größer >2TB, XenServer mit Nagios überwachen

Local ISO Repository

Veraltet: OpenIndiana und Solaris werden kaum noch eingesetzt. Lokale Paketquellen lassen sich unter FreeBSD mit poudriere und unter Linux mit apt-mirror oder createrepo einrichten.

Citrix XenServer und local ISO Repository

Man kann zwar über das „klickbunit“ Interface XenCenter für seinen einzelnen XenServer neue ISO libarays anlegen, diese können dann leider nur auf einem Windows File Shareing (CIFDS) oder NFS ISO Share liegen. Klar, man könnte nun eine VM auf dem XenServer installieren und dort einen solchen Share anlegen. oder eine Kiste neben den Server stellen, welcher die ISOs vorhält. In größeren Umgebungen kein Problem… Im „Kleinen“ schon mal nervig.

Ich habe für mich eine einfache Lösung gefunden. Ich schraube einfach eine weitere kleine Platte in den Server, lege dort die für mich wichtigen ISOs ab und baue mir eine lokale ISO library. So habe ich die nötigen ISOs immer auf der Kiste, selbst wenn alles andere aus sein sollte.

Also lokalen Speicherplatz für die ISOs habe ich an eine 160GB SATA Platte von WD gedacht. Diese wird nicht gespiegelt oder ähnliches, da die ISO Files für mich erstmal keinen Wert haben. Brennt die Platte wirklich ab, kopiere ich die ISO Files halt auf eine neue.

Nach dem Einbau ist die WD Platte in meinem System als /dev/sde zu finden. Als erstes werde ich nun auf ihr eine primäre Patrion vom Type 83 (Linux) anlegen:

$ fdisk /dev/sde

The number of cylinders for this disk is set to 19457.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
   (e.g., DOS FDISK, OS/2 FDISK)

Command (m for help):

Die Hilfe zu fdisk kann sicher jeder selbst lesen… Ich schaue als erstes über p nach ob ich wirklich auf der richtigen Platte bin, denn p listet mir die Partitionen auf der Platte auf. Dann erstell ich mit n ==> p ==> 1 eine neue primäre Partition und schreibe am Ende alles mit w auf die Platte. q beendet als letztes fdisk.

Nun muss ich die neue Partition noch formatieren. Als Dateisystem finde ich ext3 ganz passend:

$ mkfs.ext3 -L ISO-Store /dev/sde1
mke2fs 1.39 (29-May-2006)
Filesystem label=ISO-Store
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
19546112 inodes, 39072080 blocks
1953604 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
1193 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
Superblock backups stored on blocks:
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
    4096000, 7962624, 11239424, 20480000, 23887872

Writing inode tables: done                            
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 26 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

Nun erstelle ich einen Mountpoint unter welchem ich die Platte einbinden möchte:

$ mkdir /ISOs

Schon kann ich die Platte mounten:

$ mount /dev/sde1 /ISOs

Noch schnell eine kontrolle ob alles dort ist wo es hin soll:

$ mount|grep ISO
/dev/sde1 on /ISOs type ext3 (rw)

Mit einem Eintrag in die fstab (ich muss immer aufpassen nicht vfstab zu schreiben) sorge ich nun dafür dass die neue Platte bei jedem Start des Servers wieder eingebunden wird.

$ vi /etc/fstab

und dann folgende Zeile einfügen:

/dev/sde1    /ISOs    ext3    defaults    0 0

Jetzt kommt das wirklich spannende. XEN die neue Platte als localen ISO Speicher schmackhaft zu machen:

$ xe sr-create name-label=ISOs type=iso device-config:legacy_mode=true device-config:location=/ISOs content-type=iso
00da02b3-8b46-bade-6d00-e109e262ede9

Schaut doch schon gut aus, oder? Dann lassen wir uns mal die neue ISO library anzeigen:

$ xe sr-list uuid=00da02b3-8b46-bade-6d00-e109e262ede9
uuid ( RO)                : 00da02b3-8b46-bade-6d00-e109e262ede9
          name-label ( RW): ISOs
    name-description ( RW):
                host ( RO): xenserver01-kernel-error.local
                type ( RO): iso
        content-type ( RO): iso

Warum auch immer, wird die Platte bei mir an diesem Punkt immer ausgehangen. Ich könnte es jetzt einfach wieder mounten und nutzen, würde denn noch vorschlagen hier den Server selbst einmal zu rebooten. So kann man gleich sehen ob die Platte wieder richtig eingebunden wird. Nach dem Reboot schaue ich also nach ob die Platte wieder richtig eingehangen wurde:

$ mount|grep ISO/dev/sde1 on /ISOs type ext3 (rw)

Jetzt kopiere ich das nötige ISO auf die Platte:

scp WindowsSvrStd2008R2.iso root@10.44.2.88:/ISOs
WindowsSvrStd2008R2. 100% |******************************************************************************************************************************************************************************************|  3052 MB    01:28

Im XenCenter sollte man nun schon das neue SR mit dem Namen „ISOs“ sehen. Klicke man nun am Reiter Storage auf Rescan wird das hochgeladene ISO gefunden und kann verwendet werden. Ich muss nun also nur noch alle meine ISOs dort hochschieben und fertig ist!

Citrix XenCenter SR local ISO library

Siehe auch: Citrix XenServer Updates manuell über Bash installieren, Citrix XenServer local storage größer >2TB, XenServer mit Nagios überwachen, XenServer Linux Softwareraid

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑