!SOLVED! Hilfe: Datastores verschwunden Pfade aber noch vorh

[Login]

Hallo,

bei einem Kunden ist seit heute morgen ein ESX aus einem DRS Cluster krank:

Angefangen hat es damit, dass die VMs des betroffenen Hosts extrem träge wurden und teilweise für ein paar Momente gar nicht mehr pingbar waren. Auf den anderen Host migriert, ist wieder alles normal.

Auf dem kranken Host sehe ich aktuell alle Pfade zum iSCSI Storage wie immer redundant und aktiv(i/o). Die Datastores bekomme ich nur nicht mehr zu sehen! Lediglich den localDatastore des ESX.

Der Host wurde mehrfach neu gestartet und jetzt auch auf den aktuellen Patchlevel aktualisiert.

Wenn ich einen neuen Datastore erstellen will, wird mir keine LUN angezeigt, da ja bereits alle formatiert sind.

Fehler konnte ich keine finden.

Was kann das sein???

Gruß,
Conne

[Tschoergez]

Schau ins vmkernel-log!
Da sollten während des Rescans genaue meldungen zur Ursache drinstehen.

Wurd am zoning oder auf dem Storage-System was verändert?

[Login]

nein, es wurde nichts verändert! der verbliebene Host arbeitet wie immer!

Logs sehe ich gleich mal ein und poste, falls es was gibt.

[Login]

event.vprob.storage.connectivity.lost.fullFormat (vprob.storage.connectivity.lost)
Fehler
24.08.2011 17:59:44


Steht im Ereignis-Tab des hosts und kommt seit den neustarts von heute.

Welches der anderen Logs ist hier das interessante?

Gruß,
Conne

[Login]

[2011-08-24 15:57:01.206 631EFB90 info 'TaskManager'] Task Created : haTask-ha-host-vim.host.StorageSystem.rescanVmfs-1936617788
[2011-08-24 15:57:01.207 631EFB90 verbose 'Hostsvc::DatastoreSystem'] ReconcileVMFSDatastores called: refresh = true, rescan = true
[2011-08-24 15:57:01.207 631EFB90 verbose 'FSVolumeProvider'] RefreshVMFSVolumes called
[2011-08-24 15:57:01.207 631EFB90 verbose 'FSVolumeProvider'] RescanVmfs called
[2011-08-24 15:57:07.197 63471B90 verbose 'Locale'] Default resource used for 'vprob.storage.connectivity.lost.fullFormat' expected in module 'event'.
[2011-08-24 15:57:18.519 63271B90 verbose 'StorageSystem'] StoragePathUpdate Refresh --: [N11HostdCommon25VmkernelUpdateStoragePathE:0x6365b100] timestamp=1314201438518923 updated=0x63327378
[2011-08-24 15:57:18.519 63271B90 verbose 'StorageSystem'] SendStorageInfoEvent() called
[2011-08-24 15:57:18.548 63271B90 verbose 'StorageSystem'] StoragePathUpdate: Path state change event generated Storage related Notifications
[2011-08-24 15:57:18.548 63271B90 verbose 'StorageSystem'] StoragePathUpdate Refresh --: [N11HostdCommon25VmkernelUpdateStoragePathE:0x63708940] timestamp=1314201438519212 updated=0x6367f810
[2011-08-24 15:57:18.575 634B2B90 info 'App'] CreateISCSIHBA
[2011-08-24 15:57:18.594 634B2B90 warning 'App'] IP properties discovery failure on iSCSI HBA: iqn.1998-01.com.vmware:TK-ESX-02-252bc1ef: Check vmkernel tcp/ip settings for network properties for sw iscsi
[2011-08-24 15:57:19.283 634B2B90 verbose 'App'] CreateDurableName: Header length field exceeds actual payload
[2011-08-24 15:57:19.332 634B2B90 verbose 'App'] CreateDurableName: Header length field exceeds actual payload
[2011-08-24 15:57:19.380 634B2B90 verbose 'App'] CreateDurableName: Header length field exceeds actual payload
[2011-08-24 15:57:20.826 12E46B90 verbose 'Locale'] Default resource used for 'vprob.storage.redundancy.lost.fullFormat' expected in module 'event'.
[2011-08-24 15:57:21.528 12E46B90 verbose 'Locale'] Default resource used for 'vprob.storage.redundancy.lost.fullFormat' expected in module 'event'.
[2011-08-24 15:57:23.318 63471B90 verbose 'Locale'] Default resource used for 'vprob.storage.redundancy.lost.fullFormat' expected in module 'event'.
[2011-08-24 15:57:24.655 12EC8B90 verbose 'Locale'] Default resource used for 'vprob.storage.connectivity.lost.fullFormat' expected in module 'event'.
[2011-08-24 15:57:31.379 12E87B90 verbose 'Cimsvc'] Ticket issued for CIMOM version 1.0, user root
[2011-08-24 15:57:56.300 12E87B90 verbose 'ResourcePool ha-root-pool'] Root pool capacity changed from 11404MHz/5617MB to 11404MHz/5616MB
[2011-08-24 15:58:03.316 634B2B90 verbose 'App'] CreateDurableName: Header length field exceeds actual payload
[2011-08-24 15:58:08.856 632B2B90 info 'ha-eventmgr'] Event 24 : Lost path redundancy to storage device naa.600d02310006cf81000000005753a7ac. Path vmhba38:C1:T0:L0 is down. Affected datastores: Unknown.
[2011-08-24 15:58:08.856 634B2B90 verbose 'App'] CreateDurableName: Header length field exceeds actual payload
[2011-08-24 15:58:08.916 12EC8B90 info 'ha-eventmgr'] Event 25 : Lost path redundancy to storage device naa.600d02310006cf810000000079af7520. Path vmhba38:C1:T0:L1 is down. Affected datastores: Unknown.
[2011-08-24 15:58:08.917 63471B90 info 'ha-eventmgr'] Event 26 : Lost path redundancy to storage device naa.600d02310006cf810000000179af7520. Path vmhba38:C1:T0:L2 is down. Affected datastores: Unknown.
[2011-08-24 15:58:08.918 632F3B90 info 'ha-eventmgr'] Event 27 : Lost path redundancy to storage device naa.600d02310006cf810000000079af7520. Path vmhba38:C2:T1:L1 is down. Affected datastores: Unknown.
[2011-08-24 15:58:08.919 632B2B90 info 'ha-eventmgr'] Event 28 : Lost path redundancy to storage device naa.600d02310006cf810000000179af7520. Path vmhba38:C2:T1:L2 is down. Affected datastores: Unknown.
[2011-08-24 15:58:08.920 632F3B90 info 'ha-eventmgr'] Event 29 : Lost path redundancy to storage device naa.600d02310006cf81000000005753a7ac. Path vmhba38:C2:T1:L0 is down. Affected datastores: Unknown.
[2011-08-24 15:58:08.941 63271B90 verbose 'StorageSystem'] SendStorageInfoEvent() called
[2011-08-24 15:58:08.942 63271B90 verbose 'StorageSystem'] StoragePathUpdate: Path state change event generated Storage related Notifications
[2011-08-24 15:58:08.942 63271B90 verbose 'StorageSystem'] StoragePathUpdate Refresh --: [N11HostdCommon25VmkernelUpdateStoragePathE:0x63333d58] timestamp=1314201438519407 updated=0x636981e8
[2011-08-24 15:58:08.942 63271B90 verbose 'StorageSystem'] StoragePathUpdate Refresh --: [N11HostdCommon25VmkernelUpdateStoragePathE:0x63c70f00] timestamp=1314201487855369 updated=0x63c706c8
[2011-08-24 15:58:08.942 63271B90 verbose 'StorageSystem'] StoragePathUpdate Refresh --: [N11HostdCommon25VmkernelUpdateStoragePathE:0x63936258] timestamp=1314201487855604 updated=0x63940368
[2011-08-24 15:58:08.942 63271B90 verbose 'StorageSystem'] StoragePathUpdate Refresh --: [N11HostdCommon25VmkernelUpdateStoragePathE:0x637677d8] timestamp=1314201487857634 updated=0x6331dbe8
[2011-08-24 15:58:08.942 63271B90 verbose 'StorageSystem'] StoragePathUpdate Refresh --: [N11HostdCommon25VmkernelUpdateStoragePathE:0x6361ecc8] timestamp=1314201487857807 updated=0x6361fbf8
[2011-08-24 15:58:08.942 63271B90 verbose 'StorageSystem'] StoragePathUpdate Refresh --: [N11HostdCommon25VmkernelUpdateStoragePathE:0xf2131c0] timestamp=1314201487860028 updated=0xf1e54d0
[2011-08-24 15:58:08.942 63271B90 verbose 'StorageSystem'] StoragePathUpdate Refresh --: [N11HostdCommon25VmkernelUpdateStoragePathE:0x63c22c80] timestamp=1314201487860242 updated=0x63c57808
[2011-08-24 15:58:08.969 634B2B90 info 'App'] CreateISCSIHBA
[2011-08-24 15:58:08.990 634B2B90 warning 'App'] IP properties discovery failure on iSCSI HBA: iqn.1998-01.com.vmware:TK-ESX-02-252bc1ef: Check vmkernel tcp/ip settings for network properties for sw iscsi
[2011-08-24 15:58:09.676 634B2B90 verbose 'App'] CreateDurableName: Header length field exceeds actual payload
[2011-08-24 15:58:11.135 63271B90 verbose 'StorageSystem'] StoragePathUpdate Refresh --: [N11HostdCommon25VmkernelUpdateStoragePathE:0x6391d6f0] timestamp=1314201491135751 updated=0x6384a720
[2011-08-24 15:58:54.222 634B2B90 verbose 'App'] CreateDurableName: Header length field exceeds actual payload
[2011-08-24 15:58:54.245 63471B90 info 'ha-eventmgr'] Event 30 : Lost path redundancy to storage device naa.600d02310006cf810000000179af7520. Path vmhba38:C1:T0:L2 is down. Affected datastores: Unknown.
[2011-08-24 15:58:54.246 12EC8B90 info 'ha-eventmgr'] Event 31 : Lost path redundancy to storage device naa.600d02310006cf81000000005753a7ac. Path vmhba38:C1:T0:L0 is down. Affected datastores: Unknown.
[2011-08-24 15:58:54.247 6306FDB0 info 'ha-eventmgr'] Event 32 : Lost path redundancy to storage device naa.600d02310006cf810000000079af7520. Path vmhba38:C1:T0:L1 is down. Affected datastores: Unknown.
[2011-08-24 15:58:54.293 634B2B90 verbose 'App'] CreateDurableName: Header length field exceeds actual payload
[2011-08-24 15:58:56.302 12EC8B90 verbose 'ResourcePool ha-root-pool'] Root pool capacity changed from 11404MHz/5616MB to 11404MHz/5615MB
[2011-08-24 15:59:03.485 63471B90 verbose 'Cimsvc'] Ticket issued for CIMOM version 1.0, user root
[2011-08-24 15:59:43.332 634B2B90 verbose 'App'] CreateDurableName: Header length field exceeds actual payload
[2011-08-24 15:59:44.335 63471B90 info 'ha-eventmgr'] Event 33 : Lost connectivity to storage device naa.600d02310006cf810000000079af7520. Path vmhba38:C2:T1:L1 is down. Affected datastores: Unknown.
[2011-08-24 15:59:44.336 632B2B90 info 'ha-eventmgr'] Event 34 : Lost path redundancy to storage device naa.600d02310006cf81000000005753a7ac. Path vmhba38:C2:T1:L0 is down. Affected datastores: Unknown.
[2011-08-24 15:59:44.336 634B2B90 verbose 'App'] CreateDurableName: Header length field exceeds actual payload
[2011-08-24 16:00:34.122 12E87B90 verbose 'Cimsvc'] Ticket issued for CIMOM version 1.0, user root
[2011-08-24 16:01:49.317 63471B90 info 'TaskManager'] Task Created : haTask-ha-host-vim.HostSystem.acquireCimServicesTicket-1936617846
[2011-08-24 16:01:41.536 12DC4B90 verbose 'DvsManager'] PersistAllDvsInfo called
[2011-08-24 16:02:53.898 12F4AB90 info 'ha-eventmgr'] Event 35 : Lost path redundancy to storage device naa.600d02310006cf810000000179af7520. Path vmhba38:C2:T1:L2 is down. Affected datastores: Unknown.
[2011-08-24 16:02:53.900 12F8BB90 info 'ha-eventmgr'] Event 36 : Lost path redundancy to storage device naa.600d02310006cf810000000079af7520. Path vmhba38:C1:T0:L1 is down. Affected datastores: Unknown.
[2011-08-24 16:02:53.900 6306FDB0 verbose 'ResourcePool ha-root-pool'] Root pool capacity changed from 11404MHz/5615MB to 11404MHz/5614MB
[2011-08-24 16:02:53.901 632F3B90 info 'ha-eventmgr'] Event 37 : Lost path redundancy to storage device naa.600d02310006cf810000000179af7520. Path vmhba38:C1:T0:L2 is down. Affected datastores: Unknown.
[2011-08-24 16:02:53.901 632F3B90 info 'ha-eventmgr'] Event 38 : Lost path redundancy to storage device naa.600d02310006cf81000000005753a7ac. Path vmhba38:C1:T0:L0 is down. Affected datastores: Unknown.
[2011-08-24 16:02:53.903 12F8BB90 info 'ha-eventmgr'] Event 39 : Lost path redundancy to storage device naa.600d02310006cf810000000079af7520. Path vmhba38:C2:T1:L1 is down. Affected datastores: Unknown.
[2011-08-24 16:02:53.903 12F09B90 info 'ha-eventmgr'] Event 40 : Lost path redundancy to storage device naa.600d02310006cf810000000179af7520. Path vmhba38:C2:T1:L2 is down. Affected datastores: Unknown.
[2011-08-24 16:02:53.905 632B2B90 info 'ha-eventmgr'] Event 41 : Lost path redundancy to storage device naa.600d02310006cf81000000005753a7ac. Path vmhba38:C2:T1:L0 is down. Affected datastores: Unknown.
[2011-08-24 16:02:53.906 12F09B90 info 'ha-eventmgr'] Event 42 : Lost path redundancy to storage device naa.600d02310006cf810000000079af7520. Path vmhba38:C1:T0:L1 is down. Affected datastores: Unknown.
[2011-08-24 16:02:53.907 632B2B90 info 'ha-eventmgr'] Event 43 : Lost path redundancy to storage device naa.600d02310006cf810000000179af7520. Path vmhba38:C1:T0:L2 is down. Affected datastores: Unknown.
[2011-08-24 16:02:53.907 12F8BB90 info 'ha-eventmgr'] Event 44 : Lost path redundancy to storage device naa.600d02310006cf81000000005753a7ac. Path vmhba38:C1:T0:L0 is down. Affected datastores: Unknown.
[2011-08-24 16:02:53.909 632F3B90 info 'ha-eventmgr'] Event 45 : Lost path redundancy to storage device naa.600d02310006cf81000000005753a7ac. Path vmhba38:C2:T1:L0 is down. Affected datastores: Unknown.
[2011-08-24 16:02:53.911 632F3B90 info 'ha-eventmgr'] Event 46 : Lost path redundancy to storage device naa.600d02310006cf810000000079af7520. Path vmhba38:C2:T1:L1 is down. Affected datastores: Unknown.
[2011-08-24 16:02:53.912 12F09B90 info 'ha-eventmgr'] Event 47 : Lost path redundancy to storage device naa.600d02310006cf810000000179af7520. Path vmhba38:C2:T1:L2 is down. Affected datastores: Unknown.
[2011-08-24 16:02:53.918 6306FDB0 verbose 'Hostsvc::DatastoreSystem'] VmfsUpdate: got VMFS message [N11HostdCommon18VmkernelUpdateVmfsE:0xf2b06e0] timestamp=1314201773871022 specific=0 name= label=
[2011-08-24 16:02:53.920 632F3B90 error 'SoapAdapter'] PendingRequest: HTTP Transaction failed, closing connection: N7Vmacore15SystemExceptionE(Connection reset by peer)
[2011-08-24 16:02:53.934 63271B90 verbose 'StorageSystem'] SendStorageInfoEvent() called
[2011-08-24 16:02:53.935 63271B90 verbose 'StorageSystem'] StoragePathUpdate: Path state change event generated Storage related Notifications
[2011-08-24 16:02:53.935 634B2B90 verbose 'App'] Looking up object with name = "session[52940085-344c-5075-862c-95614557e45d]52e3295a-9d9a-9408-e8ae-9743810aee4b" failed.
[2011-08-24 16:02:53.935 63271B90 verbose 'StorageSystem'] StoragePathUpdate Refresh --: [N11HostdCommon25VmkernelUpdateStoragePathE:0x638004d8] timestamp=1314201518745075 updated=0x6390fe80
[2011-08-24 16:02:53.935 63271B90 verbose 'StorageSystem'] StoragePathUpdate Refresh --: [N11HostdCommon25VmkernelUpdateStoragePathE:0x63c23b98] timestamp=1314201518745483 updated=0x63c5c7b8
[2011-08-24 16:02:53.935 634B2B90 verbose 'PropertyCollector'] GetPropertyProvider failed for session[52940085-344c-5075-862c-95614557e45d]52e3295a-9d9a-9408-e8ae-9743810aee4b
[2011-08-24 16:02:53.935 63271B90 verbose 'StorageSystem'] StoragePathUpdate Refresh --: [N11HostdCommon25VmkernelUpdateStoragePathE:0x63c22430] timestamp=1314201534220549 updated=0x63c3e830
[2011-08-24 16:02:53.935 63271B90 verbose 'StorageSystem'] StoragePathUpdate Refresh --: [N11HostdCommon25VmkernelUpdateStoragePathE:0x63ce9628] timestamp=1314201534221540 updated=0x63c91368
[2011-08-24 16:02:53.935 63271B90 verbose 'StorageSystem'] StoragePathUpdate Refresh --: [N11HostdCommon25VmkernelUpdateStoragePathE:0xf1f39e8] timestamp=1314201534221968 updated=0xf1f2ba0
[2011-08-24 16:02:53.935 63271B90 verbose 'StorageSystem'] StoragePathUpdate Refresh --: [N11HostdCommon25VmkernelUpdateStoragePathE:0x638053f0] timestamp=1314201583332649 updated=0x638191f0
[2011-08-24 16:02:53.935 63271B90 verbose 'StorageSystem'] StoragePathUpdate Refresh --: [N11HostdCommon25VmkernelUpdateStoragePathE:0x63c3f090] timestamp=1314201583335760 updated=0x63c1d838
[2011-08-24 16:02:53.935 63271B90 verbose 'StorageSystem'] StoragePathUpdate Refresh --: [N11HostdCommon25VmkernelUpdateStoragePathE:0x63681108] timestamp=1314201583336161 updated=0x63680d68
[2011-08-24 16:02:53.935 63271B90 verbose 'StorageSystem'] StoragePathUpdate Refresh --: [N11HostdCommon25VmkernelUpdateStoragePathE:0x63844cf8] timestamp=1314201583336373 updated=0x63904d98
[2011-08-24 16:02:53.936 63271B90 verbose 'StorageSystem'] StoragePathUpdate Refresh --: [N11HostdCommon25VmkernelUpdateStoragePathE:0x63322688] timestamp=1314201583338532 updated=0x636e6570
[2011-08-24 16:02:53.936 63271B90 verbose 'StorageSystem'] StoragePathUpdate Refresh --: [N11HostdCommon25VmkernelUpdateStoragePathE:0xf2b5c90] timestamp=1314201583338745 updated=0xf259c40
[2011-08-24 16:02:53.936 63271B90 verbose 'StorageSystem'] StoragePathUpdate Refresh --: [N11HostdCommon25VmkernelUpdateStoragePathE:0x63c3efa0] timestamp=1314201586359349 updated=0x63c05830
[2011-08-24 16:02:53.936 63271B90 verbose 'StorageSystem'] StoragePathUpdate Refresh --: [N11HostdCommon25VmkernelUpdateStoragePathE:0x63966480] timestamp=1314201629444544 updated=0x6383be30
[2011-08-24 16:02:53.936 63271B90 verbose 'StorageSystem'] StoragePathUpdate Refresh --: [N11HostdCommon25VmkernelUpdateStoragePathE:0x6334cdd8] timestamp=1314201629444772 updated=0x6331c5a8
[2011-08-24 16:02:53.936 63271B90 verbose 'StorageSystem'] StoragePathUpdate Refresh --: [N11HostdCommon25VmkernelUpdateStoragePathE:0xf2021b0] timestamp=1314201629447033 updated=0xf23d9d0
[2011-08-24 16:02:53.936 63271B90 verbose 'StorageSystem'] StoragePathUpdate Refresh --: [N11HostdCommon25VmkernelUpdateStoragePathE:0xf1f6e40] timestamp=1314201629447248 updated=0xe779a48
[2011-08-24 16:02:53.936 63271B90 verbose 'StorageSystem'] StoragePathUpdate Refresh --: [N11HostdCommon25VmkernelUpdateStoragePathE:0x63c3e288] timestamp=1314201629447448 updated=0x63c79ee8
[2011-08-24 16:02:53.936 63271B90 verbose 'StorageSystem'] StoragePathUpdate Refresh --: [N11HostdCommon25VmkernelUpdateStoragePathE:0x6386ad20] timestamp=1314201678560757 updated=0x63804ec8
[2011-08-24 16:02:53.936 63271B90 verbose 'StorageSystem'] StoragePathUpdate Refresh --: [N11HostdCommon25VmkernelUpdateStoragePathE:0xf2de1b8] timestamp=1314201678560984 updated=0xf20a100
[2011-08-24 16:02:53.936 63271B90 verbose 'StorageSystem'] StoragePathUpdate Refresh --: [N11HostdCommon25VmkernelUpdateStoragePathE:0x63c23d78] timestamp=1314201678563150 updated=0x63c20818
[2011-08-24 16:02:53.936 63271B90 verbose 'StorageSystem'] StoragePathUpdate Refresh --: [N11HostdCommon25VmkernelUpdateStoragePathE:0xf213d30] timestamp=1314201678563368 updated=0xf2be4e0
[2011-08-24 16:02:53.937 63271B90 verbose 'StorageSystem'] StoragePathUpdate Refresh --: [N11HostdCommon25VmkernelUpdateStoragePathE:0x63331858] timestamp=1314201678565469 updated=0x63685f98
[2011-08-24 16:02:53.937 63271B90 verbose 'StorageSystem'] StoragePathUpdate Refresh --: [N11HostdCommon25VmkernelUpdateStoragePathE:0x63c3e258] timestamp=1314201678565662 updated=0x63cc1d50
[2011-08-24 16:02:53.937 63271B90 verbose 'StorageSystem'] StoragePathUpdate Refresh --: [N11HostdCommon25VmkernelUpdateStoragePathE:0xf255a58] timestamp=1314201681585144 updated=0xf2d3170
[2011-08-24 16:02:53.937 63271B90 verbose 'StorageSystem'] StoragePathUpdate Refresh --: [N11HostdCommon25VmkernelUpdateStoragePathE:0xf255a70] timestamp=1314201724670292 updated=0xf2c7348
[2011-08-24 16:02:53.937 63271B90 verbose 'StorageSystem'] StoragePathUpdate Refresh --: [N11HostdCommon25VmkernelUpdateStoragePathE:0xf2e3268] timestamp=1314201724670467 updated=0xf2d1ae0
[2011-08-24 16:02:53.937 63271B90 verbose 'StorageSystem'] StoragePathUpdate Refresh --: [N11HostdCommon25VmkernelUpdateStoragePathE:0xf213c58] timestamp=1314201724673118 updated=0xf1f52e0
[2011-08-24 16:02:53.946 634B2B90 error 'App'] Failed to send response to the client: Broken pipe
[2011-08-24 16:02:53.946 632B2B90 error 'SoapAdapter'] PendingRequest: HTTP Transaction failed, closing connection: N7Vmacore15SystemExceptionE(Connection reset by peer)
[2011-08-24 16:02:53.954 6306FDB0 verbose 'DvsTracker'] FetchSwitches: added 0 items
[2011-08-24 16:02:53.954 6306FDB0 verbose 'DvsTracker'] FetchDVPortgroups: added 0 items
[2011-08-24 16:02:53.966 12DC4B90 info 'App'] CreateISCSIHBA
[2011-08-24 16:02:54.004 12DC4B90 warning 'App'] IP properties discovery failure on iSCSI HBA: iqn.1998-01.com.vmware:TK-ESX-02-252bc1ef: Check vmkernel tcp/ip settings for network properties for sw iscsi
[2011-08-24 16:02:54.018 631EFB90 verbose 'FSVolumeProvider'] RefreshVMFSVolumes: refreshed volume, id 4a81209d-874679fc-324a-001517643739, name datastore1 (1)
[2011-08-24 16:02:54.019 631EFB90 verbose 'Hostsvc::Datastore'] SetVolume: Datastore 4a81209d-874679fc-324a-001517643739 has changed provider volume pointer
[2011-08-24 16:02:54.019 631EFB90 verbose 'Hostsvc::DatastoreSystem'] ReconcileVMFSDatastores: Done discovering new filesystem volumes.
[2011-08-24 16:02:54.019 631EFB90 info 'TaskManager'] Task Completed : haTask-ha-host-vim.host.StorageSystem.rescanVmfs-1936617788 Status success
Protokollende erreicht.

[Tschoergez]

sieht so aus, als würde der ESX die luns nicht mehr sehen können.
Werden sie denn unter "Storage Adapters" noch als Geräte angezeigt?

Ansonsten brauchts etwas mehr Info zur Storage und Netzwerkkonfiguration (um die ganzen path-down-Meldungen interpretieren zu können)...
Viele Grüße,
Jörg

[Login]

also, die Pfade werden wie gesagt angezeigt, auch die Geräte. Komisch war, dass nach einem der Neustarts des Host die Pfadkonfiguration von RoundRobin auf VMwareFest gesprngen ist. Nach Umstellung auf RR waren aber wieder beide Pfade pro gerät aktiv.

Was willst du zur Storagekonfig wissen?

- 1 Kontroller mit 2 Ausgängen active/active
- Alle 3 LUNs auf beide Channels gemappt
- ch01. 10.10.10.10, ch02 10.10.10.11

- 2x iSCSI Kernel über jeweils eigene vSwitches an eine pNIC gebunden
- Jumbos überall aktiv
- iSCSI-VMK-01 10.10.10.12, VMK-02 10.10.10.13
- Speicher-Array-Type: VMW_SATP_DEFAULT_AA

[Login]

EDIT: Nun, ohne Änderungen gemacht zu haben, sehe ich die LUNS wieder, wenn ich einen Datastore hinzufügen würde. Aber wenn ich das machen würde, würde er mir doch ein neues vmfs formatieren, oder nicht ? Also lieber finger weg!?

[bla!zilla]

Wenn er die präsentierten Volumes NICHT selbstständig als Datastores erkennt und einbindet, finger weg. Dann ist da richtig was grütze, evtl. Filesystem hinüber.

[Login]

jepp, aber es muss ein hostproblem sein, denn der Kollege im Cluster hat 9 große VMs auf den 3 Partitionen im Storage laufen, stabil und hier ist alles wie immer.

Gruß,
Conne

[echt_weg]

ich würde vorerst auf keinen fall einen rescan auf dem funktionierendem host machen. Bist du sicher, dass nicht evtl. die VMFS-Signatur zerschossen ist? z.B. durch einen Windows Backup Server?

[Login]

ich würde vorerst auf keinen fall einen rescan auf dem funktionierendem host machen. Bist du sicher, dass nicht evtl. die VMFS-Signatur zerschossen ist? z.B. durch einen Windows Backup Server?

sag doch nicht sowas!! Den laufenden Host habe ich auch noch nciht mal mit dem kleinen Finger angefasst, weil ich ich auch nciht weiß, ob der nciht nach einen Rescan/Neustart ähnliche Probleme bekommt!

Das ist grad ganz schön wackelig und ich würde gerne den Grund der ganzen Sache wissen.

In den letzten 3 Wochen wurden bei diesem Kunden ein SymantecBackupEXEC mit vAgents eingerichtet. Die BackupVM liegt auf einer der 3 Luns, kann das was damit zu tun haben!?!?

Aber ich kann mir kaum vorstellen, dass es alle 3 Partitionen auf dem Storage verrissen hat!?!??


WAS IST HIER LOS???

[irix]

Die Frage ob die LUNs auch an den Windows Backup Server gemappt worden sind und man das automount vergessen hat zu deaktivieren.

Mein Rat an die ist das du dich an den VMware Support wendest. Der kann dir Sagen was mit dem VMFS ist. In der Zwischenzeit mal pruefen ob vollstaendie und funktionierende Backups der VMs vorhanden sind!.

Ansonsten halt neue LUN/Datastore erstellen und die funktionierenden ESX Hosts verwenden um die VMs dorthin zu migrieren. Hinterher die alten DS loeschen und den einen Hosts wieder in Betrieb nehmen. Natuerlich vorher die Konfig des Backup Servers anpassen.

Gruss
Joerg

[bla!zilla]

Check mal das vmkernel Log per SSH. Evtl. steht da noch was nettes drin.

[Login]

Die Frage ob die LUNs auch an den Windows Backup Server gemappt worden sind und man das automount vergessen hat zu deaktivieren.

nein, die werden nicht direkt gemappt. Während des SymantecBackups werden die vmdks direkt an die BackupVM gehangen.

Wäre in dem Fall was am SymantecJob falsch eingestellt?

Mein Rat an die ist das du dich an den VMware Support wendest. Der kann dir Sagen was mit dem VMFS ist. In der Zwischenzeit mal pruefen ob vollstaendie und funktionierende Backups der VMs vorhanden sind!.

Ansonsten halt neue LUN/Datastore erstellen und die funktionierenden ESX Hosts verwenden um die VMs dorthin zu migrieren. Hinterher die alten DS loeschen und den einen Hosts wieder in Betrieb nehmen. Natuerlich vorher die Konfig des Backup Servers anpassen.

Puh, hätte der Sucide-Kunde dieses Jahr einen gültigen SupportContract, könnte ich auch VMware mit einbeziehen...

Einen temp. Storage an den Host zu binden, um die VMs zu verlagen ist genauso sch*****, wenn ich den Rescan für den neuen DS machen, gehen mir vielleicht alle VMs und dann für immer flöten!

Sackgasse?!?

Ohmann.

[Login]

Sorry für das lange Log...

<logfile_weiter_unten>

[echt_weg]

nein, die werden nicht direkt gemappt. Während des SymantecBackups werden die vmdks direkt an die BackupVM gehangen.

das ist schonmal seht gut dann kannst du zumindest ausschliessen, dass ein windows host das vmfs zerschossen hat

[Login]

Da der Platz hier nicht fürs voll Log reicht und die wirklich interessanten Zeilen relativ weit unten sind, hier das komplette LOG-File:

ftp://ftp.beruf-gesund.de/

Gruß,
Conne

[kastlr]

Hallo,

du solltest die Einstellung der vmk1 NIC überprüfen, denn dieser Adapter befindet sich nicht im gleichen Subnetz wie dein iSCSI Storage.
Für diesen Adapter finden sich folgende Einträge im Logfile.

Aug 24 20:19:33 vmkernel: 0:00:01:20.797 cpu1:4789) WARNING: Tcpip_Vmk: 210: cannot honor socket binding with vmk1(src_subnet=0xa141e00, dst_subnet=0xa0a0a00), dontroute=0, ro_rt=0x4100b80c08f0
Aug 24 20:19:37 iscsid: Login Failed: iqn.2002-10.com.infortrend:raid.sn7817089.001 if=vmk1 addr=10.10.10.10:3260 (TPGT:1 ISID:0x1) Reason: 000c0000 (Initiator Connection Failure)

Vielleicht hilft dir dabei ja auch folgender VMware KB Artikel weiter.
Cannot reach iSCSI target after enabling iSCSI port binding on ESX/ESXi 4.x

Und für deine beiden NIC's, die du zum Zugriff auf den iSCSI Storage verwendest, finden sich folgende Einträge in den Logs.

Aug 24 20:19:39 iscsid: Login Success: iqn.2002-10.com.infortrend:raid.sn7817089.001 if=vmk2 addr=10.10.10.10:3260 (TPGT:1 ISID:0x2)
Aug 24 20:19:39 iscsid: connection 1:0 (iqn.2002-10.com.infortrend:raid.sn7817089.001 if=vmk2 addr=10.10.10.10:3260 (TPGT:1 ISID:0x2) (T0 C1)) is operational now
Aug 24 20:20:02 iscsid: Login Failed: iqn.2002-10.com.infortrend:raid.sn7817089.101 if=vmk2 addr=10.10.10.11:3260 (TPGT:1 ISID:0x2) Reason: 00080000 (Initiator Connection Failure)
Aug 24 20:21:03 iscsid: Connection 1:0 (iqn.2002-10.com.infortrend:raid.sn7817089.001 if=vmk2 addr=10.10.10.10:3260 (TPGT:1 ISID:0x2) (T0 C1)) Nop-out timedout after 10 seconds in state (3). Dropping session.
Aug 24 20:21:06 iscsid: connection 1:0 (iqn.2002-10.com.infortrend:raid.sn7817089.001 if=vmk2 addr=10.10.10.10:3260 (TPGT:1 ISID:0x2) (T0 C1)) has recovered (2 attempts)
Aug 24 20:21:57 iscsid: Connection 1:0 (iqn.2002-10.com.infortrend:raid.sn7817089.001 if=vmk2 addr=10.10.10.10:3260 (TPGT:1 ISID:0x2) (T0 C1)) Nop-out timedout after 10 seconds in state (3). Dropping session.

Aus mir bisher unbekannten Gründen fliegen dir die Verbindungen um die Ohren, der Intervall dafür ist ziemlich genau 51sec.
Und darüber hinaus scheint der Fehler immer hübsch zwischen den beiden NICs hin und her zu springen.

Ich an deiner Stelle würde mal eine NIC (vmk2 oder vmk3) deaktivieren, um auszuschließen, das die sich gegenseitig stören.
Abhängig vom Ergebnis müßtest du noch einmal die Logs zur Verfügung stellen.

Viel Erfolg
Ralf

[Login]

Hallo,

vmk1 war in der alten Konfig vMotion. Ich hatte das so verstanden, dass der vMotion Verkehr zwischen Hosts in einem sepparaten IP-Netz betrieben werden soll. Hatte mich aber schon gewundert, warum sich vmk1 an swiSCSI gebunden hat, ich war das nämlich sicher nicht! Soll der ins iSCSI-Netz?

Mittlerweile habe ich den kranken Host in meiner Not komplett neu installiert und konfiguriert. Er macht exakt das, was er vor der Neuinstallation auch gemacht hat

In den Uploadlink ( ftp://ftp.beruf-gesund.de ) habe ich grad die aktuellen Logs der beiden Hosts und einen Screenshot von der Netzwerkkonfig kopiert.

In dieser Konfig liefen die Server Jahre lang stabil...

Leider habe keine pNic mehr am Server zur Verfügung, um FT und vMotion über eigene pNics zu leiten. Ist die Konfig so ok?

Für eure tatkräftige Hilfe bedanke ich mich mal an dieser Stelle

Gruß,
Conne

[Login]

[/quote]Ich an deiner Stelle würde mal eine NIC (vmk2 oder vmk3) deaktivieren, um auszuschließen, das die sich gegenseitig stören.
Abhängig vom Ergebnis müßtest du noch einmal die Logs zur Verfügung stellen.
[quote]

Wurde indirekt überprüft. Nach der NEuinstallation habe ich erst mal nur einen iSCSI-Kernel ins Leben gerufen und einen NEustart des Hosts gemacht -> Pfade sind da, aber Datastores werden nicht erkannt. Wenn ich einen neuen DS hinzufügen würde, würde er mir die Lun formatieren, da klicke ich natürlich wieder auf "zurück"

Einen Neusart des gesunden Hosts und des Storages habe bisher gelassen, da ich mir sorgen mache, dass das die Datastores dann auch für den gesunden Host nicht mehr da sind!!

[bla!zilla]

Was auffällt:

Code: Alles auswählen

IP properties discovery failure on iSCSI HBA: iqn.1998-01.com.vmware:TK-ESX-01-17305ea3: Check vmkernel tcp/ip settings for network properties for sw iscsi

Zudem versucht er eine Verbindung aufzubauen, die fliegt aber immer wieder weg. Check bitte mal Switchports, IP-Adressen, Subnetze und die korrekte Konfiguration eures Storagesystems. Bitte wirklich prüfen (vier Augen am besten) und nicht einfach sagen "Ging doch vorher". Ich tippe darauf, dass da irgendwo der Wurm drin ist.

[Login]

das taucht drei mal im Log auf. Kann es sein, dass dies kurz nach der Einrichtung des ersten Kernels ins Log plumste?
Kann sein, dass ich als erstes eine ip im falschen netz hinterlegt hatte... ...wenn ich mich recht entsinne, die zeit kommt auch hin.

Die Kabelkonnektionen wurden heute überprüft. Die Switche und das Storage würde ich eben gerne durchstarten, mache ich aber nicht, weil ich nicht will dass der verbliebe esx auch noch probleme bekommt. Verzwickt, auch dass ich im Moment keinen Zugriff auf die beiden pSwitche-Logs vom iSCSI Verkehr habe.

Hier die aktuellen Logs/Konfigs: ( ftp://ftp.beruf-gesund.de )

[kastlr]

Hallo Conne,

das eigentliche Problem ist meiner Meinung nach, das die Connection immer wieder einen Time Out bekommen.
Im Anschluß daran wird die Verbindung zwar wieder recovered, aber sie bleibt einfach nicht stabil bestehen.

Meiner Meinung nach könnte es sich hierbei um ein SCSI Reservation Issue handeln.
Die LUNs werden erkannt, allerdings kann der Host danach kaum noch weitere Informationen über das jeweilige Device ermittelt.
Und da der Host noch nicht einmal den Datastore mounten kann, finden sich auch nicht die sonst üblichen Hinweise auf SCSI Reservation Conflicts in den Logfiles.

Du solltest dir mal folgenden VMware KB Artikel zur Brust nehmen.
Resolving SCSI reservation conflicts
Damit solltest du in der Lage sein, deine Umgebung auf "hängengebliebende" Reservierungen zu prüfen.

Ich an deiner Stelle würde mal einen LUN/Bus Reset ausprobieren, und zwar von dem Host, der aktuell die VM's hostet.
Das ist sicherlich mit einem gewissem Risiko verbunden, aber ohne weitere Maßnahmen wirst du nicht weiterkommen.

Viel Erfolg,
Ralf

[Login]

mittlerweile sieht es folgerdermaßen (schlecht) aus:

- Der Problem-ESX wurde komplett neu installiert und mit abweichenden Daten konfiguriert. Schon in der einfachsten Grundkonfiguration mit einem Pfad ohne Jumboframes, ist sind die Luns für den ESX sichtbar, er kann den Datastore darauf aber nicht lesen/einbinden.

- Nachdem Storage und der bisher gesunde ESX neu gestartet wurden, ist selbes Phänomen auch auf diesem Host gebeben!! Zum Glück hatte ich die wichtigesten VMs am vor dem Neustart noch auf die local Datastores geklont!! Aktuell läuft beim Kunden also ein Notbetrieb mit den wichtigsten Servern.

- Das Storage hat die aktuellste Firmware geflasht bekommen und die Einstellungen (wobei die letzten Monate wirklich nichts am Storage verändert wurde) wurden alle nochmal überprüft.

- Auch die IP-Konfig vom Storage und den iSCSI-Kerneln wurden überprüft bzw. testweise in andere IP-Netze geändert, da in den ESX-Logs immer wieder hinweise auf eine vermeindlich falsche IP-Konfig für den iSCSI-HBA zu lesen sind, aber da sich die letzten Monate auch da nichts geändert hat, bin ich mir nicht sicher, ob ich die Meldung wort-wörtlich nehmen kann! Zumal die IP-Konfig von den iSCSI-Kernels ja nicht sehr umfachreich ist und ich mich frage, wie da Fehler existieren können... Ich gehe nicht davon aus, dass die IPs falsch sind, da die Pfade vollständig und konstant verfügbar sind.

Aug 27 14:24:38 Hostd: [2011-08-27 14:24:38.931 7EE40B90 warning 'App'] IP properties discovery failure on iSCSI HBA: iqn.1998-01.com.vmware:tk-esx-01-17305ea3: Check vmkernel tcp/ip settings for network properties for sw iscsi

Das ist die Meldung auf dem neu installierten Host, komisch ist das TK-ESX-01 der andere Host ist.