Probleme beim Einbinden vom Storage

[dhruser]

Liebe Kollegen,

ich versuche gerade mein Storage Qnap TS-859U+ mit aktuellster FW Version 4.03 in meine VMWare Umgebung (ESXi 5.0) einzubinden.

Vorn weg: Ich weiß wie man einbindet, alles kein Problem.Hatte das Storage früher (mit älterer FW) unter ESX 4.1 betrieben, alles ohne Probleme...

Wenn ich jetzt im vSphere Client unter Configuration - Storage Adapters - Properties - Dynamic Discovery die IP von der Qnap hinzufüge mit Port 3260 sehe ich auch direkt danach unter Static Discovery die 4 LUNs schon.

Vsphere schlägt ein Rescan aller Storages vor (wie üblich). Wenn ich dann aber unter dem Punkt Storage - Add a LUN klicke bleibt hier die Auswahl leer...

Für meinen Geschmack ist die Storage im ersten Schritt schon halb eingebunden. Der zweite ausbleibende Schritt tut aber nicht. Kann sich wer denken wieso? Wo kann ich troubleshooten? Auch ein Reboot des ESX Hosts brachte nichts...

Besten Dank im voraus!!!

[dhruser]

Kleine Ergänzung zum Troubleshooten aus der VMkernel.log Datei:

Code: Alles auswählen

2014-04-02T15:18:25.580Z cpu11:9947)WARNING: UserLinux: 1340: unsupported: (void)
2014-04-02T15:20:04.104Z cpu10:2058)NMP: nmp_ThrottleLogForDevice:2318: Cmd 0x1a (0x4124007b88c0, 0) to dev "mpx.vmhba1:C0:T0:L0" on path "vmhba1:C0:T0:L0" Failed: H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x20 0x0. Act:NONE
2014-04-02T15:20:04.104Z cpu10:2058)ScsiDeviceIO: 2324: Cmd(0x4124007b88c0) 0x1a, CmdSN 0x286f from world 0 to dev "mpx.vmhba1:C0:T0:L0" failed H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x20 0x0.
2014-04-02T15:20:04.169Z cpu10:2058)NMP: nmp_ThrottleLogForDevice:2318: Cmd 0x1a (0x4124007b88c0, 0) to dev "t10.DP______BACKPLANE000000" on path "vmhba0:C0:T32:L0" Failed: H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x20 0x0. Act:NONE
2014-04-02T15:20:04.169Z cpu10:2058)ScsiDeviceIO: 2324: Cmd(0x4124007b88c0) 0x1a, CmdSN 0x2871 from world 0 to dev "t10.DP______BACKPLANE000000" failed H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x20 0x0.
2014-04-02T15:20:12.195Z cpu4:5238)<3>ata1.00: bad CDB len=16, scsi_op=0x9e, max=12
2014-04-02T15:20:12.271Z cpu4:5238)<3>ata1.00: bad CDB len=16, scsi_op=0x9e, max=12
2014-04-02T15:20:12.294Z cpu8:5238)Vol3: 647: Couldn't read volume header from control: Invalid handle
2014-04-02T15:20:12.294Z cpu8:5238)FSS: 4330: No FS driver claimed device 'control': Not supported
2014-04-02T15:20:12.295Z cpu8:5238)<3>ata1.00: bad CDB len=16, scsi_op=0x9e, max=12
2014-04-02T15:20:12.302Z cpu8:5238)<3>ata1.00: bad CDB len=16, scsi_op=0x9e, max=12
2014-04-02T15:20:12.304Z cpu8:5238)<3>ata1.00: bad CDB len=16, scsi_op=0x9e, max=12
2014-04-02T15:20:12.307Z cpu8:5238)<3>ata1.00: bad CDB len=16, scsi_op=0x9e, max=12
2014-04-02T15:20:12.311Z cpu8:5238)FSS: 4330: No FS driver claimed device 'mpx.vmhba1:C0:T0:L0': Not supported
2014-04-02T15:20:12.380Z cpu8:5238)VC: 1449: Device rescan time 96 msec (total number of devices 11)
2014-04-02T15:20:12.380Z cpu8:5238)VC: 1452: Filesystem probe time 32 msec (devices probed 6 of 11)
2014-04-02T15:21:19.136Z cpu10:5238)<3>ata1.00: bad CDB len=16, scsi_op=0x9e, max=12
2014-04-02T15:21:19.181Z cpu1:5238)<3>ata1.00: bad CDB len=16, scsi_op=0x9e, max=12
2014-04-02T15:21:19.198Z cpu1:5238)Vol3: 647: Couldn't read volume header from control: Invalid handle
2014-04-02T15:21:19.198Z cpu1:5238)FSS: 4330: No FS driver claimed device 'control': Not supported
2014-04-02T15:21:19.199Z cpu1:5238)<3>ata1.00: bad CDB len=16, scsi_op=0x9e, max=12
2014-04-02T15:21:19.206Z cpu3:5238)<3>ata1.00: bad CDB len=16, scsi_op=0x9e, max=12
2014-04-02T15:21:19.208Z cpu5:5238)<3>ata1.00: bad CDB len=16, scsi_op=0x9e, max=12
2014-04-02T15:21:19.211Z cpu5:5238)<3>ata1.00: bad CDB len=16, scsi_op=0x9e, max=12
2014-04-02T15:21:19.215Z cpu5:5238)FSS: 4330: No FS driver claimed device 'mpx.vmhba1:C0:T0:L0': Not supported
2014-04-02T15:21:19.229Z cpu1:5238)VC: 1449: Device rescan time 55 msec (total number of devices 11)
2014-04-02T15:21:19.229Z cpu1:5238)VC: 1452: Filesystem probe time 29 msec (devices probed 6 of 11)


Möglicherweise hilft das weiter...

[dhruser]

Nach Firmware Update auf der QNAP sieht die Logfile nun so aus:

Code: Alles auswählen

2014-04-02T22:58:02.579Z cpu1:5147)NetPort: 1237: enabled port 0x100000a with mac 00:50:56:b5:0b:e7
2014-04-02T22:58:02.587Z cpu1:5152)CBT: 1082: Created device 1b223b-cbt for cbt driver with filehandle 1778235
2014-04-02T22:58:02.588Z cpu1:5152)VSCSI: 3683: handle 8209(vscsi0:0):Creating Virtual Device for world 5147 (FSS handle 893503)
2014-04-02T22:59:45.718Z cpu6:2054)ScsiDeviceIO: 1198: Device naa.6842b2b00066c5dc000003a54d1980ee performance has improved. I/O latency reduced from 15299 microseconds to 3788 microseconds.
2014-04-02T23:00:06.974Z cpu11:2087)<6>bnx2 0000:01:00.1: vmnic1: RX NetQ allocated on 1
2014-04-02T23:00:06.975Z cpu11:2087)<6>bnx2 0000:01:00.1: vmnic1: NetQ set RX Filter: 1 [00:50:56:b5:13:3f 0]
2014-04-02T23:01:01.976Z cpu0:2087)<6>bnx2 0000:01:00.1: vmnic1: NetQ remove RX filter: 1
2014-04-02T23:01:01.976Z cpu0:2087)<6>bnx2 0000:01:00.1: vmnic1: Free NetQ RX Queue 1
2014-04-02T23:01:16.976Z cpu9:2087)<6>bnx2 0000:01:00.1: vmnic1: RX NetQ allocated on 1
2014-04-02T23:01:16.976Z cpu9:2087)<6>bnx2 0000:01:00.1: vmnic1: NetQ set RX Filter: 1 [00:50:56:b5:13:3f 0]
2014-04-02T23:01:21.977Z cpu2:2087)<6>bnx2 0000:01:00.1: vmnic1: NetQ remove RX filter: 1
2014-04-02T23:01:21.977Z cpu2:2087)<6>bnx2 0000:01:00.1: vmnic1: Free NetQ RX Queue 1
2014-04-03T06:49:39.657Z cpu10:50346)WARNING: UserObj: 675: Failed to crossdup fd 8, /dev/ptyp0 type CHAR: Busy


Scheint ja ein kompliziertes Problem zu sein, wenn niemand helfen kann ;-(

[Supi_Du]

Nuja, die VMWARE HCL für das Teil sprich nur von ESXI 4.1 und FW 3.3.

Also eher eine unsupported Umgebung. Das ist häufig das Problem bei NAS Systemen. 1x mit FW X unter Vmware Y zertifiziert und dann wird immer mit geworben.
Das es dann mit aktuelleren FW und ESXI Versionen Probleme gibt, ist dem Marketing erst mal egal.

Versuche doch mal das NAS per NFS einzubinden und nich per ISCSI. Das ist häufiger problemloser.

[kastlr]

Hallo,

liegt vielleicht auch daran, das die Log Snippets nicht wirklich was hergeben.

Über welchen vnhba versuchst du denn den Storage zu erreichen?
In deinen Snippets erscheinen nur die vmhba's 0 und 1, damit werden üblicherweise interne Komponenten wie ATA oder SCSI Kontroller benannt.
Sofern du diese vmhba's nicht zum Zugriff auf deinen externen Storage verwendest haben die Meldung wahrscheinlich nichts mit deinem Problem zu tun.

Gruß,
Ralf

[dhruser]

Hallo Jungs,

eure Tipps waren Gold wert, besonders der von Supi_Du.
NFS scheint auf den ersten Blick zu funktionieren, ich bin sehr froh! Werde das weiter testen und es auch wissen lassen!!!!

vielen Dank erstmal!! Melde mich wieder falls noch was offen ist!

[Supi_Du]

Das kennst du sicher alles schon und es brachte nix?

http://files.qnap.com/news/pressresourc ... _above.pdf
http://www.viktorious.nl/2013/11/20/qnap-vsphere55/

http://qnapsupport.net/?page_id=930

Try not to use jumbo frame in Network configuration. Set the MTU to 1500 instead of 9000.
DisableNetwork Port Trunking
Use specific network speed instead of auto-negotiation in TCP/IP setting.
Try to assign a specific NIC for iSCSI service.

Edit: Ok, gut wen es jetzt funktioniert. zum NFS vielleicht noch folgender Link:
https://communities.vmware.com/thread/4 ... 5&tstart=0
Also aufpassen, bei den verwendeten NIC's.

[UrsDerBär]

Wenn das NAS als Backup verwendet wird, wäre mir NFS eh sympathischer. --> VMFS-Dateisystem auf SoHo-NAS ohne gscheite Stromversorgung ist immer eine Zeitbombe.

[dhruser]

Hi Leude,

ich nochmal. Also ich habe zwar geschrieben, das ich die Storage per NFS zum laufen kriegte, aber das stimmt wohl nur so halb.

Wenn ich eine VM drauf migrieren will, kommt nach kurzer Zeit (bei 2%, Cannot Access Storage...) lauter Fehlermeldungen....

Meine Frage ist nun, welche Logdateien ziehe ich am besten zum Troubleshooten zu Rate?

[kastlr]

Hallo,

die vmkernel Logs zum Zeitpunkt einer fehlgeschlagenen Migration.

Gruß,
Ralf

[rprengel]

Hi Leude,

ich nochmal. Also ich habe zwar geschrieben, das ich die Storage per NFS zum laufen kriegte, aber das stimmt wohl nur so halb.

Wenn ich eine VM drauf migrieren will, kommt nach kurzer Zeit (bei 2%, Cannot Access Storage...) lauter Fehlermeldungen....

Meine Frage ist nun, welche Logdateien ziehe ich am besten zum Troubleshooten zu Rate?

Hallo,

setzt dir mal ein Testlinux auf einem PC auf und mounte das NFS. Danach mal mal reichlich Dateien in allen Grössen kopieren und schauen ob ähnliche Probleme auftauchen.
Wenn ja hast du erst mal auf dem Zielsystem oder im Netzwerk ein Thema.
NFS kann sehr unspezifische Probleme verursachen. Deshalb mein Vorschlag per Ausschlussverfahren zu klären wo man suchen sollte.

Gruss

[dhruser]

HI,
ich habe seit eben heraugefunden wo das Problem ist, aber noch keine Lösung

Wenn ich beim NFS Security Filter in der Storage IP Addressen konfiguriere welche das NFS share mounten können, tauchen Probleme beim Zugriff auf. Wenn ich als Filter ein * setze (alles darf zugreifen) läuft es 1a.

Die einzige offene Frage ist demnach:
Welche IPs erwartet die Storage das es sicher funktioniert.

Ich habe bereits die IPs von:
- ESXi Server
- Vmotion
- iScsi
- Dell Storage (Mgmt Ports, und transfer ports)

als zugriffsberechtigt gelistet. Das ist schon fast das ganze Subnetz. Ich weiß nicht was die Storage sonst noch von mir will...

Kann die NFS ja nicht für alle Welt aufmachen

[dhruser]

sodele, VMWare Subnetz freigegeben für NFS und gut ist...

Hoffentlich

[UrsDerBär]

Für NFS erstelle ich jeweils nen eigenen Vmkernel-Port in einem eigenen VLAN. So gibts sicher keine Kollisionen mit anderen Dingen.
Mir hat eine kleine Fehlkonfig mal die komplette SAN iSCSI-Geschichte lahmgelegt. Nur weil sich NFS und iSCSI irgendwie gar nicht riechen konnten. Seither nur noch getrennt.