- Négy másodperc alatt betölt a Forza Horizon 6 a Microsoft csodatechnológiájával
- Fujifilm X
- Szentjánosbogárral venné fel a versenyt a Macbook Neo ellen az Intel
- AMD vs. INTEL vs. NVIDIA
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- 5.1, 7.1 és gamer fejhallgatók
- Fejhallgató erősítő és DAC topik
- NVIDIA GeForce RTX 5070 / 5070 Ti (GB205 / 203)
- A Linux megnégyszerezte magát a Steamen — a Microsoft ismét ígérget
- Milyen ÚJ notebookot vegyek?
- bacsis: Gyere el a 11. BRSZK-ra!
- E.Kaufmann: Optikai szál nem kell félnetek jó lesz, avagy a damil alapú hálózat
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
- LordAthis: A nagy Triple Channel Tesz: Hogyan lett egy hibás 24GB-os Kitből 1 "Tökéletes"
- sziku69: Fűzzük össze a szavakat :)
-
PROHARDVER!
PROHARDVER!Sziasztok, udvozlunk mindenkit Magyarorszag legnagyobb VMware forumjaban!
Új hozzászólás Aktív témák
-
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án
Szó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.
Grat, hogy sikerült megoldani!
Az én egyik megoldásom az lett volna, hogy felhívom a magyar VMware-s csapatot, hogy segííííííttttseeettteeeekkkkk
-
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
-
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
Én a my.vmware.com-on szoktam megnéni
-
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
-
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.
Szia!
Nem semmi feladat, le a kalappal
Hogy sikerült feltámasztani? -
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. -
Mikrotik, nincs rajta semmi extra.
Csak 2 VLAN, a másodikat akár le is szedhetnám, mert nem használja semmi, de mindegy, mert minden VLAN 1-ben van ESXi-ben és egy porton: 3.
A másik port (ha bedugnám a Mikrotikbe) csak az ESXi menedzsment, 0 VM. Viszont ha egy switchben vannak, akkor loop van.# dec/17/2020 20:02:23 by RouterOS 6.47.7
# model = CRS309-1G-8S+
/interface bridge
add admin-mac=74:4D:28:52:41:2C auto-mac=no comment=defconf name=bridge
/interface ethernet
set [ find default-name=ether1 ] l2mtu=9092 mtu=9000
set [ find default-name=sfp-sfpplus1 ] advertise=10M-half,10M-full,100M-half,100M-full,1000M-half,1000M-full,10000M-full comment=uplink l2mtu=9092 mtu=9000
set [ find default-name=sfp-sfpplus2 ] l2mtu=9092 mtu=9000
set [ find default-name=sfp-sfpplus3 ] advertise=10M-half,10M-full,100M-half,100M-full,1000M-half,1000M-full,10000M-full comment=ESXi l2mtu=9092 mtu=9000
set [ find default-name=sfp-sfpplus4 ] l2mtu=9092 mtu=9000
set [ find default-name=sfp-sfpplus5 ] advertise=10M-half,10M-full,100M-half,100M-full,1000M-half,1000M-full,10000M-full l2mtu=9092 mtu=9000
set [ find default-name=sfp-sfpplus6 ] auto-negotiation=no l2mtu=9092 mtu=9000
set [ find default-name=sfp-sfpplus7 ] auto-negotiation=no l2mtu=9092 mtu=9000
set [ find default-name=sfp-sfpplus8 ] auto-negotiation=no l2mtu=9092 mtu=9000
/interface vlan
add interface=sfp-sfpplus3 mtu=9000 name=vlan2 vlan-id=2
/interface bridge port
add bridge=bridge comment=defconf interface=sfp-sfpplus1
add bridge=bridge comment=defconf interface=sfp-sfpplus2
add bridge=bridge comment=defconf interface=sfp-sfpplus3
add bridge=bridge comment=defconf interface=sfp-sfpplus4
add bridge=bridge comment=defconf interface=sfp-sfpplus5
add bridge=bridge comment=defconf interface=sfp-sfpplus6
add bridge=bridge comment=defconf interface=sfp-sfpplus7
add bridge=bridge comment=defconf interface=sfp-sfpplus8
/interface bridge vlan
add bridge=bridge tagged=sfp-sfpplus1,sfp-sfpplus3 vlan-ids=2,1
/system routerboard settings
set boot-os=router-os -
Mikrotik, nincs rajta semmi extra.
Csak 2 VLAN, a másodikat akár le is szedhetnám, mert nem használja semmi, de mindegy, mert minden VLAN 1-ben van ESXi-ben és egy porton: 3.
A másik port (ha bedugnám a Mikrotikbe) csak az ESXi menedzsment, 0 VM. Viszont ha egy switchben vannak, akkor loop van.# dec/17/2020 20:02:23 by RouterOS 6.47.7
# model = CRS309-1G-8S+
/interface bridge
add admin-mac=74:4D:28:52:41:2C auto-mac=no comment=defconf name=bridge
/interface ethernet
set [ find default-name=ether1 ] l2mtu=9092 mtu=9000
set [ find default-name=sfp-sfpplus1 ] advertise=10M-half,10M-full,100M-half,100M-full,1000M-half,1000M-full,10000M-full comment=uplink l2mtu=9092 mtu=9000
set [ find default-name=sfp-sfpplus2 ] l2mtu=9092 mtu=9000
set [ find default-name=sfp-sfpplus3 ] advertise=10M-half,10M-full,100M-half,100M-full,1000M-half,1000M-full,10000M-full comment=ESXi l2mtu=9092 mtu=9000
set [ find default-name=sfp-sfpplus4 ] l2mtu=9092 mtu=9000
set [ find default-name=sfp-sfpplus5 ] advertise=10M-half,10M-full,100M-half,100M-full,1000M-half,1000M-full,10000M-full l2mtu=9092 mtu=9000
set [ find default-name=sfp-sfpplus6 ] auto-negotiation=no l2mtu=9092 mtu=9000
set [ find default-name=sfp-sfpplus7 ] auto-negotiation=no l2mtu=9092 mtu=9000
set [ find default-name=sfp-sfpplus8 ] auto-negotiation=no l2mtu=9092 mtu=9000
/interface vlan
add interface=sfp-sfpplus3 mtu=9000 name=vlan2 vlan-id=2
/interface bridge port
add bridge=bridge comment=defconf interface=sfp-sfpplus1
add bridge=bridge comment=defconf interface=sfp-sfpplus2
add bridge=bridge comment=defconf interface=sfp-sfpplus3
add bridge=bridge comment=defconf interface=sfp-sfpplus4
add bridge=bridge comment=defconf interface=sfp-sfpplus5
add bridge=bridge comment=defconf interface=sfp-sfpplus6
add bridge=bridge comment=defconf interface=sfp-sfpplus7
add bridge=bridge comment=defconf interface=sfp-sfpplus8
/interface bridge vlan
add bridge=bridge tagged=sfp-sfpplus1,sfp-sfpplus3 vlan-ids=2,1
/system routerboard settings
set boot-os=router-osvswitch-ben ez hogy néz ki? melyik mikrotik portokra dugnád rá?
-
É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.Magyarul? User error vagy ilyen faszák a huawei sw-ek?
-
+1
STP bibi más szimptómákkal szokott járni, mint szar sávszél/latency.
Ott a legjellemzőbb hibajel, hogy flappinggelnek a portok.É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é. 20 fős cég, kis foci
Jaja a switch-en jumbo frame van, a VMware-on szabvány 1500-as MTU.
Lehet debuggolni, csak ésszel, a switch-et nem rugnám le, de esténként lehet a szerverrel játszani mert van iDrac. -
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.
Jaaa, azt hittem ez valami labor, mert eléggé ortopédnak tűnik ez az infra.
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é. -
L2 részen néznék körbe, mert ha jól értem, kvázi minden forgalom böszme lassú. Nem tudsz másik switch-et kipróbálni? Netán direktben összekötni a 2 host-ot, csak a test erejéig? MTU size-ok pl. egyeznek?
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ó
-
Van itt nekem egy ESXi.
2 hálókártya, 2 vSwitch, 1 kártya / vSwitch.
Ha mindkettő uplinkje ugyanazon a fizikai switchen van, akkor loop van döglött hálóval. Ha két külön switchre csatlakoznak akkor minden szép.
Miért loopol ha az ESXi nem bridgel?Na, a licenszelős emberek után a hálózatos arcok azok akik minden deploymentet megkeserítenek
-
Nem mai vasak, vmware HCL szerint vannak támogatott fw-ek, stb.?
Most akkor mi is a setup, mindkét DELL-en ESXi van és azok közt lassú a vMotion?
A képeken látható Win hol helyezkedik el a infra hierarhiában?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.
-
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. -
-
Sziasztok
Nem vagyok tapasztalt de az lenne a kérdésem hogy Vmware alatt win 7 operációs rendszert használok és egy bizonyos használati idő után mindig belassul a rendszer lassan nyitja meg az alakmazásokat browsert stb.. Mit tudok tennni hogy megfelö kondicióban maradjon.
Köszönöm a válaszokat. -
Sziasztok
Nem vagyok tapasztalt de az lenne a kérdésem hogy Vmware alatt win 7 operációs rendszert használok és egy bizonyos használati idő után mindig belassul a rendszer lassan nyitja meg az alakmazásokat browsert stb.. Mit tudok tennni hogy megfelö kondicióban maradjon.
Köszönöm a válaszokat. -
Üdv,
16-os Workstationon már nem lehet megmondani bridged csatolónál, h melyik NIC-re csatlakozzon? Csináltam tesztjelleggel egy virtuális gépet Xpenology-val (bridged auto) és APIPA ip-t kap a gép ... ha nat-ra állítom, akkor 192.168.168.x-ből kap rendesen ip-t, csak nem ez lenne a cél ...
Virtual network editor-ban.
-
https://www.virten.net/2020/07/vmware-esxi-7-0-io-devices-not-certified-for-upgrade/
Ha 82599ES akkor lehet azért.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
-
Intel 82599 10 Gbit hálókártya van benne, ugyanaz, mint a másik 2 szerverben. Nem volt fw frissítés.
Megpróbáltam downgrade-elni 6.7-re, de a recovery módnál azt írta, hogy csak 7 verziót tud bootolni, nem talál régebbit, ha bebootoltam a 6.7 ISO-t azzal sem lehetett "update"-elni, mert not supported. -
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
-
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
-
Nos:
Today HPE has two integrations for vLCM:
- HPE OneView Hardware Support Manager for vLCM is delivered via the OV4VC appliance
- HPE Hardware Support Manager for vLCM is delivered via the iLO Amplifier Pack appliance
Fontos hogy amit OveView kezel, azt nem kezelheti ILo Apmlifier és fordítva. -
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.
-
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.
-
A HPE küldött el, mert olyan FW/driver kombót használtam ami csak a VMware HCL-jében szerepelt mint támogatott a HPE adott szervere kapcsán. Synergy-ről van szó. HPE szerint ez az oldal a szent. [link]
Picit átfedésben van, de az ILO Apmlifier pack csak a hatodára alkalmas annak amit a Oneview tud, illetve kicsit jobban tolja az adatot az Infosight-ba.
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.
-
-
ESXi FW/BIOS frissítésnél ki melyik oldalra szokott hallgatni, a VMware vagy a HW Vendor általi compatibility-re? Sajnos jellemzően nincsenek fedésben a 2 oldali eredmények és ha gond van, akkor mindenki a saját listájra szerinti verziókra fog mutogatni.
Meg az se segít, hogy pl vmware compatibility alapján egy NIC-re ad 25633 találatot és akkor mazsolázd ki, hog melyik fw verzió lehet a jó. -
Leállítod a guest-et és (minden) datastore-ból lemented a hozzá tartozó fájlokat.
Megteheted GUI-ban (Datastore browser), vagy ha elég ügyes vagy, akkor írsz egy scriptet, ami becsatlakozik SCP-n, és letölti amit beleírtál.
Fapados, viszont megvannak a VM beállítások és a VHD is.Ez nem is rossz ötlet. Ezt megpróbálom.
Meg is néztem winscp-vel hozzáférek. Írok valami egyszerű scriptet hozzá, és nekem tökéletes lesz. -
-
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.
-
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.
Milyen CPU van benne?
-
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.
-
Üdv mindenkinek.
Egy olyan kérdésem lenne a nálam jobban hozzáértőkhöz, hogy van nekem egy vmware esxi 6.5 free rendszerrel üzemeltetett gépecském, ami az itthoni dolgaimat szolgálja ki. Ezen van 4 linux, és szeretném néha menteni őket nagyobb változtatások előtt. Tehát free esxi 6.5-el mi a legegyszerűbb megoldás a teljes mentésre egy virtuális gépnél?
-
-
Szia!
A free-ben le van tiltva az API is minden egyéb feature, amivel tudnál épképzláb módon VM szintű bkp-t csinálni.
Marad a guest OS level mentés vagy régebben találkoztam egy custom script-el, amivel állítólag lehetne VM mentést csinálni. De nem foglalkoztam vele különösebben.+1
ESXi-n keresztül nem tudod menteni. Veeam-mel tudod, ha feltelepíted mind a 4 Linux-ra az Agent-et.
-
Üdv mindenkinek.
Egy olyan kérdésem lenne a nálam jobban hozzáértőkhöz, hogy van nekem egy vmware esxi 6.5 free rendszerrel üzemeltetett gépecském, ami az itthoni dolgaimat szolgálja ki. Ezen van 4 linux, és szeretném néha menteni őket nagyobb változtatások előtt. Tehát free esxi 6.5-el mi a legegyszerűbb megoldás a teljes mentésre egy virtuális gépnél?
-
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 -
Felmerül pár kérdés, hogy pontosan hogy történt. Kikapcsolgatta a VM-eket a szkript és utána pl mountolta valahol a datastore-t aztán titkosította? Nem tartom valószínűnek, hogy magán az ESXi-n "keresztül" történt volna.
Írja a thread-ben pár "It's FC storage. Only accessible thru ESXi or vCenter." illetve "Block. Fibre channel storage." Ettől függetlenül simán lehet, hogy az adott LUN, akárhová máshová is ki van adva, ott simán titkosítható - pl Veeam B&R storage integrált mentés. Írják is neki, hogy "My NDA won't allow that to be disclosed." szóval semmi specifikum.
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 -
Van közös storage? Ha nincs, akkor nem tudok olyan okot mondani ami miatt lenne értelme őket egy klaszterbe tenni (pl HA miatt).
Nincs közös storage.
Azon gondolkoztam, hogy esetleg ha vm-et akarok egyik esxi-ről a másikra költöztetni akkor gyorsabb vagy kényelmesebb lehet, de végső soron ezért is kérdezem a szakértőket itt a fórumon -
Sziasztok,
Jelenleg 2 különálló ESXi servert managelek egy közös vCenter Essentials licencel. Hamarosan mindhárom eszközön ugyanolyan 7.0U1 verzió lesz.
Tudtok segíteni abban, hogy milyen előnyökkel járna ha a 2 különálló servert 1 clusterbe tenném anélkül, hogy nagyobb licencet kelljen vásárolni? -
Sziasztok!
Hatha tudtok itt segiteni. A problemam, hogy manjaro kde rendszert hasznalok, es ez alatt kellene vmware horizonon keresztul egy tavoli virtualis gepet hasznalnom. Minden oke, van kep, van hang, csak a mikrofon nem jo.
Sem a laptop mikrofonja, sem a (jack -es) fejhallgato mikrofonja.
A virtualis gep egy windows 7, annak a hangbeallitasaban a felvevo resznel van egy eszkoz, de ott sem erzekel semmit.
Manjaro kde alatt ha egy alkalmazas hasznalja a mikrofont, akkor megjelenik a talcan egy ikon errol, hogy valami hasznalja a mikrofont. Ez vmware haszanalatkor nem tortenik meg.
Valakinek otlet? -
Kicsit részletesebben kiolvasva SMARTotnincs ennek semmi baja.
5 Reallocated_Sector_Ct 0x0032 100 100 --- Old_age Always - 0
...
230 Unknown_SSD_Attribute 0x0032 100 100 --- Old_age Always - 11373090179672
232 Available_Reservd_Space 0x0033 100 100 004 Pre-fail Always - 100
233 Media_Wearout_Indicator 0x0032 100 100 --- Old_age Always - 7933 -
Kezdjük az elején...
/scratch az SSD-re megy:
lrwxrwxrwx 1 root root 49 Sep 30 19:10 scratch -> /vmfs/volumes/5f74d79a-721df731-426d-d8d3859f5f00Az SSD SMART is jónak tűnik. Ezt alátámasztja az is, hogy soha egyik VM-nek sem volt problémája az elmúlt években (és most sem) erről az SSD-ről, csak az ESXi problémázik vele, ha éppen olyan kedve van.
[root@localhost:~] esxcli storage core device smart get -d t10.ATA_____SanDisk_Ultra_II_960GB__________________154387412673________Parameter Value Threshold Worst---------------------------- ----- --------- -----Health Status OK N/A N/AMedia Wearout Indicator 100 0 100Write Error Count N/A N/A N/ARead Error Count N/A N/A N/APower-on Hours 100 0 100Power Cycle Count 100 0 100Reallocated Sector Count 100 0 100Raw Read Error Rate N/A N/A N/ADrive Temperature 68 0 66Driver Rated Max Temperature N/A N/A N/AWrite Sectors TOT Count 253 0 253Read Sectors TOT Count 253 0 253Initial Bad Block Count N/A N/A N/A[root@localhost:~]
Egyelőre ennyit sikerült összehozni. -
Kéne nekem valami induló ötlet...
Hosszabb áramtalanítás után (több mint 5 perc) bootolás közben elhal az ESXi 6.7. Itt korrupt, ott korrupt, load error, buffer too small, nem mindig ugyanaz. Ilyenkor csak a reinstall segít, szerencsére a VM-ek megmaradnak, de hát azért mégiscsak jó lenne, ha egy tervezett áramszünet (=rendes lekapcsolás, nemcsak power off) utánra nem kellene minden alkalommal reinstall is.PS: Bootolás SSD-ről történik, ami az alaplapra csatlakozik közvetlen, semmi RAID vagy ilyesmi.
-
Kéne nekem valami induló ötlet...
Hosszabb áramtalanítás után (több mint 5 perc) bootolás közben elhal az ESXi 6.7. Itt korrupt, ott korrupt, load error, buffer too small, nem mindig ugyanaz. Ilyenkor csak a reinstall segít, szerencsére a VM-ek megmaradnak, de hát azért mégiscsak jó lenne, ha egy tervezett áramszünet (=rendes lekapcsolás, nemcsak power off) utánra nem kellene minden alkalommal reinstall is.PS: Bootolás SSD-ről történik, ami az alaplapra csatlakozik közvetlen, semmi RAID vagy ilyesmi.
![[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
- Poco X8 Pro Max - nem kell ide sem bank, sem akkubank
- Autós topik
- BestBuy ruhás topik
- A fociról könnyedén, egy baráti társaságban
- Abarth, Alfa Romeo, Fiat, Lancia topik
- Négy másodperc alatt betölt a Forza Horizon 6 a Microsoft csodatechnológiájával
- Villanyszerelés
- Windows XP
- Xbox Series X|S
- Fujifilm X
- További aktív témák...
- HP EliteBook 640 G11 Core Ultra 5 125U 16GB 512GB FHD 1 év gar
- 3440 x 1440 100Hz!!! 65W PD 34" CURVED 1800R Samsung C34H890WGR - 1 év garancia!
- BESZÁMÍTÁS! ASUS B450 R7 2700 16GB DDR4 512GB SSD RTX 2070 SUPER 8GB ASUS ROG Strix GA15DH Adata600W
- Samsung 990 EVO 2TB M.2 NVMe SSD
- ÁRGARANCIA! Épített KomPhone R7 5700X 16/32/64GB RAM RX 9060 XT 16GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: aiMotive Kft.
Város: Budapest
Cég: Laptopműhely Bt.
Város: Budapest