UCS 2.4-1 iSCSI-Implementierung nicht möglich (virsh)

virtualization
german

#1

Hallo,

versuche nun schon eine Weile, ein iSCSI-Storage in eine UCS 2.4-1 dom0 einzubinden.
Dazu habe ich auch eine passende Doku gefunden: wiki.univention.de/index.php?tit … erbereiche

Nur leider kommt beim Ausführen des Befehls “virsh pool-start iscsi” der Fehler, dass /usr/bin/iscsiadm nicht gefunden werden kann.

In der Doku steht leider nicht, dass davor noch etwas installiert werden muss -> gibt es hierzu ein passendes UCS-Paket?? Ehrlich gesagt möchte ich kein Debian-Paket installieren, da es dann wieder irgendwo zu Problemen bei den Updates kommt.

Bitte um eine rasche Antwort, da ich mitten in einem Testaufbau stecke und der Beginn des Kundenprojekt ansteht.

Vielen Dank!

Mit besten Grüßen,
Ing. Daniel Anthofer


Fujitsu Eternus per iSCSI an UCS2.4
#2

Hallo,

hier muss das Paket “open-iscsi” installiert sein (verfügbar im unmaintained Bereich von UCS 2.3). Wir werden den Wiki-Artikel entsprechend ergänzen.

Mit freundlichen Grüßen
Janis Meybohm


#3

Hallo,

vielen Dank für die rasche Antwort!
Bekommen wir da beim nächsten Update Probleme, wenn wir Pakete aus dem unmaintained Bereich nutzen?

Danke.
Mit besten Grüßen,
Ing. Daniel Anthofer


#4

Hallo,

wo finde ich dieses open-iscsi-Paket genau?

mfg
Daniel


#5

Hallo,

für die unmaintained Pakete liefern wir derzeit keine Security-Updates oder Hotfixes, außerdem werden Sie bei Release-Updates nicht berücksichtigt weshalb wir Probleme bei zukünftigen Updates nicht ausschließen können.
Generell empfehlen wir die unmaintained Repositorys lediglich für die Installation einzelner Pakete zu aktivieren und für die Release-Updates abzuschalten um zu verhindern das ungewollt weitere Updates aus dem unmaintained-Repository installiert werden.
Nach einem Update ist dann allerdings manuell zu prüfen ob die unmaintained Pakete noch installiert sind (ggf. wurden Sie wegen fehlender Abhängigkeiten deinstalliert) bzw. ob sie aktualisiert werden müssen.

Das Paket open-iscsi (sowie eventuelle Abhängigkeiten) werden wir allerdings in das nächste Major oder Minor Release von UCS aufnehmen sodass das Paket dann aus dem maintained Bereich bezogen werden kann.

apt.univention.de/2.3/unmaintain … 4_i386.deb
apt.univention.de/2.3/unmaintain … _amd64.deb

Mit freundlichen Grüßen
Janis Meybohm


#6

Hallo,

gab es mit iSCSI und UVMM schon Tests oder sogar Projekte? Ich stelle mir gerade die Frage, wie ich das Projekt von Grund auf am Besten aufbauen soll.

Beim aktuellen Projekt greifen 2 physische Server auf ein Fujitsu Eternus DX60 zu (siehe Bild im Anhang). Die Images der virtuellen Maschinen sollen auf dem Eternus laufen, so dass die virtuelle Maschine im Notfall auf den anderen Server umgeschaltet werden kann.

Soll ich nun das Eternus via iSCSI als eigene Platte in die beiden dom0 einbinden und darauf die Images ablegen, oder wäre es besser einzelne iSCSI-Luns direkt in UVMM als Festplatte anzugeben?

Ich möchte für dieses Projekt ein optimales Konzept ausarbeiten. Wäre es möglich, dass wir dieses Thema einmal am Telefon besprechen?

Vielen Dank schon mal!

mfg
Daniel


#7

Hallo,

soweit mir bekannt ist gab es interne Tests aus denen dann der bereits erwähnte Wiki-Artikel entstanden ist.

Um die Instanzen zwischen zwei Servern migrieren zu können ist es notwendig dass beide Dom-0 Systeme schreibend auf die Instanz zugreifen können. Dies ist vermutlich ein einfachsten und ungefährlichsten zu realisieren wenn eine LUN (oder eine Partition auf der LUN) pro Instanz vergeben wird. Bei zentralen Partitionen mit Disk-Images ist es vermutlich schwieriger konkurrierende Schreibzugriffe zu verwenden.

Wenn Sie Unterstützung bei der Projektplanung wünschen, würde ich Sie bitten sich an Ihren vertrieblichen Ansprechpartner zu wenden.

Mit freundlichen Grüßen
Janis Meybohm


#8

Hallo,

das Einbinden eines iSCSI-Storages funktionierte so weit einmal. Wenn ich das Storage nun als Festplatte für eine VM angebe, lässt sich diese nicht starten -> es wird ein Fehler angezeigt (siehe Bild im Anhang).

Ich bin folgendermaßen vorgegangen:

  • iSCSI Target und LUN am Storage angelegt
  • passende zarafa.xml erstellt
  • “virsh pool-define zarafa.xml” ausgeführt
  • “virsh pool-start zarafa” ausgeführt
    -> das iSCSI-Storage wurde eingebunden und konnte mit fdisk angezeigt werden -> auch der Zugriff ist möglich

Im UVMM bin ich folgendermaßen vorgegangen:

  • virtuelle Maschine angelegt
  • Neues Laufwerk hinzufügen > Festplatte > Auswahl einer vorhandenen Image-Datei > Speicherbereich: zarafa > Laufwerk: das vorhandene LUN
  • die Festplatte wird nun bei der VM unter Laufwerke angezeigt

Beim Start der VM kommt der Fehler (wie anfangs beschrieben).

Wie im Wiki beschrieben wurde auch schon mit “virsh edit instanz” die VM-Konfiguration angepasst -> hier hab ich nur den driver von block auf phy geändert. Mit dieser Einstellung lässt sich zwar die VM starten, bleibt aber dann beim Suchen der Festplatte hängen.

Wo liegt das Problem? Kann ich das Laufwerk irgendwie anders einbinden, so dass es funktioniert?

Vielen Dank!

mfg
Daniel


#9

Hallo,

[quote=“sinteam”]Wo liegt das Problem? Kann ich das Laufwerk irgendwie anders einbinden, so dass es funktioniert?
[/quote]

Können Sie bitte einmal die vollständige XML-Beschreibung der Instanz sowie des Pools schicken (virsh dumpxml instanz; virsh pool-dumpxml zarafa)?

Mit freundlichen Grüßen
Andreas Büsching


#10

Hallo,

mit der angehängten Konfiguration (driver name wurde in der xml von “block” auf “phy” geändert) lässt sich die VM zwar starten, jedoch bleibt sie dann beim Suchen der Laufwerke hängen (siehe Bild).



zarafasrv_instanz.xml (1.29 KB)
zarafa_pool.xml (496 Bytes)


#11

Die Konfiguration für den Pool sieht korrekt aus. Kann virsh auf die Liste der vorhandenen LUNs zugreifen?

virsh vol-list zarafa --details

In der Konfiguration der Instanz ist zu sehen, dass die Festplatte nicht als paravirtualisiertes Gerät eingebunden wird. Da es eine paravirtualisierte Instanz ist würde ich hier als Test vorschlagen die disk Konfiguration einmal mit virsh wie folgt anzupassen:

Die Zeile

<target dev='sda' bus='scsi'/>

durch die Zeile

<target dev='xvda' bus='xen'/>

ersetzen.

Mit freundlichen Grüßen
Andreas Büsching


#12

Hallo,

ich habe nun ein paar Tests durchgeführt und konnte dabei folgendes feststellen:

Wenn ich im UVMM eine Festplatte aus dem iSCSI-Pool hinzufüge, sieht das in der Domain-Config so aus:

Mit dieser Konfiguration kommt beim Starten der VM der bereits genannte Fehler mit dem block device.
Wenn ich nun den driver name von block nach phy ändere, lässt sich die VM starten (auch ohne Anpassung des Targets) und die Festplatte wird erkannt (ohne Timeout von Xenbus beim Starten via UCS ISO-Image).

Wenn ich via UVMM eine zweite Festplatte hinzufüge und den driver name wieder auf phy anpasse, lässt sich die VM zwar starten, bleibt aber dann wieder beim Xenbus hängen und im UCS-Setup werden die Festplatten dann auch nicht erkannt.
Habe nun auch schon versucht, die Festplatten händisch via virsh attach-disk einzuhängen -> leider gleiches Verhalten.

Sobald ich es mit dem target dev=‘xvda’ bus=‘xen’ versuche, werden die Platten auch nicht erkannt (auch nicht, wenn nur eine Festplatte eingehängt wurde).

Welche Szenarien wurden von Eurer Seite bereits probiert/getestet?

Leider habe ich dazu im Internet auch nichts Besonderes gefunden!? Vielleicht liegt es ja hierbei nicht mal an der xen-domain sondern am UCS-CDROM-Bootvorgang (dass hierbei vielleicht die Festplatten nicht erkannt werden!?).

Ich versuch mal mit einer Boot-CD.

mfg
Daniel


#13

Also wie es aussieht, gibt es beim Booten mit der UCS24 Probleme, wenn 2 Festplatten angegeben werden (vermutlich irgendwo beim Xenbus).

Wenn ich das Gleiche mit einem Ubuntu probiere, gibt es keine Probleme -> die beiden Festplatten werden im Setup sofort erkannt (habe in der domain-xml auch wieder nur von block auf phy umgestellt).

Bitte um Prüfung des Problems.

mfg
Daniel


#14

[quote=“sinteam”]Also wie es aussieht, gibt es beim Booten mit der UCS24 Probleme, wenn 2 Festplatten angegeben werden (vermutlich irgendwo beim Xenbus).

Wenn ich das Gleiche mit einem Ubuntu probiere, gibt es keine Probleme -> die beiden Festplatten werden im Setup sofort erkannt (habe in der domain-xml auch wieder nur von block auf phy umgestellt).[/quote]

Bei verschiedenen Tests haben wir auch schon selber festgestellt, daß es bei Xen Probleme gibt, wenn Laufwerke vom Typ “block” mit Laufwerken vom Typ “file” innerhalb einer VM gemischt benutzt werden.
Für CDROMs hat folgender Trick geholfen, der die Datei mit dem ISO-Image per Hand in ein Block-Device umwandelt:

[code]# Freies Loop-Back-Device finden
losetup -f → /dev/loop0

ISO-Image an dieses Loop-Back-Device binden

losetup /dev/loop0 /var/lib/libvirt/images/ucs_2.4-0-latest-i386.iso

Konfiguration per Hand anpassen:

virsh edit “$VM”












[/code]

Das Binden des ISO-Images an das Loop-Back-Device ist nicht permanent und geht durch ein Reboot verloren, ist also keine dauerhafte Lösung. Die Probleme standen häufig damit im Zusammenhang, das durch die Verwendung von PyGrub das Laufwerk zwischen dem extrahieren des Kernels aus dem Laufwerk und dem eigentlichen Start der virtuellen Maschine gelöst wurde, so daß dieses dann nicht mehr gefunden wird.

Mit freundlichen Grüßen
P. Hahn

PS: Das Problem des fehlerhaften -Eintrags wird mit UCS-2.4-2 behoben sein. Außerdem wird die auf dem Loop-Back-Device basierende Lösung durch Block-Tap-2 abgelöst werden.


#15

Hallo,

habe nun alle devices auf block device umgestellt und die UCS-Installation läuft soweit (es werden beide Platten erkannt).

neues Problem: nachdem ich die VM gestartet habe, verschwindet sie aus dem UVMM (egal ob ich sie via UVMM oder mit “virsh start” starte). Nach einem Reboot vom dom0 scheint die domU im UVMM wieder auf (solange sie nicht gestartet wurde).

mfg
Daniel


#16

Hallo,

[quote=“sinteam”]
neues Problem: nachdem ich die VM gestartet habe, verschwindet sie aus dem UVMM (egal ob ich sie via UVMM oder mit “virsh start” starte). Nach einem Reboot vom dom0 scheint die domU im UVMM wieder auf (solange sie nicht gestartet wurde).[/quote]

Was heisst in diesem Fall genau “verschwindet im UVMM”? Ist die Instanz im UMC Modul nicht mehr zu sehen? Wird sie bei einem der folgenden Kommandos noch angezeigt?

virsh list --all
virsh -c xen://$(hostname -f)/ list --all

Mit freundlichen Grüßen
Andreas Büsching


#17

Hallo,

die Instanz ist im UVMM nicht mehr zu sehen (siehe Screenshot). Nur der erste Befehl zeigt die Instanz.

mfg




#18

Hallo,

Hierbei handelt es sich um ein bekanntes Problem, welches nicht die virtuelle Instanz ansich betrifft sonndern ausschließlich das Managementsystem UVMM. Dies ist eine Unzulänglichkeit in dem libvirt-Dienst. Mit UCS 2.4-2 wird eine verbesserte Version des Dienstes ausgeliefert mit der dieses Problem nicht mehr auftreten sollte.

Um dies in UCS Versionen vor 2.4-2 zu korrigieren, können Sie den libvirt-Dienst einmal neustarten:

invoke-rc.d univention-virtual-machine-manager-node-common restart

Anschließend kann es ein paar Sekunden dauern bis die Instanz im UVMM-Modul wieder angezeigt wird.

Mit freundlichen Grüßen
Andreas Büsching


#19

Danke für den Tip.

Welchen Target-Typ (im xml der Instanz) würden Sie empfehlen? xen oder scsi?

mfg
Daniel


#20

hallo,

In dem Bereich haben wir mit dem Bus scsi noch keine Erfahrungen. Bei einer paravirtualisierten Instanz würde in UVMM in der Vorgabe der Bus Xen verwendet werden. Ich würde hier empfehlen die beiden Varianten einmal durchzutesten.

Mit freundlichen Grüßen
Andreas Büsching