Digi-Quick
Urgestein
- Mitglied seit
- 02.09.2009
- Beiträge
- 7.082
Moin,
z.B. um welche Devices geht das bei diesen Einträgen und was kann/soll/muß/darf ich daraus ableiten:
Was soll mir das sagen:
Welcher USB Storage, es ist keiner angeschlossen:
Sind hier zu viele Dateien auf dem ESXi göffnet und wenn ja, warum?
Ich habe am Samstag Nachmittag in einem anderen Server den Speicher getauscht, dafür mußte ich den Switch umpositionieren, da der auf dem Serverdeckel lag.
Dafür habe ich die beiden Netzwerkkabel vom ESXi kurfristig gezogen.
Der ESXi ist mit beiden 10GBE Ports an einem 10GBE-Switch (D-Link DXS-1210-10TS 10GbE Smart Managed Switch) angeschlossen, auf dem Switch selbst ist kein Trunking eingerichtet.
Der Kollge, der das eingerichtet hat meinte DAS würde den internen v-switch beschleunigen - ich frage mich allerdings wie das gehen soll.
Extern ist eigentlich nur ein NAS mit 10 GBE zu "füttern" (Online-Datensicherung), der andere Server hat nur GBit und benötigt kaum Transferleistung und dann ist da noch das Internet mit max 32 MBit.
Ein 10 GBE Link wird zu keiner Zeit mehr als ca. 30% ausgelastet
Ich habe die Netzwerkkabel wieder angeschlossen, am 2. Server den Speicher getauscht (Es stellte sich im Nachhinein heraus, daß die Programmabstürze durch was ganz anderes verursacht wurden.).
Die Netzwerkzugriffe (SMB, Datenbank etc.) liefen alle.
Ich kann nicht mehr genau sagen, wann es losging, da die vmkwarnings.log bereits komplett voll war, es muß etwa 10-30 Minuten Später losgegangen sein, daß der ESXi sämtliche externen Netzverbindungen totgelegt hat.
Erschreckenderweise war auch der BMC/IPMI via dedicated LAN Port nicht mehr erreichbar.
Direkt auf der ESXi Konsole konnte ich die IP Adressen der VMs anpingen, aber keine IP-Adresse ausserhalb (Switch, Router/Gateway, NAS etc.)
Unterbrochen wurde die Eintrags-Flut ab und an durch Meldungen dieser Art:
Meine Vermutung: Ich habe die Kabel beim wiederanschliessen vertauscht und ESXi hat das erkannt und daraufhin die Netzverbindungen wegen vermutetem Hackerangriff gekappt.
Ich frage mich allerdings, wie ESXi den BMC ebenfalls abschotten kann.
Aktuell steht bei "VM Network"
Sicherheitsrichtlinie Promiscuous-Modus zulassen : Nein
Gefälschte Übertragungen zulassen: Ja
MAC-Änderungen zulassen: Ja
Netzwerkkarten-Gruppierungsrichtlinien
Switches benachrichtigen :Ja
Richtlinie: Lastenausgleich basierend auf der Quell-ID
Umkehrrichtlinie : Ja
Rollender Auftrag : Nein
z.B. um welche Devices geht das bei diesen Einträgen und was kann/soll/muß/darf ich daraus ableiten:
Code:
2017-01-21T19:02:01.887Z cpu0:37881)WARNING: PCI: 157: 0000:00:00.0: Bypassing non-ACS capable device in hierarchy
2017-01-21T18:04:54.943Z cpu8:35713)WARNING: NetDVS: 660: portAlias is NULL
0:00:00:08.880 cpu0:32768)WARNING: PCI: 1275: No resources for device: 0000:ff:1e.3, BAR[0]: 0x10, size: 16, type: 0x3, flags: 0x6
Was soll mir das sagen:
Code:
2017-01-21T19:01:53.393Z cpu0:37881)WARNING: NFS41: NFS41_VSIGetMaxQueueDepth:3509: Invalid arg count! (0): Usage <FS>
2017-01-21T19:01:53.393Z cpu0:37881)WARNING: NFS41: NFS41_VSIGetShares:3385: Invalid arg count! (0): Usage <FS> <worldID>
Welcher USB Storage, es ist keiner angeschlossen:
Code:
2017-01-23T05:47:43.994Z cpu0:33265)WARNING: LinScsiLLD: scsi_add_host:573: vmkAdapter (usb-storage) sgMaxEntries rounded to 255. Reported size was 65535
2017-01-23T05:47:44.226Z cpu12:33265)WARNING: LinScsiLLD: scsi_add_host:573: vmkAdapter (usb-storage) sgMaxEntries rounded to 255. Reported size was 65535
2017-01-23T05:47:44.458Z cpu1:33265)WARNING: LinScsiLLD: scsi_add_host:573: vmkAdapter (usb-storage) sgMaxEntries rounded to 255. Reported size was 65535
Sind hier zu viele Dateien auf dem ESXi göffnet und wenn ja, warum?
Code:
2017-01-21T18:01:23.743Z cpu4:33506)WARNING: MaxFileHandles: 9600, Prealloc 1, Prealloc limit: 32 GB, Host scaling factor: 1
Ich habe am Samstag Nachmittag in einem anderen Server den Speicher getauscht, dafür mußte ich den Switch umpositionieren, da der auf dem Serverdeckel lag.
Dafür habe ich die beiden Netzwerkkabel vom ESXi kurfristig gezogen.
Der ESXi ist mit beiden 10GBE Ports an einem 10GBE-Switch (D-Link DXS-1210-10TS 10GbE Smart Managed Switch) angeschlossen, auf dem Switch selbst ist kein Trunking eingerichtet.
Der Kollge, der das eingerichtet hat meinte DAS würde den internen v-switch beschleunigen - ich frage mich allerdings wie das gehen soll.
Extern ist eigentlich nur ein NAS mit 10 GBE zu "füttern" (Online-Datensicherung), der andere Server hat nur GBit und benötigt kaum Transferleistung und dann ist da noch das Internet mit max 32 MBit.
Ein 10 GBE Link wird zu keiner Zeit mehr als ca. 30% ausgelastet
Ich habe die Netzwerkkabel wieder angeschlossen, am 2. Server den Speicher getauscht (Es stellte sich im Nachhinein heraus, daß die Programmabstürze durch was ganz anderes verursacht wurden.).
Die Netzwerkzugriffe (SMB, Datenbank etc.) liefen alle.
Ich kann nicht mehr genau sagen, wann es losging, da die vmkwarnings.log bereits komplett voll war, es muß etwa 10-30 Minuten Später losgegangen sein, daß der ESXi sämtliche externen Netzverbindungen totgelegt hat.
Erschreckenderweise war auch der BMC/IPMI via dedicated LAN Port nicht mehr erreichbar.
Direkt auf der ESXi Konsole konnte ich die IP Adressen der VMs anpingen, aber keine IP-Adresse ausserhalb (Switch, Router/Gateway, NAS etc.)
Code:
2017-01-21T17:50:46.230Z cpu15:33219)WARNING: LinNet: netdev_watchdog:3680: NETDEV WATCHDOG: vmnic0: transmit timed out
2017-01-21T17:50:47.233Z cpu18:33223)WARNING: LinNet: netdev_watchdog:3680: NETDEV WATCHDOG: vmnic1: transmit timed out
Code:
cpu17:33208)<6>ixgbe 0000:03:00.0: vmnic0: Fake Tx hang detected with timeout of 160 seconds
33223)<4>ixgbe 0000:03:00.0: vmnic0: -1 Spoofed packets detected"
Meine Vermutung: Ich habe die Kabel beim wiederanschliessen vertauscht und ESXi hat das erkannt und daraufhin die Netzverbindungen wegen vermutetem Hackerangriff gekappt.
Ich frage mich allerdings, wie ESXi den BMC ebenfalls abschotten kann.
Aktuell steht bei "VM Network"
Sicherheitsrichtlinie Promiscuous-Modus zulassen : Nein
Gefälschte Übertragungen zulassen: Ja
MAC-Änderungen zulassen: Ja
Netzwerkkarten-Gruppierungsrichtlinien
Switches benachrichtigen :Ja
Richtlinie: Lastenausgleich basierend auf der Quell-ID
Umkehrrichtlinie : Ja
Rollender Auftrag : Nein
Zuletzt bearbeitet: