Hirdetés
- iPhone topik
- Szívós, szép és kitartó az új OnePlus óra
- Apple iPhone 15 Pro Max - Attack on Titan
- OnePlus 15 - van plusz energia
- Yettel topik
- Samsung Galaxy Watch5 Pro - kerek, de nem tekerek
- Fotók, videók mobillal
- Ezt az öt videót volt a legjobb megcsinálni idén
- Külföldi prepaid SIM-ek itthon
- Kezünkben a OnePlus 15 és az Oppo Find X9-ek
-
Mobilarena
Sziasztok, 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
-
válasz
bugizozi
#5091
üzenetére
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.
-
jerry311
nagyúr
válasz
kraftxld
#5085
üzenetére
Ú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.
-
jerry311
nagyúr
válasz
kraftxld
#5082
üzenetére
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 -
jerry311
nagyúr
Oké, egy hálózatos probléma megoldva.
Erre valami? -
kraftxld
félisten
válasz
TheProb
#5078
üzenetére
É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. -
-
TheProb
veterán
válasz
kraftxld
#5070
üzenetére
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é. -
kraftxld
félisten
válasz
TheProb
#5069
üzenetére
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.
-
kraftxld
félisten
válasz
TheProb
#5065
üzenetére
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ó
-
kraftxld
félisten
válasz
bmw320d4
#5063
üzenetére
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.
-
-
bmw320d4
csendes tag
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. -
Micsurin
nagyúr
Workstation 16 Player:
Lehetséges folyamatot megszakítani? Utolsó pillanatban kész projekthez akartunk adni egy plusz hálókártyát de befagyott az egész gép percenként ha 1%-ot lép. Lehet abandonolni a változást?Force close nem játszik nem veszíthetjük el most már a rendszert és a konfigot.
-
Magnat
veterán
Ü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 ...
-
bugizozi
őstag
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
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. -
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
-
[Newman]
tag
válasz
TheProb
#5042
üzenetére
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. -
-
TheProb
veterán
válasz
[Newman]
#5041
üzenetére
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.
-
[Newman]
tag
válasz
TheProb
#5038
üzenetére
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.
-
Ezen fog elvileg a Lifecycle Manager segíteni
https://blogs.vmware.com/virtualblocks/2020/06/02/vsphere-lifecycle-manager-on-hpe/ -
TheProb
veterán
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ó. -
kraftxld
félisten
-
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.
-
jerry311
nagyúr
válasz
sirály12
#5022
üzenetére
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. -
TheProb
veterán
válasz
sirály12
#5025
üzenetére
A free Veeam Agent-et ajánlanám én is. De nyilván annak is megvannak a korlátai, pl. nem tud app-aware mentést, CBT-t, etc. Bár ahol a free license elég, ott gondolom ezek nélkül is meg lehet élni.
Én pl. az otthoni CentOS alapú NAS-omat mentem vele, amin fut pár konténer. Ment szépen, bár az tény, hogy sose próbáltam még restore-olni...
-
TheProb
veterán
válasz
sirály12
#5022
üzenetére
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. -
sirály12
őstag
Ü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?
-
válasz
[Newman]
#5019
üzenetére
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]
tag
válasz
bugizozi
#5018
üzenetére
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.
-
-
Immy
őstag
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? -
jerry311
nagyúr
válasz
jerry311
#5011
üzenetére
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 -
jerry311
nagyúr
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. -
válasz
jerry311
#5005
üzenetére
Az ESXi ilyen szempontból faék egyszerű, minden a memóriából fut kb., a system diskhez nem nyúl. Ezt sokan be is szívják, mert ha smart nélküli diskre telepítik (pl. SD kártya) akár évekig is elzörög, úgy hogy közben a kártya rég döglött benne. Aztán mikor valaki felébred, hogy updatelni kéne, vagy egyéb okból rebootolni, netán jön egy áramszünet, akkor megy a pislogás hogy nem bootol be a host. Mindezzel arra akarok utalni, hogy ebből adódóan az unclean shutdown-t is nagyon jól bírja, soha nem láttam még olyat, hogy ilyen esetben sérült volna a system fs.
Szóval szerintem is az SSD-vel lesz valami, vagy egyéb kapcsolódó eszközzel (pl. vezérlő, etc..), mert nem kellene ilyet csinálnia.
-
TheProb
veterán
válasz
jerry311
#5005
üzenetére
Bár elvileg SSD-nél nem kéne, de lehet, hogy a /scratc csak a tmp-be van irányítva és a shutdown után elszáll minden log, stb. Ilyenkor láttam hasonlót. Illetve még esetleg ránézhetnél az SSD állapotára. Ugyan ezen az SSD-n van a VMFS DS is?
Itt egy leírás, ezt érdemes átnyálazni: [link]
-
jerry311
nagyúr
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.
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
- Home server / házi szerver építése
- Hobby elektronika
- Milyen videókártyát?
- Epic Store Ünnepi Ajándékozás - 12. nap: Viewfinder
- iPhone topik
- Épített vízhűtés (nem kompakt) topic
- Milyen NAS-t vegyek?
- Szívós, szép és kitartó az új OnePlus óra
- Csekély 4000 dollárért tervezetten "hibás" az ASUS limitált VGA-ja
- Bestbuy játékok
- További aktív témák...
- Gyermek PC játékok
- 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, Most Ünnepi áron! :)
- Eredeti Microsoft termékek - MEGA Akciók! Windows, Office Pro Plus, Project Pro, Visio Pro stb.
- Game Pass Ultimate előfizetések 1 - 36 hónapig azonnali kézbesítéssel a LEGOLCSÓBBAN! AKCIÓ!
- Telefon felvásárlás!! Apple iPhone 16, Apple iPhone 16e, Apple iPhone 16 Plus, Apple iPhone 16 Pro
- BESZÁMÍTÁS! ASROCK B650M R7 7700 16GB DDR5 1TB SSD RTX 3070Ti 8GB ASUS TUF GT301 GIGABYTE 750W
- GYÖNYÖRŰ iPhone 12 mini 128GB Blue-1 ÉV GARANCIA - Kártyafüggetlen, MS3415 94% Akkumulátor
- ÚJ MacBook Pro 14" M4 PRO 24GB 512GB Space Black
- Victorinox jellegű svájci bicska eladó
Állásajánlatok
Cég: Laptopszaki Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest