PowerStore: Inbäddad ESXi-nod kan inte visa några protokollslutpunkter på PowerStore X
This article applies to
This article does not apply to
This article is not tied to any specific product.
Not all product versions are identified in this article.
Symptoms
När den maximala överföringsenheten (MTU) som konfigurerats på ethernetswitchar inte är lika med eller större än den MTU som konfigurerats i PowerStore-hanteringsnätverket kan det orsaka återkommande hanteringsproblem.
I det här specifika exemplet misslyckas PowerStore X VASA-anslutningen endast för en av de inbäddade ESXi-värdarna (värden som är installerad på nod B)
När jumboramar (vanligtvis en MTU-storlek på 9 000 byte) är aktiverade måste de konsekvent ställas in från ände till ände. Felkonfigurerade jumboramar kan resultera i anslutningsfel eller försämrade IO-prestanda.
Kontrollera att felet i vvold.log är err=Connection timed out och inteerr=SSL Exception. Om felet är SSL Exception följer du istället VMware KB 67744.
När du testar anslutningen med jumboramar subtraherar du ICMP-huvudet på 8 byte och den minsta IP-huvudstorleken på 20 byte. 9 000 – 28 = 8 972. Dessa två huvuden läggs till automatiskt och ökar ramstorleken.
Pingtesterna kördes från en ssh-session till ESXi-värdarna, se VMware KB 1003728 för mer information om vmkping.
Det verkar som att det inte går att pinga över VLTi-portkanalen. Om pingarna fungerar eller inte i exemplen ovan beror på vilket källgränssnitt som väljs, eftersom varje källgränssnitt är anslutet till olika switchar.
På en Dell Networking OS10- eller OS9-switch ska MTU för alla gränssnitt som är anslutna till PowerStore ställas in på 9 216. Felaktig konfiguration leder till det här problemet.
Det finns ett problem i OS10-versioner före 10.5.0 (augusti 2019) där VLTi-gränssnittets portkanal 1 000 inte skickar ramar med en MTU som är större än 1 500 utan fragmentering. Som standard förväntas att VLTi ska skicka ramar upp till 9 216 MTU.
Efter att ha korrigerat MTU-felmatchningen och skannat om lagringen på ESXi-värden kan vi se alla protokollslutpunkter som förväntat.
I det här specifika exemplet misslyckas PowerStore X VASA-anslutningen endast för en av de inbäddade ESXi-värdarna (värden som är installerad på nod B)
När jumboramar (vanligtvis en MTU-storlek på 9 000 byte) är aktiverade måste de konsekvent ställas in från ände till ände. Felkonfigurerade jumboramar kan resultera i anslutningsfel eller försämrade IO-prestanda.
Innehållsförteckning
1. Problem
Dessa anslutningsfel observeras i /var/log/vvold.log på den berörda ESXi-värden:2020-06-24T09:33:08.114Z info vvold[2104948] [Originator@6876 sub=Default] VasaSession::Initialize url is empty 2020-06-24T09:33:08.114Z warning vvold[2104948] [Originator@6876 sub=Default] VasaSession::DoSetContext: Empty VP URL for VP (PowerStore)! 2020-06-24T09:33:08.114Z info vvold[2104948] [Originator@6876 sub=Default] Initialize: Failed to establish connection https://xx.xx.xx.xx:8443/version.xml 2020-06-24T09:33:08.114Z error vvold[2104948] [Originator@6876 sub=Default] Initialize: Unable to init session to VP PowerStore state: 0 2020-06-24T09:33:08.117Z info vvold[2104947] [Originator@6876 sub=Default] VasaSession::GetEndPoint: with url https://xx.xx.xx.xx:8443/version.xml 2020-06-24T09:34:28.895Z warning vvold[2104947] [Originator@6876 sub=Default] VasaSession::GetEndPoint: failed to get endpoint, err=Connection timed out, using default 2020-06-24T09:34:28.896Z info vvold[2104947] [Originator@6876 sub=Default] VasaSession::Initialize url is empty
Det här är ett annat exempel från loggen nedan från ett annat system. Följande logg är ett certifikatfel som är ett helt annat problem. I exemplet ovan är det dock ett anslutningsfel även om stora delar av loggen är identiska.
Dessa certifikatfel observeras i /var/log/vvold.log på en annan ESXi-värd för ett annat problem:
2019-12-26T16:57:03.396Z info vvold[2139844] [Originator@6876 sub=Default] VasaSession::GetEndPoint: with url https://xxxxxxxx.com:8443/version.xml 2019-12-26T16:57:03.401Z warning vvold[2139844] [Originator@6876 sub=Default] VasaSession::GetEndPoint: failed to get endpoint, err=SSL Exception: Verification parameters: --> PeerThumbprint: 0B:01:C4:F2:16:E0:10:C9:63:B5:F2:92:D3:36:B5:65:5C:59:DB:17 --> ExpectedThumbprint: --> ExpectedPeerName: xxxxxxxx.com --> The remote host certificate has these problems: --> --> * Host name does not match the subject name(s) in certificate., using default 2019-12-26T16:57:03.401Z info vvold[2139844] [Originator@6876 sub=Default] VasaSession::Initialize url is empty 2019-12-26T16:57:03.401Z warning vvold[2139844] [Originator@6876 sub=Default] VasaSession::DoSetContext: Empty VP URL for VP (xxxxxxxxx)! 2019-12-26T16:57:03.401Z info vvold[2139844] [Originator@6876 sub=Default] Initialize: Failed to establish connection https://xxxxxxxx.com:8443/version.xml 2019-12-26T16:57:03.401Z error vvold[2139844] [Originator@6876 sub=Default] Initialize: Unable to init session to VP xxxxxxxxx state: 0
Kontrollera att felet i vvold.log är err=Connection timed out och inteerr=SSL Exception. Om felet är SSL Exception följer du istället VMware KB 67744.
När du testar anslutningen med jumboramar subtraherar du ICMP-huvudet på 8 byte och den minsta IP-huvudstorleken på 20 byte. 9 000 – 28 = 8 972. Dessa två huvuden läggs till automatiskt och ökar ramstorleken.
[root@Powerstore1000X-host-2:~] vmkping -I vmk1 1.2.3.4 -s 8972 -c 2 PING 1.2.3.4 (1.2.3.4): 8972 data bytes 8980 bytes from 1.2.3.4: icmp_seq=0 ttl=64 time=0.327 ms 8980 bytes from 1.2.3.4: icmp_seq=1 ttl=64 time=0.376 ms --- 1.2.3.4 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 0.327/0.352/0.376 ms [root@Powerstore1000X-host-2:~] vmkping -I vmk1 1.2.3.5 -s 8972 -c 2 PING 1.2.3.5 (1.2.3.5): 8972 data bytes --- 1.2.3.5 ping statistics --- 2 packets transmitted, 0 packets received, 100% packet loss[root@Powerstore1000X-host-2:~] [root@Powerstore1000X-host-2:~] vmkping -I vmk2 1.2.3.5 -s 8972 -c 2 PING 1.2.3.5 (1.2.3.5): 8972 data bytes 8980 bytes from 1.2.3.5: icmp_seq=0 ttl=64 time=0.303 ms 8980 bytes from 1.2.3.5: icmp_seq=1 ttl=64 time=0.411 ms --- 1.2.3.5 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 0.303/0.357/0.411 ms [root@Powerstore1000X-host-2:~] vmkping -I vmk2 1.2.3.4 -s 8972 -c 2 PING 1.2.3.4 (1.2.3.4): 8972 data bytes --- 1.2.3.4 ping statistics --- 2 packets transmitted, 0 packets received, 100% packet loss[root@Powerstore1000X-host-2:~]
Pingtesterna kördes från en ssh-session till ESXi-värdarna, se VMware KB 1003728 för mer information om vmkping.
[root@Powerstore1000X-host-2:~] vmkping -I vmk1 1.2.3.4 -s 8972 -c 2 PING 1.2.3.4 (1.2.3.4): 8972 data bytes 8980 bytes from 1.2.3.4: icmp_seq=0 ttl=64 time=0.327 ms 8980 bytes from 1.2.3.4: icmp_seq=1 ttl=64 time=0.376 ms --- 1.2.3.4 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 0.327/0.352/0.376 ms [root@Powerstore1000X-host-2:~] vmkping -I vmk1 1.2.3.5 -s 8972 -c 2 PING 1.2.3.5 (1.2.3.5): 8972 data bytes --- 1.2.3.5 ping statistics --- 2 packets transmitted, 0 packets received, 100% packet loss[root@Powerstore1000X-host-2:~] [root@Powerstore1000X-host-2:~] vmkping -I vmk2 1.2.3.5 -s 8972 -c 2 PING 1.2.3.5 (1.2.3.5): 8972 data bytes 8980 bytes from 1.2.3.5: icmp_seq=0 ttl=64 time=0.303 ms 8980 bytes from 1.2.3.5: icmp_seq=1 ttl=64 time=0.411 ms --- 1.2.3.5 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 0.303/0.357/0.411 ms [root@Powerstore1000X-host-2:~] vmkping -I vmk2 1.2.3.4 -s 8972 -c 2 PING 1.2.3.4 (1.2.3.4): 8972 data bytes --- 1.2.3.4 ping statistics --- 2 packets transmitted, 0 packets received, 100% packet loss[root@Powerstore1000X-host-2:~]
Det verkar som att det inte går att pinga över VLTi-portkanalen. Om pingarna fungerar eller inte i exemplen ovan beror på vilket källgränssnitt som väljs, eftersom varje källgränssnitt är anslutet till olika switchar.
2. Lösning
På en Dell Networking OS10- eller OS9-switch ska MTU för alla gränssnitt som är anslutna till PowerStore ställas in på 9 216. Felaktig konfiguration leder till det här problemet.
Det finns ett problem i OS10-versioner före 10.5.0 (augusti 2019) där VLTi-gränssnittets portkanal 1 000 inte skickar ramar med en MTU som är större än 1 500 utan fragmentering. Som standard förväntas att VLTi ska skicka ramar upp till 9 216 MTU.
SWITCH# ping -M do -s 8972 1.2.3.6 -c 3 PING 1.2.3.6 (1.2.3.6) 8972(9000) bytes of data. ping: local error: Message too long, mtu=1500 ping: local error: Message too long, mtu=1500 ping: local error: Message too long, mtu=1500 --- 1.2.3.6 ping statistics --- 3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2042ms SWITCH# ping -M do -s 2472 1.2.3.6 -c 3 PING 1.2.3.6 (1.2.3.6) 2472(2500) bytes of data. ping: local error: Message too long, mtu=1500 ping: local error: Message too long, mtu=1500 ping: local error: Message too long, mtu=1500 --- 1.2.3.6 ping statistics --- 3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2039ms SWITCH# ping -M do -s 1472 1.2.3.6 -c 3 PING 1.2.3.6 (1.2.3.6) 1472(1500) bytes of data. 1480 bytes from 1.2.3.6: icmp_seq=1 ttl=64 time=1.05 ms 1480 bytes from 1.2.3.6: icmp_seq=2 ttl=64 time=0.966 ms 1480 bytes from 1.2.3.6: icmp_seq=3 ttl=64 time=1.00 ms --- 1.2.3.6 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2001ms rtt min/avg/max/mdev = 0.966/1.008/1.059/0.046 ms SWITCH#
- Informationen -s -parametern används för att definiera nyttolaststorleken för ramen
- I ovanstående utskrift skickas en ram med en nyttolast på 8 972, vilket motsvarar en MTU på 9 000 som misslyckas.
- Efter detta skickas en nyttolast på 2 472, motsvarande 2 500 MTU som också misslyckas
- Slutligen skickas en nyttolast på 1 472 som motsvarar 1 500 MTU som lyckas
- I det här fallet bekräftades att nätverkssökvägen inte kunde ta emot en ram som är större än 1 500 MTU
- I det här specifika exemplet var problemet VLTi-portkanalen 1 000 mellan 2 x S4148U-ON på grund av OS10-defekten som beskrevs tidigare.
Efter att ha korrigerat MTU-felmatchningen och skannat om lagringen på ESXi-värden kan vi se alla protokollslutpunkter som förväntat.
Affected Products
PowerStoreArticle Properties
Article Number: 000125860
Article Type: Solution
Last Modified: 19 Apr 2021
Version: 5
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.