Virsh pool-refresh funktioniert nur teilweise

virtualization
german

#1

Hallo,

ich habe unter UCS 2.4-1-2 64Bit ein iSCSI-Storage eingebunden (virsh pool-define iscsi_config.xml).

So sehen die Volumes/LUNs aus:

[code]root@backupsrv:~# virsh vol-list filesrv
Name Path

7.0.0.0 /dev/disk/by-path/ip-192.168.2.22:3260-iscsi-iqn.2000-09.com.fujitsu:storage-system.eternus-dxl:00021eae.10-lun-0
7.0.0.1 /dev/disk/by-path/ip-192.168.2.22:3260-iscsi-iqn.2000-09.com.fujitsu:storage-system.eternus-dxl:00021eae.10-lun-1
[/code]

Auf diesen beiden LUNs (lun-0 und lun-1) läuft bereits eine domU (ebenfalls UCS 2.4-1-2). Hänge ich nun am Storage 2 weitere LUNs dazu, muss ich nur ‘virsh pool-refresh poolname’ ausführen und schon werden mir die neuen LUNs im UCS angezeigt:

[code]root@backupsrv:~# virsh pool-refresh filesrv
Pool filesrv refreshed

root@backupsrv:~# virsh vol-list filesrv --details
Name Path Type Capacity Allocation

7.0.0.0 /dev/disk/by-path/ip-192.168.2.22:3260-iscsi-iqn.2000-09.com.fujitsu:storage-system.eternus-dxl:00021eae.10-lun-0 block 19,53 GB 19,53 GB
7.0.0.1 /dev/disk/by-path/ip-192.168.2.22:3260-iscsi-iqn.2000-09.com.fujitsu:storage-system.eternus-dxl:00021eae.10-lun-1 block 17,58 GB 17,58 GB
7.0.0.2 /dev/disk/by-path/ip-192.168.2.22:3260-iscsi-iqn.2000-09.com.fujitsu:storage-system.eternus-dxl:00021eae.10-lun-2 block 19,53 GB 19,53 GB
7.0.0.3 /dev/disk/by-path/ip-192.168.2.22:3260-iscsi-iqn.2000-09.com.fujitsu:storage-system.eternus-dxl:00021eae.10-lun-3 block 21,48 GB 21,48 GB[/code]

Wie kann ich nun diese beiden neu hinzugefügten LUNs wieder entfernen? Wenn ich die beiden LUNs beim Storage wieder rausnehme und im UCS ein ‘virsh pool-refresh poolname’ ausführe, sind die LUNs im UCS trotzdem noch da. Die Größe steht aber auf 0:

[code]root@backupsrv:~# virsh pool-refresh filesrv
Pool filesrv refreshed

root@backupsrv:~# virsh vol-list filesrv --details
Name Path Type Capacity Allocation

7.0.0.0 /dev/disk/by-path/ip-192.168.2.22:3260-iscsi-iqn.2000-09.com.fujitsu:storage-system.eternus-dxl:00021eae.10-lun-0 block 19,53 GB 19,53 GB
7.0.0.1 /dev/disk/by-path/ip-192.168.2.22:3260-iscsi-iqn.2000-09.com.fujitsu:storage-system.eternus-dxl:00021eae.10-lun-1 block 17,58 GB 17,58 GB
7.0.0.2 /dev/disk/by-path/ip-192.168.2.22:3260-iscsi-iqn.2000-09.com.fujitsu:storage-system.eternus-dxl:00021eae.10-lun-2 block 0,00 0,00
7.0.0.3 /dev/disk/by-path/ip-192.168.2.22:3260-iscsi-iqn.2000-09.com.fujitsu:storage-system.eternus-dxl:00021eae.10-lun-3 block 0,00 0,00 [/code]

Erst wenn ich ein ‘virsh pool-destroy poolname’ und danach ‘virsh pool-start poolname’ ausführe, sind die beiden LUNs weg. Problem dabei: ich muss die domU, welche auf lun-0 und lun-1 läuft zuerst herunterfahren -> erst dann kann ich ein destroy ausführen!

Hinweis: lun-2 und lun-3 wurden dazwischen nicht gemountet!

Vielen Dank!

mfg
Daniel


#2

Hallo,

Storage-Pool dienen primär dazu einen Überblick über verfügbare Speicherbereiche zu haben und geben libvirt die Möglichkeit (in Abhängigkeit von der Storage-Pool Art) auch neue Images anzulegen.

Das die Storage-Pools mit einem pool-refresh aktualisiert werden müssen ist grundsätzlich ein normales und korrektes Verhalten. Das bei einem iSCSI Storage-Pool die entfernten LUNs nach einem Refresh nicht entfernt scheint eine Besonderheit des iSCSI-Storage zu sein. Unabhängig davon müsste aber ein pool-destroy möglich sein ohne die Maschinen herunterzufahren, da dies nur die Verbindung vom libvirt-Dienst zum iSCSI-Storage trennt. Was passiert wenn Sie ein pool-destroy aufrufen? Gibt es dann eine Fehlermeldung?

Mit freundlichen Grüßen
Andreas Büsching


#3

Hallo,

ein pool-destroy kann ich schon aufrufen, nur steht dann meine domU (wegen E/A-Fehlern) -> muss ja auch so sein, da ich meine root-Partition auf dem Storage laufen habe, welches via iSCSI angebunden ist. Wenn ich diese Verbindung kappe, ist es so als reiße ich im die Festplatte unter den Füßen weg.

Ich verstehe nur nicht, warum es in die eine Richtung geht und in die andere nicht. D. h. wenn ich beim Storage LUNs hinzufüge und ein pool-refresh aufrufe, werden die neuen LUNs gleich erkannt. Wenn ich nun aber beim Storage LUNs wegnehme und ein pool-refresh aufrufen, bleiben die LUNs im UCS erhalten.

mfg
Daniel


#4

Hallo,

Eine Recherche hat ergeben, dass es sich hierbei um ein spezifisches Verhalten von open-iscsi handelt. Beim Refresh des Pools (iscsiadm -m session -r <SID> --rescan) werden zwar neue LUNs hinzugefügt, aber keine entfernt. Das wird mit Funktionsweisen vom sysfs SCSI-Subsystem begründet. Auf der open-iscsi Mailingliste wurde das bereits diskutiert.

[quote=“open-iscsi Documentation”]
Note: Rescanning does not delete old LUNs. It will only pick up new ones.[/quote]

Wird diese Fähigkeit dringend benötigt?

Mit freundlichen Grüßen
Andreas Büsching


#5

Hallo,

in unserem Fall wäre es für die Migration einer domU (von einem XEN-Wirt zum nächsten) wünschenswert.

Beispiel:
es gibt 2 Virtualisierungsserver auf welchen unterschiedliche domUs laufen. Diese Server greifen via iSCSI auf 1 Storage zu (Fujitsu Eternus DX60/80). Auf diesem Storage befinden sich sämtliche Festplatten der domUs.
Möchte man nun Zwecks optimaler Lastverteilung zwischen den beiden Server eine domU von einem Server zum anderen verschieben/migrieren, ist solch ein Aus- und Einhängen der LUNs notwendig. Für solch eine Migration möchte man natürlich nicht immer alle domUs herunterfahren, bevor man die LUNs aushängt.

Fällt Ihnen dazu irgendein Workaround ein?

Vielen Dank!

Gruß,
Daniel


#6

Hallo,

[quote=“sinteam”]
Fällt Ihnen dazu irgendein Workaround ein?[/quote]

Da wir in diesem Bereich noch keine Erfahrung haben, kann ich Ihnen mit einem Workaround nicht behilflich sein. Sollten Sie hier Erfahrungen sammeln wären wir sehr an einem Bericht interessiert.

Mit freundlichen Grüßen
Andreas Büsching