Pár hete tettem fel egy bejegyzést arról, hogy egy teljesen szűz, teljes mértékben kompatibilis és jól előkészített környezetbe nem települt fel a VCF legújabb verziója.
Szóval maga a Management domain tökéletesen települt – háromszor is végrehajtott próba alapján – azzal minden rendben volt.
Viszont az első workload domain telepítése minden esetben azonos hibára futott.
Maga a feladat egyszerű volt, minden szerverben négy darab fizikai hálózati interfész van és azokat fel kell használni. A Cloud Builder – a 4.0.1-es build-hez – képes ezt GUI-ról megcsinálni, de a Cloud Builder maga az nem épít meg semmi mást, csak a management domain-t.
A Cloud Builder-ről le kell tölteni egy XLS fájlt, amit ki kell tölteni, majd azt feltölteni és indítani a management domain telepítését. (Erről is írtam már egy másik posztban).
Ebben választható három opció:
- 1 vDS – 2 PNIC – Minden egyben, management VLAN,vMotion,VSAN,Host TEP, Edge TEP
- 2 vDS – 2 PNIC/VDS – Az első VDS-en management VLAN,vMotion,VSAN, a második VDS-en Host TEP, Edge TEP
- 2 vDS – 2 PNIC/VDS – az elsőn minden kivéve VSAN, a második a VSAN számára
Itt a profile 2-t volt a számomra megfelelő és ezzel nem is volt gond. A táblázat egy másik oldalon tartalmaz egy ilyet.
Attól hogy ebben a K27-es cellában „Yes” vagy „No” a válasz, teljesen függetlenül települ a management domain-ben három NSX Manager és minden hoszt rendelkezni fog 2 db TEP interfésszel. Ez a cella annyit jelent, hogy létrehozna ezeken felül még két Edge VM-et, egy Edge Cluster-ben – ennek minden járulékos vonzatával (T0,T1, uplinkek, BGP) – illetve két szegmenst. Lévén vSphere 7-ről és vDS 7.0-ról van szó, ezt ténylegesen két VDS port group-ként materializálódik a management domain vCenter-ében, a második vDS alatt – ha profile 2-t választottunk.
Viszont a K27-es cellában „No” kiválasztása esetén ez a fenti kép szürke, nem jön létre edge VM, nem lesznek szegmensek sem. A második vDS létrejön, a hosztoknak is lesz benne TEP interfészük, de jó vmkernel interfészhez hűen nem igényel PG-t.
Szóval a telepítés „No” esetén, profile-2 alapján, 2 vDS-sel simán lefut, sikeresen.
Viszont a workload domain létrehozása már SDDC Manager-ből történne, de az a GUI-ról nem lehetséges 4 fizikai hálózati interfésszel telepíteni semmit – szóval a 4.0.1 feature list csúsztat kicsit, mert ez a 4 pNIC opció GUI az pont csak a management domain-re igaz.
JSON fájlt kell megetetni az SDDC Manager-rel. Na ekkor jött a linkelt cikkben látható exception hiba.
A szerverben összesen nyolc fizikai interfész van, alaplapi 1Gbit-esek vmic0-1-2-3 és 4 db 10Gbit-es.
Több tipp érkezett:
- le kell tiltani az első négyet, nem jött be.
- akkor biztos az a baj, hogy én a JSON fájlban a VDS1-nél a vmnic4-et és a vmnic6-ot, a VDS2-nél a vmnic5-öt és a vmnic7-et akarom felhasználni. Biztos az SDDC Manager nem tudja értelmezni csak a növekvő számokat. Ezt kicsit furcsáltam, mert a fizikai interfészek felismerési és elnevezési sorrendje mindig kártyáról-kártyára megy de egy kártyán ha több port van, akkor először azokat cimkézi fel mielőtt új kártyára ugrik. Na mindegy, nem jött be persze.
- vmnic0-tól tud csak kezelni interfészeket, szóval az összes alias ennek megfelelően át lett állítva. Nem jött be ez sem.
Végső elkeseredésben a már a 2 fizikai interfészes telepítés is megkísérlésre került, a GUI-ról, akkor is azonos hiba lett a vége – a legfelső kép – pont mint az összes többi esetben.
És akkor három hét után a VMware GSS a harmadik log bundle bekérés után végül rájött, hogy az a baj, hogy az XLS-ben a K27-es mezőben „No” került kiválasztásra. Illetve nem is ez a baj, hanem hogy amiatt nem jön létre semmiféle port group/szegmens a VDS2-n, amit viszont a workload domain telepítésénél a workflow nagyon keres, de nem talál, ezért elszáll.
Following the deeper investigation by Engineering, this seems to be caused by the fact that the mgmt dvs named ‘mgmt-vds02’ which is only used for NSX-T doesn’t have any portgroups defined (which is expected behaviour). However, the GenerateViInternalModelAction doesn’t check for null value of the portgroups which is causing a NullPointerException.
A megoldás? Nem szabad „No”-t választani az AVN-nél. Gyanítom hogy egy port group manuális létrehozása sem segítene a dolgon, mert arról mégis hogy tudna az SDDC Manager, mikor azt közvetlen a vCenter-ben tesszük. A GSS javaslata alapján, magában az SDDC postgre adatbázisában kellett üres listával kitölteni egy bejegyzést – ezt a parancsot nem publikálom, mert rossz eredménye is lehet.
Összefoglaló
Úgy tűnik, hogy az XLS-ben bár megengedett „No”-t választani, de ezen a bolygón én választottam ki azt együtt a „Profile-2”-vel először és ezért jött a hiba. Az is gyanús, hogy ez átment a quality check-en, mert ha valaki „Profile-2”-t választ és az AVN-nél „No”-t, akkor garantáltan a fenti hibát kapja.
Szóval én vagyok az első ember ezen a világon aki belefutott ebbe a jól beidőzített pofonba.
És hogy ez mennyire demotivál? Különös nagy mértékben, mert egy rajtam nem múló ok miatt került egy hónap hibakeresésbe ez az egész, ráadásul esélyem sem volt/sincs egy ilyet megoldani, mert nem férek hozzá a workload domain workflow lépéseihez, hogy pontosan tudjam miért száll el.
