-
Fototrend
FototrendSziasztok, udvozlunk mindenkit Magyarorszag legnagyobb VMware forumjaban!
Új hozzászólás Aktív témák
-
Na igen
Itt kicsit bonyolultak voltak a "politikai viszonyok", és a felettük álló szervezet (akiktől anno a kulcsokat kapták) többszöri megkeresésre is elhajtotta őket. Customer portálos hozzáférésük pedig csak nekik van.Mondjuk esélyes hogy ezért is nem találok a témában semmit, normális emberek belépnek és megnézik ott
-
Ne is kérdezd, azzal indult, hogy a root pass nem hogy lejárt, de nem is tudták mi volt (amit megadtak, azzal nem működött konzolon sem). Nem tudom csináltál e már root pw resetet vcsa-n (én eddig nem), de most szembesültem vele, hogy 6.0-ig a GRUB-ra is rárakja ugyanezt a jelszót! Szóval nem úgy van az, hogy init=/bin/bash aztán jót röhögünk... Persze mire mindezt átnézi az ember, live linux alá mountolja, megpatkolja a grubot, sok óra megy el
Utána meg annyi volt csak, hogy vissza kellett menni a kályhához, és szolgáltatásonként egyesével áttúrni a logokat, és a bennük levő problémákat megoldani. Persze a sorrend feltérképezése is egy jó szívás, hiszen sok servicenek csupán annyi baja van, hogy függ egy másiktól, egyébként elindulna.Amúgy használhatóra nem hinném, hogy meg tudtam csinálni, egy halom alert volt rajta, de legalább a webservice és az sso ment, be lehetett lépni, ctrl+c a linecenkre, aztán delete from disk a vm-re + sóval behinteni a helyét is
Csak az idegsít még, hogy milyen kalapból/honnét rántotta elő végül a kulcsokat, nagyon érdekelne ennek a megfejtése
-
Chal
addikt
Pár hete belefutottam egy idióta feladatba, azóta nem hagy nyugodni a dolog, és most lett időm írni róla: ügyfélnél volt egy évek óta megdöglött VCSA 6.0, 3db hosttal, Essentials Plus csomag. Más munka farvizén előálltak a kéréssel, hogy ha már ott vagyok, akkor segítsek feltámasztani a vcsa-t, vagy telepíteni egy újat. Nyilván az utóbbi mellett döntöttem, túl rövid az élet egy halott (ráadásul 6.0-ás) vcsa életre rugdalásához + upgradejéhez. Igen ám, de sikeresen elhagyták a licence kulcsokat. Ennek kapcsán elkezdtek köröket futni, de a vége az lett a dolognak, hogy nem volt más megoldás, ki kell valahogy bányásznom a halott vcsa-ból őket.
A probléma a szokásos volt vele: elfogyott a hely, és ezt sikerült tovább fokozni azzal, hogy megpróbálták megjavítani. Ennek hatására gyakorlatilag teljesen kinyírták (azt sem tudták megmondani, hogy pontosan mivel próbálkoztak, mert régen volt), ezen felül lejárt a root pass, az ssl certek, machine accountok, psc, directory service nem indul, minden halott gyakorlatilag. Az embedded postgres db viszont működött, konzisztens volt, nem sérült (azon a partíción nem fogyott el a hely). A *_lic_* táblák teljesen üresek voltak (a többiben viszont láthatóan ott voltak az élő adatok). Erre találtam egy KB-t, ami ugyan licence manuális törlésére vonatkozik, viszont megerősíti, hogy a lic_* táblákban kellene lenniük.
Kínomban már ki is dumpoltam, és a dump file-ban kerestem, de semmi eredménye nem volt a dolognak, átnéztem az egészet, biztosan nem volt benne. Végül elkezdtem a javítást. Több mint 1 munkanapom ment rá, és sikerült talpra állítani azt a szart, a webes guin pedig ott voltak a kulcsok. A DB miatt 90%-ra biztos voltam benne, hogy nem így lesz, ne kérdezzétek hogy miért csináltam végig mégis a javítást, nem tudom, hajtott az ideg egy idő utánSzóval happy end a vége, de marhára érdekelne, hogy mi lett volna az a megoldás, amivel azt a 10 órányi munkát le tudtam volna spórolni ami a javításból adódott. Szívott már valaki ilyennel? Hol tárolja a licenceket a VCSA? Grepeltem a teljes filerendszerén is (a hostok kulcsa ugye adott volt egy jó "nyomnak"), túrtam az összes releváns fórumot, gyári doksikat, kb-ket, de még csak hasonló kérdést sem találtam, nem hogy választ.
-
Úgy döntöttem, hogy egy képpel ábrázolom inkább a hibát.
(na jó, azért az is "segített" a loop létrehozásában, hogy az egyik switchport fix 'edge'-re volt állítva, úgyhogy a STP sosem tette block-ra.)Mindenkinek köszönöm a segítséget, megint a user volt a hülye, nem az eszköz.
-
És ez a szerencséje ennek a fosnak, hogy 18 ezer km-re van, már már ott lennék a város főterén és 30L benzinnel lelocsolva égne a switch stack
A migráció alatt az egyik Unifi AP-t nem vitte át a controller migráció, a helyi IT-s arc megkereste, hogy melyik porton volt. Ezt a portot átraktam VLAN99 access-re, hogy lássam az AP-t, firmware frissítés, provisioning. Majd a controlleren átállítottam a management portot VLAN 99 tagged-re.
Utána a switch-en is visszaállítottam a vlan-okat és megoldódott a network hiba
Full ugyanaz a konfig. -
Jaaa, azt hittem ez valami labor, mert eléggé ortopédnak tűnik ez az infra.
![;]](//cdn.rios.hu/dl/s/v1.gif)
De látom, jumbo frame-re van állítva a port(ok), nem default size-ra. Feltételezem ez az ESXi-okon is így van.
Nem láttam még hüvely switch-et élőben (meg máshogy sem), de pl. mikrotik-nál nagyon szar tud lenni a teljesítmény, ha nem HW-esen akar valamiért switch-elni.
Így picit nehézkes lesz a debug, hogy a világ másik végén van a szajré. -
Igen, minden forgalom lassú, hááátt. 18 ezer km-re van a cucc, nem nagyon tudok átugrani és switch-ekkel matatni
A switch portok ilyenek ezen csoda Huawei-en (hogy döljön rá egy taligányi pandaszar arra aki ezt a kínai fost eladta az ügyfélnek), nincs SSH access, és csak trunk port-ként tudom beállítani, hogy az összes VLAN átmenjen.
-
Mindkettő rajta van az ESXi 7.0 U1 HCL-en. Firmware-t frissítettem.
Mindkettőn ESXi van, local storage.
A vmotion lassú ha az alap 100-as VLAN-on csinálom és ugyanúgy felmegy a latency
Ha átrakom a vmotion-t a 130-as VLAN-ra akkor is ugyanez.
Ez egy Windows-os VM az egyik host-on, a 100-as VLAN-on csatlakozik iSCSI-n egy Synology NAS-re. Ez a Veeam ReFS repository.
Ha elindítom a Veeam mentést ugyanez a hiba, hogy max 15MB/sec-el megy a folyamat és a latency is megnő.
Ha indítok egy AzCopy-t bármelyik VM-ről akkor is ez történik, korábban a Hyper-V-ről simán tolta 500Mbit-el Azure Blobba a biteket.Szerk, most indítottam egy Veeam replikációt a 2 host között, ez is hasonló sebességgel megy. 1ms alatt van a latency ha nincs terhelés a hálón, alatta a latency ha megy a replikáció
-
Kicsit meg vagyok lőve ezzel a setup-al.
Egy Dell T430-as meg egy Dell R330-as szerver. Broadcom 5720-as hálókártyák.
Legfrisebb Dell ESXi 7.0 U1 image rajtuk, pár VM-et migráltam rá hyper-v-ről.
Semmi komplex cucc, egy management / computer VLAN meg két másik VLAN amin egyéb cuccok vannak.
Huawei S1720-as switch-ek, hálókártyák aktív / passive módban vannak.A vmotion meg bármilyen hálózati dolog mocsok lassú, elér max 150Mbit-et és atom latency jön mindenfelé. Ha átraktam a vMotion-t egy másik VLAN-ra akkor is.
A veeam mentés egy iSCSI-n csatlakoztatott Synology NAS-re, ezt ha elindítom akkor is ugyanez a helyzet mint a vMotion-nál, max 150Mbit, magas latency.
Ötletek, hogy mi lehet? Hyper-Vn előtte nem volt ilyen gond.
-
Láttam, hogy van többféle 82599, hogy tudom megnézni, hogy ez ES-e?
Bár ha jól értelmezem a cikket akkor ez valószínű ES, mert ennek hálókártyának nem frissült a driver-e. A "jó" szervernek 1.8.9.0 a driver verziója, míg a "rossz" szervernek 1.7.1.28. Pedig ugyanazt azt ISO-t használtam. A VMware oldalán megtaláltam a frissebb drivert [link] Ebből már csak egy ISO-t kellett kreálni és remote console-on felmountolni az ESXi-hez, lévén, hogy hálózaton nem elérhető.
How to Mount the Host CD-ROM to the ESXi Shell
Ezután megfrissítve a drivert elérhetővé vált a hálózaton az ESXi.
Reggel úgy voltam vele, hogy ez rutin munka, fél óra alatt megleszek vele, így délután 4 óra után úgy érzem bezárom mára a zinternetet
-
bugizozi
őstag
Sziasztok!
Találkozott már valaki olyannal, hogy ESXi upgrade 6.7 -> 7.0 után nincs hálózat? A network adapterek disconnected állapotban vannak
ESXi 6.5-ről indult az egész, 6.7-nél mindig ok, 7.0-nál meg nem lehet elérni hálózaton.
Ráadásul 2 db Supermicro 2019 szervert már megfrissítettem minden gond nélkül, ez egy Supermicro 2029 lenne.update: közben hálókábel kihúz-bedug, átváltott connectedre, de mégsem érhető el, nem pingel, nem jön be a webes felület
-
Na ezt mondom. Viszont ha VMware SR kapcsán merülne fel ez, akkor tuti, hogy a VMware HCL lenne a szentgrál. És ilyenkor jön a megszokott egymásra mutogatás. Az ügyfél meg közben nézi, ahogy ég a ház...
És akkor most ez az ILO Apmlifier pack must have a LCM-hez vagy ha van OV, akkor abból is be tudja húzni, amit kell neki?
Nálunk is épp zajlik a synergy beszerzés, beüzemelés.
-
pumukli93
csendes tag
Sziasztok!
Lenne egy olyan problémám, hogy van egy Dell SC1420-as szervergép. BIOS: A04
Próbáltam már az ESXI 6.0,6.5,7.0 verziókat felhúzni rá, de unsupported CPU-val eldobott.Próbáltam a nocheckCPUIDLimit parancsot telepítés előtt a SHIFT+O lenyomása után beírni, de ugyanúgy eldob.
Melyik ESXI verzió futna szerveren, mert nekem már ötletem nincs.
Csak tesztkörnyezetnek menne, nem élesben lenne használva.
-
Bárhogy is volt, igazából nem áll sokból az API-n keresztül futtatni valamit egy trójaival, sőt, sokkal bonyolultabb lenne egyéb rendszerekre vadászni. Ugyanis azt írja, hogy a datastore-on ott volt a ransom note, szóval ha a lun-t érte el, akkor azt olyan valamin keresztül kellett tennie, ami tudja írni/olvasni a vmfs-t, ami azért ritka. Vagy B verzió, hogy storage API-val rendelkező dolgon keresztül érte el, de akkor ugyanott vagyunk ahol voltunk, max a jump rendszer nem egy esxi host vagy a vcenter, na bumm.
Viszont szerintem egyszerűbb akkor már azokat (mármint a hostokat vagy a vcentert) célba venni, minek keresgélni ilyen egzotikumokat? Nem mondom hogy így volt, csak azt, hogy ha már ilyesmire adnám a fejem, én a kisebb erőfeszítés felé haladnék, és az ez. A C verzió meg az, hogy működik így is meg úgy is, végül is a busás haszon reményében megéri a befektetett energia
Igazából az a csoda, hogy eddig még nem tett ebbe senki munkát, de úgy látszik ennek is vége
![[Newman]](http://cdn.rios.hu/dl/faces/c21.gif)
Utána meg annyi volt csak, hogy vissza kellett menni a kályhához, és szolgáltatásonként egyesével áttúrni a logokat, és a bennük levő problémákat megoldani. Persze a sorrend feltérképezése is egy jó szívás, hiszen sok servicenek csupán annyi baja van, hogy függ egy másiktól, egyébként elindulna.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
ESXi-n keresztül nem tudod menteni. 
Új hozzászólás Aktív témák
- Adobe Előfizetések - Adobe Creative Cloud All Apps - 12 Hónap - 15% AKCIÓ
- Számlás!Steam,EA,Epic és egyébb játékok Pc-re vagy XBox!
- Bitdefender Total Security 3év/3eszköz! - Tökéletes védelem.
- Eladó jogtiszta, Windows 11/10, Office 2019/2021/2024, Fizikai és Digitális licencek, Számlával.
- The Elder Scrolls Online Imperial Collector s Edition
- 5G LTE! Whitespotos, Microsoft Surface Pro 8 i7-1185G7 16GB 512GB 1 év garancia
- Felújított laptopok számlával, garanciával! Ingyen Foxpost/PostaPont!
- ÁRGARANCIA!Épített KomPhone i5 14600KF 32/64GB RAM RX 9070 16GB GAMER PC termékbeszámítással
- Apple iPhone 16 128 GB Ultramarine 96% Akkumulátor 2026.07.10-ig Garancia Beszámítás Házhozszállítás
- Apple iPhone 13 Pro 128GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest