-
Fototrend
Sziasztok, udvozlunk mindenkit Magyarorszag legnagyobb VMware forumjaban!
Új hozzászólás Aktív témák
-
válasz
kenwood
#6213
üzenetére
PCI passthrough-val oda tudni adni a kártyát a vm-nek, és menni fog a dolog. Hogy milyen vlanok lesznek, tagged vagy untagged, annak innét semmi köze nem lesz az esxi-hez, ugyanúgy kell eljárni mintha fizikai gép fizikai NIC portjai lennének. Ha a teljes kártyát nem tudod odaadni a vm-nek, akkor SR-IOV képes kártya kell, vagy olyan, aminek minden portja külön pci-e eszközként látszik a buszon.
Aztán persze ha van enterprise plus licensz, meg distributed vswitch, akkor az tudni fogja natívan az LACP-t hypervisor szinten, ez is egy megoldás lehet, de mivel csak "esxi"-t írtál, így gondolom ilyesmi nem játszik.
-
Jól látom, hogy teljesen törölték a vizsgáknál a tanfolyam kötelezettséget?
https://www.broadcom.com/support/education/vmware/certification/vcp-dcv
https://docs.broadcom.com/doc/vmware-certifcation-tracks-presentation -
válasz
MrSealRD
#6194
üzenetére
Ha a diskeknek nincs baja, akkor szerintem döglődik a raid controller, lehet véletlen egybeesés, hogy a pendrive (vagy az usb controller/hub) is. Persze ennek elég kicsi az esélye, így inkább alaplap vagy egyéb probléma a géppel. Jól gondolom, hogy Microserver Gen8? Tudom, hogy még mindig kedvelik sokan, aminek jó oka van, de nagyon öreg vasak már ezek, eljárt felettük az idő, csoda hogy még mennek. Esetleg próbáld meg meghajtani a gépet, raid tömböt más OS-el (pl. live linux usb-ről).
Ha engedik a lehetőségek, én a helyedben kicserélném valami másra, és Proxmoxra váltanék sw raid-el. A mai CPU-k mellett már nincs sok értelme a raid hba-knak, több gond van velük, mint amennyi előnyük van, már az enterprise világban is elavult megoldásnak számítanak. Otthonra esxi hw raid-el meg pláne önszívatás kategória már.
A pendrive-ot én simán dd-vel menteném le.
-
válasz
kraftxld
#6166
üzenetére
Gondolkodtam, meg olvasgattam kicsit, az igazsághoz hozzátartozik az is, hogy a Vmware a gyári CPU virtualizációt fogja használni a három OS-en, de ez csak egy API, és a saját layerében ettől még ad/adhat rengeteg pluszt, drivereket, guest optimalizációt/integrációt, gpu támogatást, stb.. -t. Összeségében lehet a mostanitól akár jobb végeredmény is, várjuk ki a végét, kérdéses, hogy melyik platformon mi fog ezekből megvalósulni, és milyen minőségben.
Linux esetén a KVM tiszta ügy, viszont Windows esetén ez nem tudom hogy néz ki pontosan, de találtam arra vonatkozó doksikat, hogy magában az ntkernelben van hasonló, de kell hozzá a hyper-v feature telepítése, ha valaki saját appot akar fejleszteni rá.
MacOS esetén nekem is újdonság volt, hogy szintén van ilyen, Virtualization Framework a neve. Itt nagy kérdés, hogy mi lesz a Windows (mármint az arm-os) támogatással.
-
Na és azt láttátok, hogy Linuxon KVM alapú lesz, Windowson meg hyper-v? Így aztán nem meglepő a lépés, kb. egy frontend lesz a vége
-
válasz
bugizozi
#6155
üzenetére
Szerintem az alap koncepciónak mennie kellene, de nem teljesen értem mi történt. Maga a passthrough enabled lett host reboot után, de a bekapcsoláskor a fenti hibaüzenetet kaptad? Mert ez alapján a passthrough nem működik jól. Addig feleslegesen keresgélsz linket, amíg az nem megy. A kártyára direktben van kötve a tape library, nincs rajta más?
Kósza tipp: én megpróbálnám kikapcsolni a félhalott passthrough-t (legyen minden az eredeti kiinduló állapotban), TL-t lehúznám, hogy ne legyen link, host restart, majd megpróbálnám bekapcsolni újra. Addig kell masszírozni, amíg hibaüzenet nélkül sikerül bekapcsolni, ha ez nem megy, akkor support.
-
válasz
bugizozi
#6141
üzenetére
Ez érdekes, tisztán emlékeztem rá, hogy úgy 1 éve csináltam, még az ügyfélnek is megírtam, hogy így működik, megkerestem a levelet, válaszolt is, hogy tényleg, kipróbálta, köszöni.
Valamint: https://community.spiceworks.com/t/vsphere-essentials-plus-kit-storage-migration/832778
Ehhez képest ránézve most ugyanarra essentials plus -os clusterre, ugyanazt látom amit te, pedig nem lett frissítve. Egyébként akkor biztosan úgy működött, hogy a storage vmotion job is elindult, majd beledöglött egy licence error hibaüzenet formájában, de "both" opcióval szépen lefutott több esetben is. Furcsa.
-
válasz
babszon
#6097
üzenetére
Én is felkaptam erre a fejem. Szerintem a Centos nagyon rég kihullott már mindenhol, 2021-ben kaszálták el, maintenance updateket kap idén júniusig (és ezt akkor jelentették be, szóval ha használták is valahol még, volt már idő bőven kivezetni). Én utoljára enterprise termékben vmware appliancekben láttam, még a Photon előtt, nagyon régen. Melyik HPE storage-ban van (volt?) Centos amúgy?
Egyébként mivel opensource, nyilván mindenki azt csinál vele amit akar, megfelelő stábbal, meg pénzzel lehet bele backportolgatni a dolgokat, meg talpon tartani, csak akkor az már nem is Centos, meg hát eleve minek?
-
válasz
bugizozi
#5974
üzenetére
Fakeraid fos, ezeknél a driver biztosítja szoftveresen a raid funkciót, ha nincs driver, külön látod a diskeket. Szóval az nem teljesen igaz, hogy az esxi nem támogat sw raidet. Ő maga nem tud létrehozni (nincs benne olyan funkció mint pl. Linuxnál az md), de ha kalapál drivert a gyártó, akkor megy, rengeteg ilyen vezérlő van, amihez van vib, és utána látod a raid volume-ot.
Nézz kürül a Lenovonál, de tartok tőle hogy eleve Lenovo custom imaget használsz, amiben benne kellene lennie, ha létezik. Szóval ha így van, akkor semmit nem fogsz tudni kezdeni vele. Illetve de, az egyik diskre telepítesz
-
#5960
Chal
addikt
NeoPampalini
#5959
válasz
NeoPampalini
#5959
üzenetére
Szerintem ez ilyen, a Win10 már eleve nagyon rosszul muzsikál hdd-n, és ha még ehhez párosul egy folyamatos egyéb i/o load is... Ne csak a throghputot nézd, gondolom nem 15k rpm enterprise diskről van szó. Egy desktop sata hdd elhervad ilyesmitől könnyen, mivel seekelnie kell folyamatosan. A Win10 bootkor rányom egy masszív random olvasást, miközben a lemez teljesen más területére írnia kellene folyamatosan, még ha nem is túl gyorsan. Ehhez még hozzájön a multi layer fs (ntfs -> vmdk -> linuxon használt fs). Ha netán valami alacsony fordulatszámos "green" hdd-ről van szó, akkor az pláne megadja a kegyelemdöfést.
Az biztos amúgy, hogy swapel? Kapcsold ki a swapet a Windowsban. De szerintem a fő probléma az, amit fentebb írtam. Esetleg a Linuxon lehet tekergetni az i/o schedulert. Lehet hogy van jobb infó forrás is, de nagy hirtelen: link (ha jobban érdekel, akkor gugli, dunát lehet rekeszteni az i/o scheduler tuning tutorialokkal), de nagy csodát ne várj.
-
válasz
tasiadam
#5902
üzenetére
Szerintem engedd el, a Proxmox megváltás lesz. Ott legalább támogatott minden, arról nem is beszélve, hogy patchelni is tudod amikor csak kell a jövőben. A 6.5/6.7 idén novemberben end of tech support státuszba megy, és ha lesz megint valami security bug, akkor jövőre fogod a Proxmoxot telepíteni, az addigra már belakott rendszeren. Sokkal jobban fog fájni.
-
Vagy a legprimitívebb módszer:
Szereld be az új gépbe a régi fizikai disket, hozz létre egy üres vm-et a Vmware Workstationben, add neki a régi fizikai disket (persze legyen neki egy megfelelő méretű üres virtuális diskje is), majd bootolj a vm-en egy bármilyen számodra szimpi disk klónozó eszközt iso-ból (pl. Gparted), és klónozd át a fizikai disket a virtuálisra.
Ennek ugye annyi hátulütője lehet, hogy a Win7 számára gyakorlatilag szinte az összes hardver meg fog változni, ha ezt jól viseli és talpra tudja állítja magát az első bootkor (+ esetleg utána némi driver telepítgetéssel kézzel), akkor szerencséd van, és ennyi volt az egész.
-
válasz
kraftxld
#5732
üzenetére
Szerintem a második kijelölésnél ugyanazt a jelszót kell megadni amit az elsőnél beállítasz, ami meg a saját leendő sso adminja, és a jelszava. Hiszen alapvetően nem vCenterbe deployolunk vCentert, szóval ezen a ponton (ebben a feladatban) a telepítőnek nem is létezik másik vCenter, csak egy (vagy több) unmanaged esxi host kellene neki. De lehet, hogy csak belekavarodtam így estére egy sör után én is a vCenterception-be.....
Mindenesetre a nested szerintem jó lesz, ha tényleg tudod állítani a forged transmit policy-t.
-
-
válasz
MrSealRD
#5647
üzenetére
A Proxmox alatt egy stock Debian van, a saját installerük csak annyit ad, hogy kapsz egy Proxmoxos grafikus install felületet (ez az ami nálad bugos), és a Debianra kapásból ráteszi ugye a saját csomagjait.
Szóval sima Debian (PVE 7 esetén Debian 11) install után Proxmox repo hozzáadás + apt-vel proxmox telepítés a repóból az teljesen megegyezik azzal, amit a saját install iso-juk csinál. Ráadásul ez Proxmox oldalról is supported teljesen, a doksiban is benne van, mint telepítési mód. Én eleve inkább így szoktam, tisztább megoldásnak érzem, ráadásul a Debian saját telepítője sokkal több beállítási lehetőséget ad, na meg a monitor sem fog vibrálni
-
-
Gondolom sokan láttátok már, de itt még nem vót': Broadcom is acquiring VMware for $61 billion. Durva.
-
válasz
Konflikt
#5610
üzenetére
Ja, pont az előbb néztem, hogy ne írjak hülyeséget az ár kapcsán, akkor láttam, hogy ebben a formában csak 4250 USD az install, configure, manage
Persze gondolom vannak azért kedvezmények.Amúgy persze ez már csak lazán kapcsolódik, mert csak simán drága, mint minden egyéb gyártó hasonló szolgáltatása. Sőt... voltam tavaly többedmagammal egy három betűs több kurzusán is (online + online lab), az biztos hogy ennél drágább volt.
-
válasz
Konflikt
#5606
üzenetére
Persze, de nem is volt szó ilyen aspektusról, minden tanfolyam drága, sőt... Én a kötelezőséget emeltem ki, ettől elkanyarodtunk kicsit az általános képzési árakhoz, meg hogy máshol is fizetni kell a vizsgáért, megújításért (egyik sem ugyanaz ugye...).
Amúgy két szakmabeli ismerősöm is került már e miatt kellemetlen helyzetbe, mert oké hogy a munkáltatók még itthon is viszonylag könnyen szórják a pénzt képzésre, de nem mindegy azért, hogy úgy jön a dolog, hogy van rá egy éves budget a csapatnak, és mindenki kedvére válogathat (jó esetben), vagy xy egyszer csak a kezét tördelve megjelenik, hogy főnök, az van hogy benéztem/elfelejtettem, és akkor most 5 napra el kellene mennem egy 600 ezres tanfolyamra
Persze nyilván le van írva, és az illetőknek kellett volna figyelnie, csak hát ettől még hülye helyzet, és más gyártóknál ilyet én még nem láttam (de biztos lehet találni még, nem állítom hogy a vmware az egyedüli, viszont abban biztos vagyok, hogy ritka jelenség). -
válasz
bugizozi
#5599
üzenetére
Melléduma sajnos. Erről persze küldtek e-mailt anno, és én is hátradőltem, hogy milyen jó, végre nem kell ezzel szórakozni, ha éppen a projekt vagy a munkáltató igényli, akkor majd megyek vizsgázni (upgradelni). Csakhogy sajnos nem így van. Ami nem jár le, az a már birtokolt cert az adott verzióra (előtte ez is lejárt, szóval teljesen el tudtad veszíteni a vcp-d). Viszont a tanfolyamkötelezettség nélküli vizsga továbbra is határidős, ha X verziójú cert-et nem újítasz meg vizsgával Y vagy Z verzióra adott időn belül, akkor egy idő után nem is engedik, csak tanfolyammal.
Én is az utolsó pillanatban szembesültem ezzel tavaly év végén, akkor is úgy úsztam meg, hogy volt egy NSX vizsgám, amit kivételként kezeltek (a vpc-mmel önmagában már csak tanfolyammal ment volna az upgrade, de az ugyanolyan verziójú VCP-NV-vel még engedték).
Amúgy asszem 6-osom volt, és azt upgradeltem DCV7-2021-re, de ez a fentiek szempontjából lényegtelen.szerk.: bocsi, látom Newman leírta ugyanezt, csak én még 8 körül kezdtem el írni, és most nyomtam rá a postra, lassan indul a nap, na
-
#5579
Chal
addikt
promagus00
#5578
válasz
promagus00
#5578
üzenetére
Persze hogy van: link
-
Nálam sima md (linux softraid) fölött van LVM, abban pedig thin pool. Így minden virtuális disk saját natív lv -t kap, a host saját fs-e (amiről bootol is) meg egy sima (nem thinpoolos) lv. Vmware megfelelője ennek talán a vvol, ha nagyon sarkítva hasonlítani akarom.
Persze erre itthon csak 1db host van, meg ez az lvm-es megoldás nem is tudna shared storaget, viszont erre nekem tökéletes, főleg, hogy nem kell hozzá enterprise/drága vas, és performanciában is nagyon jó, és ha bármi történik bármivel, akkor akár egy "kenyérpirítóról" és elérhetővé tudom tenni az adatokat. -
válasz
MrSealRD
#5568
üzenetére
Így már értem, akár még működhet is.
Amúgy feltétlen szükséges az esxi? Én pont hasonló okokból adtam fel sok év után az egészet itthon, egyszerűen vagy egy halom pénzt kellene rá költeni, vagy elkezded mókolgatni kerülőmegoldásokkal, de akkor előbb utóbb csak a szívás lesz vele, rosszabb esetben adatvesztés, hosszú állásidő, vagy egy adott verzión ragadás.
Engem már eleve attól kirázna a hideg, hogy kiadok mondjuk 100-150kHUF-ot egy ilyen tri-mode kártyáért, majd ha teszem azt 2 év múlva megdöglik, akkor állni fog az egész cucc 2 hónapig, amíg nem szerzek egy másikat? Vagy egyből kettőt vegyek 300-ért? És itt használt, ebay-ről összevadászott cuccokról beszélünk. Ennyi pénzből komplett, modern, keveset fogyasztó háziszervert lehet venni... Lehetne persze 2 node-os vsan is, de akkor megint oda kanyarodunk vissza, hogy zsebbe kell nyúlni keményen.
Persze az igazsághoz hozzátartozik, hogy van combos labor a cégnél, szóval van aki kifizette helyettem a fentiek sokszorosát, és ott bármit is lehet csinálni bármikor távolról is, így nyilván könnyen szántottam be itthon a saját környezetet, illetve lett helyette Proxmox.
-
válasz
MrSealRD
#5566
üzenetére
Nálam van Highpoint kártya esxi alatt, u.2 csatikkal és u.2 nvme ssd-kkel. Driver nélkül is megy, persze nem akkora kunszt, mert raid nélkül használjuk (vsan alatt van). Raid módban soha nem próbáltam.
A második felét a commentednek nem biztos hogy értem, de ha nvme disket akarsz ezzel a módszerrel sas raidvezérlőre kötni, az biztosan nem fog menni, hiszen ettől még pci-e eszköz marad az ssd, nem lesz belőle sas vagy sata.
-
Arra akar célozni szerintem, hogy ennek semmi köze a vmware-hez. Annak a hálózati rétege ad neked egy L2 kapcsolatot a hoston kívüli fizikai LAN-odhoz ha bridged networkingre állítod a vm-ed virtuális hálózati interfészét, aztán azt csinálsz amit akarsz. Pontosan úgy kell kezelned, mintha egy fizikai gépre telepítetted volna, amit rádugsz a hálózatodra, és azon akarnál ipv6-ot konfigurálni. Ha azon megy, itt is fog, ha nem megy, akkor viszont nem ebben a topicban lesz a megoldás kulcsa.
-
válasz
Konflikt
#5486
üzenetére
Off: ők is (IT Cafe) a pongyola "Apache sebezhetőség" kifejezéssel jönnek. Eléggé zavaró/félrevezető, mert sokan az Apache webszervert értik alatta. Sajnos még ügyfelek/kollégák körében is tapasztaltam péntek óta, hogy nekiálltak keresgélni hogy hol van náluk Apache, és mit kellene vele csinálni. Agyrém az egész. Kedvencem annak Veeam-es fejlesztőnek a hivatalos blog és fórumbejegyzése, aki a kérdésre annyit válaszolt, hogy a Veeam nem érintett, mert sehol nem használnak Apache-ot.... Amennyire ki tudtam deríteni, Java-t se, szóval jogos, hogy nem érintettek, csak nem amiatt amit írt
. Innét meg ugye elég ijesztő, hogy mennyire lehet képben, miközben hivatalos választ ad.(A log4j ugye egy java lib, java fejlesztőknek, az Apache-hoz annyi köze, hogy az Apache foundation szárnyai alatt fejlesztik. Szerintem azt kellene hangsúlyozni inkább, hogy ahol Java alapú alkalmazások vannak, ott szinte biztos az érintettség, mert a log4j java lib nagyon közkedvelt, java alkalmazások jelentős része - már amik logot is készítenek - ezt használja.)
-
válasz
TheProb
#5459
üzenetére
Exchange kivéreztetésre mondjuk inkább, hogy in progress, de előrébb járnak azért mint a hyper-v-vel
Amúgy hála az égnek én sem magamtól tudom, csak mellettem ül az ms-es csapat a cégnél, és mostanában már arra is panaszkodnak, hogy még új xch vizsga sincs, a régieket meg visszavonták. De lehet hogy pontatlan a dolog, érintettség hiányában nem néztem utána, csak hallottam. -
válasz
TheProb
#5447
üzenetére
Én nem hallottam erről konkrétumot, de nagyon agresszíven terelnek mindenkit az Azure-be, nem lennék meglepve annyira ezen. Másfelől meg azért sokkal alapvetőbb on-prem. szolgáltatás ez mint mondjuk az Exchange (aminek a kivéreztetése már önmagában nem kis balhét okoz az ügyfeleik körében), szóval elég nagy vállalásnak érzem.
-
-
válasz
TheProb
#5393
üzenetére
Nem jártam utána még, de logikusan arra tippelnék, hogy így túl nagy az overhead a command setek konvertálgatása miatt. Eleve ha feltételezzük, hogy egy bármilyen sata/sas diskből képes lenne csak egy más típusú szoftveresen emulált vezérlővel ennyivel többet kivenni a hypervisor (a fenti benchmarkban helyenként kétszeres-háromszoros eltérések is vannak), akkor ezt megcsinálhatták volna réges-régen, max nem "nvme controller" lenne a neve.
Szóval egyelőre így józan paraszti ésszel: szerintem kell hozzá a fizikai nvme eszköz is.
-
válasz
bugizozi
#5360
üzenetére
Nekem más miatt kellett (régi c7000 virtual connect modul webguihoz), de végül feladtam. Sajnos az Adobe a múltban sem készített fullos flash telepítőt, csak egy mini exe volt, és maga az installer online töltötte le a dolgokat. Természetesen az e mögött levő repot az Adobe megszüntette már rég, szóval hiába találsz akár megbízható helyeken is telepítőket, egyik se fog menni. A legjobb ha tudsz kukázni valahol/valakitől egy öreg managament vm-et amiben még van flash, azt jól el kell tenni, és ha belefut az ember ilyesmibe akkor lehet vele legalább dolgozni.
Valamint van egy opensource project, akik from scratch készítettek flashpalyert, de a VC nem működött vele, esetleg ezzel tégy a próbát, hátha a Horizont szereti: link
Illetve most láttam, hogy van egy ilyen is, ezt nem próbáltam: link
-
válasz
sto1911
#5355
üzenetére
CIS-nél keresgélj inkább, pl: https://www.cisecurity.org/benchmark/vmware/
CsodaPOK: na de a zöld doboz nem a VMware. Amúgy valahol félúton van szerintem a megfejtés: dual SD slot, mirroror funkcióval, és rendes industrial grade kártyákkal (nem zöld dobozosnak, meg kék D betűsnek címkézett, de valójában random, ki tudja milyen dzsunka gyártótól származó ipari hulladék), és akkor oké
-
válasz
VANESSZA1
#5347
üzenetére
Így van, UAC-ot kapcsold ki, és 127.0.0.1-et adj meg szervernél. Nagyjából az alábbiakkal lehet eliminálni a Converter bugjait/hülyeségeit:
- local adminnal futtasd (domain admin nem jó)
- UAC legyen a gépen kikapcsolva a fenti említett helyen
- 127.0.0.1-et adj meg a szervernél
- a megadott user legyen ugyanaz a local admin amivel futtatod és gépnév\localadminnal add megMostanában egy projekt miatt elég sokat használtam (hyper-v -> vSphere migráció), minden is előjött, de a fentieket betartva tök jól működött mindig.
-
válasz
Konflikt
#5345
üzenetére
+1, de pár kiegészítés: félprofi vagy profi fotózásnál is alap a kétkártyás gép (vagy mondhatjuk, hogy kb. mindenhol, ahol megengedheti magának a fotós), máshogy nekivágni egy munkának/projektnek őrültség, minden fotósnál fogyóeszköz kategória az SD kártya.
Amúgy nem csak az i/o nyírja ki, hanem a meleg is, vagy a gyakori hőmérséklet változás. Én magam is használok egyébként industriál kártyákat, sokkal nagyobb i/o mellett mint amit egy esxi csinál (ami konvergál(t) a nullához).
30-35db ilyen üzemel nálam kültéren, magaslati pontokon, a közvetlen napfénytől/fagytól/csapadéktól csak egy kis vacak műanyag doboz választja el őket, és 6 éve mennek mind egy szálig gond nélkül.Nem úgy mint pl. a HPE kártyák a szerverekben, a frankón belőtt páratartalmú levegőben
Persze ennyire nem vészes a helyzet, nálam is csak az van inkább, hogy túl nagy a minta, és ezért is jön szembe néha egy-egy ilyen hiba, viszont akkor nagyon idegesítő tud lenni. -
válasz
kraftxld
#5343
üzenetére
Propagandát én vmware oldalról nem láttam az SD kártya mellett, de lehet hogy van valahol, csak nem futottam bele. Viszont sacc/kb. 5-6 alkalommal szívtam be már azt, hogy nem indult el többé a host, hibás kártya miatt (hozzáteszem, hogy egyik sem dual card-os, mirrorozott megoldás volt), és ennek semmi nyoma nem volt a rebootig. Ráadásul a kedves gyártóktól sem láttam még, hogy a 10-es árszorzóba beleférne valamilyen high durable kártya, pedig létezik.
Egyébként ez az eset annyiból hasonló, hogy itt nagyon rövid idő alatt történik meg az, amihez amúgy pár év kellene.
-
válasz
bugizozi
#5338
üzenetére
Szomorú, még jó hogy nem futottam bele. Sajnos hiába hangoztatom mindig, hogy ne telepítsen senki SD kártyára ESXi-t, ennek ellenére tömegével jönnek szembe az ilyen hostok (oké, tegyük hozzá, hogy valamelyest érthető okokból).
Nekem a fő bajom vele az, hogy a kártyákon nincs SMART, vagy egyéb hasonló diagnosztikai megoldás, vagy legalábbis semmi olyan, ami közel járna ahhoz, hogy úgy lehessen használni/monitorozni mint egy hdd-t vagy ssd-t. Ahol van mirror (szerencsére már sok vasban alap), ott valamelyest jobb a helyzet, de szerintem ez még nem ad megnyugvást.
Évekig is képes szunnyadni egy ilyen disk hiba, gondolom mindenki látott már olyan kártyát, ami vígan eszi a write requesteket, aztán reboot után nincs rajta a kiiírt adat... És mikor derül ez ki? Igen, amikor crashel a host, vagy amikor az éjszaka közepén rebootolna az ember egy upgrade miatt, szóval csupa olyan esetben amikor van bajunk bőven, és akkor még kapunk mellé egy kövér maflást is -
Local adminnal futtasd, és sokszor még ez sem elég a boldogsághoz, mert az UAC-ot is ki kell kapcsolni.
Javaslom még, hogy a connection megadásnál ne a convertert futtató gép IP-jére loginolj, hanem a localhostra (és ezzel együtt természetesen ne loginolj távoli converter kiliesnből remote converter szerverre), az user pedig legyen az említett local admin.
Ha fent leírtakat betartom, akkor soha nincs baj sem a telepítéssel, sem a konvertálással, RDP-n használva sem. Egyéb esetekben az egyes fázisokban (install, login, scan, convert, stb..) mindenféle mágikus hibába lehet botlani. Ez a termék sajnos nem a VMware büszkesége, de szerencsére nagyon ritkán kell
-
válasz
[Newman]
#5243
üzenetére
Ez a kérdés bennem is felmerült hasonló szituban: 1 hónapon belül dobva lesznek, és nem egyértelmű, hogy tényleg nem érintett, vagy csak nem foglalkoznak vele.
bugizozi: én végül update helyett megcsináltam inkább a workaroundot (ki kell kapcsolni az slpd-t), de itt belefért, főleg hogy pár héten belül mennek a kukába.
-
válasz
jerry311
#5212
üzenetére
Ha van is benne ilyen, akkor úgy oldja meg ahogy írtam is, azaz boot közben próbálja kitalálni hogy kell e volume-ot növelnie, aztán szépen meghívja a megfelelő parancsokat (fdisk, resize2fs, stb..), majd rebootol egyet újra. Csak ugye az vele a baj, hogy mi van ha én nem akarom ezt? E miatt se szeretem, hogy a Pi OS--nél (volt Raspbian) ez default, install után az első dolgom ennek a kikapcsolása. Másnál amúgy nem is láttam ilyet, de ettől függetlenül lehet, hogy létezik még ilyen OS/disztribúció).
-
válasz
józsi9995
#5208
üzenetére
Teljesen elbeszélünk szerintem egymás mellett
Sehol nem írtam, hogy a reboot megoldja. Nagyon bele vagy kavarodva ebbe az egészbe, első körben a legfontosabb az lenne, hogy ne csak felületesen olvasd el amiket írunk.Vélhetően a vm-ben futó OS (az A10 appliance) valamit csinál automatizáltan a szabad hellyel, ettől lehet az, hogy nálad a laborban ment a dolog, és ugyanezen funkció valamiért nem működik a régi rendszeren. Viszont ezt a hibát vmware oldalról nem fogod tudni megoldani, mert nem ott van.
-
válasz
józsi9995
#5205
üzenetére
Ezt nem teljesen értem. Amit írsz, az nem probléma, hanem a normál működés. 6.7-en is ugyanígy kell viselkednie, meg a Hyper-V-től kezdve a Proxmoxon át mindenhol.
Javítsd ki légyszi ha rosszul értem, szóval összefoglalva: növelted a virtuális disk méretét a hoston, és azt várod, hogy belül a vm-ben a filerendszer ennyivel nagyobb legyen? Ez így nem fog működni, az OS-en belül meg kell növelni a filerendszert, ezt a host nem tudja megcsinálni. A kézi növelésnek előfeltétele persze, hogy lássa a guest OS a megnövekedett disket, ezt Linux esetén egy scsi rescan vagy egy reboot oldja meg, de újra leírom: ettől még nem fog megnőni a filerendszer vagy bármelyik partíció.
Léteznek egyébként pl. olyan linux disztribúciók, amik boot közben ha nagyobb disket detektálnak, akkor megnövelik az fs méretét scriptekkel (pl. a Raspbian ilyen), de ugye ő is csak azt csinálja amit neked kellene most kézzel.
Ha ez az appliance is tud ilyet, de valamiért nem csinálja meg, akkor szintén csak a support fog tudni segíteni. Ha van shell hozzáférésed akkor megpróbálhatod patkolni, de ha ez egy éles rendszer, élő support szerződéssel, akkor tényleg kérdezz rá előbb.
-
válasz
józsi9995
#5201
üzenetére
Sajnos rossz helyen kopogtatsz, a kérdéshez nincs köze a VMware-nek. Bármilyen OS alatt bárhol (virtualizáció, fizikai vas) ha disket bővítesz, akkor pontosan az lesz az eredmény amit írtál. A vm-ben levő OS-ben is át kell méretezni az adott filerendszert illetve partíciót, magától ez nem fog megtörténni.
Gondolom ez valamilyen appliance lesz, első körben nézd át a dokumentációját, hogy milyen lehetőséget kínál erre, aztán ha abból nem derül ki semmi, akkor beszélj a supporttal.
-
Hát igen, az usb passthrough addig tűnik semmirekellő dolognak, amíg nem jön szembe, aztán lehet pislogni
Én eddig kétszer futottam bele, az egyiknél egy kis HSM modult akartak használni, a másiknál hw kulcsot. Mindkét esetben bekerült egy plusz blade a hyper-v-sek mellé, ingyenes esxi-vel, roppant szép megoldás lett -
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.
-
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 -
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.
-
válasz
jerry311
#4969
üzenetére
A fizikai portokat csak uplink portnak tudod használni, tehát bridge itt nem lesz, nem erre való. Annak viszont semmi akadálya, hogy csinálj egy vm-et, és abban valósítsd meg a bridge funkciót. Persze ez esetben két külün vswithcen legyen a két fizikai NIC mint uplink, és mindkét vswithcbe legyen a vm-nek 1-1 lába + a switchek security beállításainál mindhárom opció legyen engedélyezve (pormisc. mode, forged transmits, mac address changes).
Egyébként - bár működik - de ez sem túl szép megoldás, miért nem kötöd eleve össze a fizikai switcheket inkább?
-
Használ valaki NPAR-t éles környezetben? Egy projekt kapcsán merült fel az ötlet, mert kevés az interface, de eddig valahogy ez a megoldás elkerült, nincs vele tapasztalatom. A vasak Gen10 DL-ek lennének, a kártyák pedig 10G-s 534FLR-ek. A cél az lenne, hogy külön interfaceket kapjon az iscsi és az vm-ek forgalma (NIOC és dvs nincs a licencekben, és az npar-al talán amúgy is szebb lenne, már ha megbízhatóan működik).
-
válasz
[Newman]
#4891
üzenetére
HA sem játszik, mert nem tudod egy clusterbe tenni őket, már a vCenter se fogja megengedni (és az EVC sem oldja meg, mert csak intelen vagy amd-n belül működik). Mondjuk ezt a korlátot sosem értettem, technikailag semmi akadálya nem lenne egy HA only működésnek mixed (amd/intel) hostok esetén.
-
válasz
bugizozi
#4874
üzenetére
+1 szintén. A kérdés nálam csak azért merült fel, mert 99%-ig biztos vagyok benne, hogy ez az sns nem lesz megújítva, szóval vagy az sns lejártáig lehet upgradelni (ami egy nagyobb munka ugye 1 éven belül (HA és amennyiben él még egyáltalán az sns, amit nem tudok), vagy most eleve azzal telepítem. Egyelőre magammal sem beszéltem még meg, hogy melyik lenne a kisebb szar, szóval inkább csak infót gyűjtök
-
Jól látom/gondolom, hogy egy 6-os vSphere standard licence csomag upgradelhető 7.0-ra (for free), amennyiben él még rá a support subscription? Zöldmezős beruházás lenne, és lehet, hogy kicsit korai még, de akkor már eleve 7.0-val indulnék. Ugyanis nem tudom, hogy a későbbiekben meg lesz e újítva a support sub., szóval lehet, hogy ez egy "most vagy soha" helyzet.
Ugyanakkor egyelőre nincs infóm róla, hogy az említett 6-os standard mikor lett vásárolva, az is lehet hogy régebben (1 éve, vagy több), felhasználva/regisztrálva viszont még nem volt. A support sub. erre ugye a regisztrációtól ketyeg, és nem a vásárlás napjától? Mert ha az utóbbi, akkor az első kérdés tárgytalan is
-
Erre írtam, hogy felesleges vele szenvedni, mert a XP-n belül is variálni kell defrag vagy scsi unmap tool stb... Vélhetően ha törölne most 45GB-t az OS-en belül, és egyéb dolgot nem csinálna, akkor thinre konvertálás után ugyanúgy 80GB lenne a végén a vmdk. Ha pedig hozzányúlna e miatt, akkor szerintem inkább már érdemes párat klikkelni mondjuk egy live bootos gparted-ben (átméretezés majd klónozás), így szebben/véglegesen rendbe van rakva az egész.
-
válasz
SzaZso007
#4822
üzenetére
Többrétű a probléma, mert ha jól értem a vm-en belül is 80GB-s a partíció. E miatt én nem mennék bele nagy barkácsolásokba, egyszerűen adnék a vm-hez egy 35GB-s disket, fognék egy live bootos klónozó eszközt (pl. ott az ingyenes gparted), átklónoznám a disket a kisebbre (a tool ugye csinál egy átméretezést, majd egy klónozást). Bootolnék a 35GB-sről, és ha minden oké vele, akkor törölném a régit.
-
válasz
bucihost
#4802
üzenetére
VNC-vel esetleg, de elég korlátolt a billentyűzetkezelése. Ha us kiosztás van a vm-en belül, és nálad is, akkor talán meg lehet vele ugrani a feladatot.
A vm-hez tartozó configba:
RemoteDisplay.vnc.enabled = "TRUE"
RemoteDisplay.vnc.port = "5901"
RemoteDisplay.vnc.password = "valami" (opcionális)Persze a tűzfalat kapcsold ki a hoston, vagy engedélyezd rajta a megadott portot. Ha jól rémlik, anno meg tudtam azt is oldani, hogy vm restart nélkül ki/be lehessen kapcsolni a VNC konzolt. Ha ez utóbbi fontos lenne, szólj, és előtúrom.
-
válasz
Adamo_sx
#4777
üzenetére
Szerintem sehogy, a kártya elrejti az esxi elől a diskeket teljesen. Hogy a smart arraynak mennyire lehet hinni, az egy másik kérdés, ha nem lélegeztetőgép megy róla, akkor én lehet, hogy megvárnám hogy tényleg elhullik e. Ennél kókányabb/lassabb/hazudósabb vezérlőket nem hordott a hátán a föld. Nem spare drive véletlenül? Mert akkor itt van pl. ez.
-
válasz
MrSealRD
#4746
üzenetére
Mi egy házon belüli speciális projekt keretében fogunk beüzemelni egy három node-os clustert Ryzennel. Lesz 100G ethernet meg vSAN is alatta, és jelentősen lesznek terhelve a cpu-k is. 1-2 hónap múlva lesz vele hoszabb távú (1-2 hónapos!
) tapasztalat, majd megírom, hogy hogy vált be. -
Belefutottam egy furcsa dologba 6.7u2 san boot kapcsán: HPE DL* gen10, qlogic kártya, fc lun-ok. Az installer nem lát egy darab lunt se. Rommá konfiguráltam már a kártya és a gép biosát is, de semmi. Kínomban bootoltam egy linuxot, az látta a lun-t, és települt/bootolt is róla. Ezek után az esxi installer is látta
Gondolom az lehet a háttérben, hogy a linux létrehozta az uefi boot partíciót, meg a megfelelő flageket, és így már tetszett az esxi-nek is.ESXi-nél ezek szerint előre kellene inicializálni a lun-t valamivel, ha telepíteni szeretnék rá? Az installerben nincs erre mód? HPE custom iso amúgy, és legacy bios módban is ugyanez vele a helyzet. 2-3 éve telepítettem utoljára san lun-ra esxi-t, de akkor mintha nem lett volna vele ilyen gond.
-
Szerintem technológiában nincs semmi eltérés, mert ugyanúgy nandflash, ugyanúgy usb-n csatlakozik (a HP/Dell-es integrált sd slot is). Szerintem az van, hogy default valamilyen industrial grade kártyával érkeznek ezek, amik azért nincsenek pariban az apróról vagy az XY PC boltból/nagykerből beszerzett pendrive-okkal
Amúgy én már láttam HP-ban meghalni ilyen kártyát, igaz nagyon nagy darabszám mellett csak 1db-ot. -
Futtat valaki vSphere 6.0-án WS2019-et? Működik? Azzal tisztában vagyok, hogy unsupported, de néhány HP G7 blade miatt két lehetőségem van: vagy tákolok rájuk 6.5/6.7-es esxi-t, vagy marad a 6.0 ami supported.
Kérdés, hogy PSOD-ból vagy BSOD-ból fogok többet látni az egyes megoldások függvényében
Melyik kezembe harapjak? A virtualconnect firmwarek és a hp-s esxi driverer mátrixok okozta idegbajok miatt én inkább a felé mennék, hogy a 6.0-án vállalnám a kockázatot a ws2019-el (már ha működik egyáltalán). -
válasz
TheProb
#4534
üzenetére
Nem nem érted szerintem, hanem nem tudsz róla, hogy mi történt pontosan. Tuti hogy döccent egyet a kártya, vagy a tömb, vagy most is van benne még hibás disk, bármi lehet. A vmfs-nek volt egy olyan pillanata vélhetően amikor nem tudott írni, vagy korrupt lett az írás, erről nem az 1db kiesett disk tehet, hiszen erre lenne a raid5 redundanciája.
A mellett hogy próbálod lelapátolni az adatokat, szerintem nézd meg a logokat is, különösen abban az időszakban, amikor a disk elhullott.
-
válasz
TheProb
#4532
üzenetére
Biztosan valami nagyobb gond volt/van, mert a vmfs arról mit sem tud, hogy neked a raid5 tömbödből kiesett 1db disk. Szóval ha tényleg csak ennyi történt, akkor azt a vmfs nem veszi észre, mint ahogy abban a rétegben semmi más se venné (ha natív ext*, ntfs, akármi lenne rajta, az se tudna róla).
-
válasz
powerray
#4500
üzenetére
Én nem szívnék vele, illetve hirtelen nem is tudom, hogy támogatja e a converter a Debiant. Szerintem húzd be egy vmdk-ba dd-vel, vagy bootolj egy live linuxot a cél vm-en, és cpio vagy tar over ssh-val másold bele a forrásrendszert (egyszer régebben amúgy futás közben kibányásztam a konverter processeit, és pontosan ugyanígy csinálja). A végén kell telepíteni egy új grubot, hogy loadere is legyen, illetve rendet tenni az fstab-ban, és meg is vagy.
-
válasz
[Newman]
#4468
üzenetére
Na, akkor ezt tényleg érdemes pontosítani, én azért írtam, mert egyrészt a vizsgaközpontban megkérdeztem, de ott ugye sokszor teljesen nyilvánvaló kérdésekre se biztos hogy jó választ adnak, másrészt azt hittem, hogy tök ugyanaz a kategória mint az NSX, ami viszont tuti hogy hosszabbít.
Ha már így tanácsot adtam (és lehet hogy rosszat), akkor vállalom, hogy írok a cert. supportnak, amint megválaszolják a kérdést (ezer % hogy fel fog hívni egy indián
), jelentkezem -
Én még mindig nem teljesen értem, ha nem nyúlsz semmihez, akkor ennek így mennie kéne, mert 1db vswitchről beszélünk, és egy azon zajló sima L2 forgalomról,1db vm, és az esxi vmkernel (mgmt) interfésze között. Szóval tuti, hogy csak 1db vswitch van, és abban 1db portgroup, meg egy vmkernel interface?
A másik, hogy az esxi-nek is van tűzfala, azzal tényleg minden oké? Ha nem vagy benne biztos, akkor nyomj egy "esxcli network firewall unload" parancsot ssh-n, és próbáld ki utána a kapcsolódást.
-
válasz
kraftxld
#4445
üzenetére
Elég, én is NSX-el hosszabbítottam, az összes certemet kitolta 2 évvel. Ha nincs meg egyik sem, akkor ezekkel érdemes boostolni szerintem 4 évet (NSX + VSAN, először az egyiket, majd rá 2 évre a másikat). Talán jobb, mintha biztonsági játékkal megcsinálná az ember mindig ugyanazt a VCP-t vagy egyel újabbat (de én is voltam abban az élethelyzetben hogy nem volt idő tanulni/laborozni, szóval teljesen érthető ez a taktika is
). Amúgy szerintem ezek viszonylag egyszerű és rövid vizsgák.
) tapasztalat, majd megírom, hogy hogy vált be.
Új hozzászólás Aktív témák
- PlayStation 5
- Samsung Galaxy A56 - megbízható középszerűség
- Milyen billentyűzetet vegyek?
- Milyen légkondit a lakásba?
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Konzolokról KULTURÁLT módon
- Utcakép banánnal: félrecsúszhat a Google Térkép fókusza
- OLED TV topic
- Víz- gáz- és fűtésszerelés
- Itt a Galaxy S26 széria: az Ultra fejlődött, a másik kettő alig
- További aktív témák...
- Windows 10/11 Home/Pro , Office 2024 kulcsok
- Adobe Előfizetések - Adobe Creative Cloud All Apps - 12 Hónap - 15% AKCIÓ
- Windows, Office licencek kedvező áron, egyenesen a Microsoft-tól - Automata kézbesítés utalással is!
- PC Game Pass előfizetés
- Játékkulcsok ! : PC Steam, EA App, Ubisoft, Windows és egyéb játékok
- ÓRIÁSI AKCIÓK / MICROSOFT WINDOWS 10,11 / OFFICE 16,19,21,24 / VÍRUS,VPN VÉDELEM / SZÁMLA / 0-24
- Készpénzes / Utalásos Számítógép felvásárlás! Személyesen vagy Postával!
- BESZÁMÍTÁS! MSI B450 R7 1700 16GB DDR4 512GB SSD GTX 1070 8GB Rampage SHIVA Thermaltake 500W
- HP EliteDesk 800 G2 (Tower) i5-6500,8GB DDR4,240GB SSD, DVD, WIN11
- BESZÁMÍTÁS! Gigabyte B450M R5 2600X 16GB DDR4 512GB SSD GTX 1650 4GB ZALMAN T3 Plus Deepcool 400W
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest