-
Fototrend
Sziasztok, udvozlunk mindenkit Magyarorszag legnagyobb VMware forumjaban!
Új hozzászólás Aktív témák
-
válasz
MrSealRD
#4416
üzenetére
Ez elég érdekes, mert a bekapcsolás után az esxi gyakorlatilag elveszíti a system disket érthető okokból, így a configot sem tudja kiírni. Ezt írja egyébként a KB is, szóval restart után be kéne bootolnia a régi configgal, amiben még ki van kapcsolva az usb passthrough. Furcsa, hogy nálad sikerült kiírnia.
Ha ez mégis megtörtént valahogy, akkor én első körben mountolnám a pendrive-ot valahol, és belenéznénk az esx.cfg-be, szerintem egy true/false paraméter átbillentése megoldja a dolgot, de meg kell nézni. Arra figyelj, hogy a configok egy state.tgz nevű file-ban vannak, tehát ki kell tömöríteni, majd editálás után visszacsomagolni. Persze lehet hogy simán kevesebb idő egy host reinstall, még hostprofile nélkül is (azzal együtt meg kb. semmi), csak hát az a gyávák menedéke!
-
válasz
kraftxld
#4381
üzenetére
Erre írta hogy unsupported, LSI kártya esetén is, physical bus sharing-el. De majd futok vele még egy kört.
Egyébként ha valaki S2D-zni akarna vspheren: ha csak SSD típusú vmdk-val akar laborozni (lehet hdd-n is), akkor a régebbi tutorialokban írt physical bus sharing beállítású vezérlőre, és eager zeroed vmdk-kra nincs szükség, elég a virtualSSD = true paraméter (ha valóban SSD-n vannak a vmdk-k akkor még ez sem kell). Nem akartam kibogozni hogy a vmware-nek vagy az újabb s2d verziónak köszönhető e a dolog, a lényeg hogy már megy ezen egyszerű módon is
Így lehet snapshotolni a vm-eket (physical bus sharing mód esetén erre nincs lehetőség), és lehet akár thin disk is. -
MS Storage Spaces Directet (S2D) laboroznék nested módban egy vSphere clusteren. Ez egy olyan állat, aminek fontos, hogy jól be tudja azonosítani a diskek típusát (fizikai környezetben sem egy egyszerű eset amúgy, nagyon meg kell válogatni alá a hw-t).
Működik is a dolog, a "scsi*:*.virtualSSD = 1" advanced paraméterrel a vmx file-okban, viszont nem lenne rossz, ha tudnék tesztelni olyan virtuális disk-el is, amit HDD-nek hisz (tieringhez kéne). Sajnos nem találtam ehhez semmilyen támpontot, jobbára mindenki addig jutott vele, hogy a fenti megoldással behazudta SSD-nek a vdiskeket, aztán örült, hogy működik az all-flash S2D labja
Windows oldalon így néz ki perpill a helyzet: screenshot
Az mediatype = SSD diskeknél a "virtualSSD = 1" trükk van bevetve, az "unspecified"-eknél pedig szeretnék HDD vagy SAS típust látni.
Van bárkinek bármilyen ötlete?
-
Na, NSX vizsga (VCP6-NV) pipa
Nem volt annyira nehéz, de sok kétértelmű és szivatós kérdés volt, ahogy a normál VCP-nél is lenni szokott, csak ez ugye más terület. A legtöbb kilogikázható, de nagyon résen kell lenni, mert arra hajtanak hogy túlgondold, rossz irányba menj, stb.. -
válasz
MrSealRD
#4352
üzenetére
Az NSX example vizsgánál dobta fel a mylearn.vmware.com, hogy ha akarok több kérdést, meg több gyakorlást, akkor itt van ez.
Ugye ilyen example vizsga mindenhez van náluk, VCP-hez is, 25 kérdés általában. Azt is végig szoktam nyomni vizsgák előtt, és eléggé valid volt eddig mindegyik, tehát olyan kérdéseket tesz fel, amik szerepelnek a az éles vizsgán is.
Na most ha azt állítják, hogy a fenti linken ennek a bővített változata van, akkor én azt úgy értelmezem hogy az egy "prémium dump"
Persze az tény, hogy nem láttam egyiket sem, nem fogok érte 100 usd-t adni, szóval simán lehet, hogy nincs igazam, a fenti gondolatmenet alapján jutottam csak erre. -
válasz
MrSealRD
#4347
üzenetére
Viszont az érdekes amit írsz az elmúlt 10 évedről. Ezt a problémát hogy kezeltétek? Milyen eszköz felelt a biztonságos leállításért?
Tápellátás szempontjából mindig olyan helyen dolgoztam vmware megoldásokkal, ahol redundáns táp volt, redundáns ups-ekkel, aggregátorokkal. A legtöbb közöm az infra ezen részéhez egy viszonylag kicsi (magyar léptékben is) hazai DC-ben volt, ahol a monitoring rendszerbe be kellett vonnom az ups/aggregátor/betápok szenzorait, de vmware viszonylatban ott sem volt ezekkel semmi kapcsolat. Egy host leállítása pedig mindig tervezett feladat (maintenance mode, stb..), ha pedig hw vagy sw hiba okozza, akkor arra nyilván nem lehet készülni, beindul a HA/FT/DRS és teszi a dolgát
Ez volt a 'Z' terv.
Szerintem más megoldás nem lesz nagyon erre, de nincs ezzel baj, tulképpen csak az USB driveren vérezhet el az, hogy meglevő vm-ben meg tudod e oldani, vagy telepíteni kell hozzá egy sajátot. Meg kell nézni, hogy nem támogatja e a linux kernel alapból, és akkor nyert ügyed lehet Xpenologyval is, mert ez esetben csak egy kis script az egész (usb-n adat kiolvas, ha X<Y akkor ssh a hostra (key-auth belőhető könnyen), és shutdown).
-
válasz
MrSealRD
#4345
üzenetére
Persze azt is elfogadom, ha a szerverszobai körülmények miatt ilyen felhasználásra nem gondolnak annyira.
De gondolnak, csak az megint nem az a méret amit te szeretnél. Pont valamelyik VMUG-on demózta az APC a cuccait, ahol ups állapot, fogyasztás meg mindenféle energiafelhasználási szempontok alapján vomitonozott, tette le downba a hostokat és egyéb nyalánkságokat is művelt, illetve a vcenterbe is beépült. Mondjuk a mellett hogy jól nézett ki, mindenki csak ásítozott rajta, főleg hogy ott a DRS power management is (mondjuk azt is milyen sokan használják...
). Lassan 10 éve VMwarezek, láttam már pár dolgot, de olyan még soha nem adódott, hogy bármi közöm legyen az elektromos hálózathoz és az ups-hez szerver oldalon, és ez így is van jól (az meg tény ugye, és írták fentebb is, hogy a VMware nem lő soho területekre, ahol ez szempont lehet).Egyébként miért nem csinálsz az ups-nek egy management vm-et, és kezeled abból az egészet? Így bármilyen OS-ed lehet, az ups-t meg neki adod USB passthrough-val. Megfelelő eventre pedig egy egyszerű scripttel le tudod lőni a hostot valamelyik api-n, vagy szimplán csak ssh-n keresztül.
-
Jól látom, hogy NSX-ből nincs eval, csak hands-on lab? Össze akartam dobni egy kis saját labot, hogy a deployt is lássam, és sokadik lépés után derült csak ki, hogy a default licencel nem lehet továbbmenni. Nem is értem, hogy az első appliance deploy közben ezt miért nem lehet jelezni
NSX-ezik itt egyébként valaki? Lenne pár kérdésem a fentin kívül is
-
válasz
CsodaPOK
#4187
üzenetére
Itt is hasonló célok vannak
De azért vannak fenntartásaim vele. Pl. most átállítottam vsan-ra a labort, ahogy feljebb említettem, és egyszerűen nem találtam meg a módját annak, hogy hogyan lehetne a scaleiot graceful módon leállítani Az összesen kb. 1500 oldalnyi doksiban elég otthonosan mozgok már, de nem találom (mert nincs benne 
) hogy hogy kellene lekapcsolni. És ez csak a jéghegy csúcsa.Egyébként megvan a véleményem a HCI san-okról (főleg amikor mamut cégek akarják a meglevő all-flash valódi SAN helyett), de hát ez a trend, ez kell szeretni.
-
VSAN 6.6 esetén feltétlen LACP-znem kell, ha szeretném hogy 2x10G uplinket használjon? Találtam pár régebbi postot, amiben azt írják, hogy ha csinálok 2db vswitchet, 2db vmk interfésszel külön subnetbe, akkor szintén mennie kéne (hasonlóan ahhoz, mint amikor ugyanígy csinál az ember multipath iscsi-t). Viszont nem megy. Van rá valami megoldás, vagy mindenképpen vds+lacp kell?
-
válasz
CsodaPOK
#4182
üzenetére
Állítólag ugyanazon a vason jobb teljesítményt nyújt, mint a VSAN.
Két hét POC-olás után most kezdtem el átállítani a környezetet VSAN-ra, szóval (remélem) ki fog derülni. Az biztos, hogy a ScaleIO elég meggyőző volt, mindenféle optimalizáció és tweak nélkül ki tudtam vele koppantani a 2x10G-s interfaceket olvasás esetén (64K random read, IOmeter-el generálva, cachek nélkül). Statikus 2.6GByte/sec-et mértem 60k iops mellett. Ez több mint 20Gbit, de úgy jön ki a dolog, hogy az iometert futtató host olvasott a local ssd-iről is. Magán a fizikai switchen 9.6Gbit-et mértem a két porton egyenként a többi host switchportjainak a kihasználtsága (3x2db NIC) pedig 30-33%-on mozgott eközben. A mért értékeket alátámasztották a hostok performancia chartjai is (network és storage adapter) illetve a ScaleIO beépített saját egyszerű toolja is.
Írásban sajnos gyenge a vas, így arról nem tudok érdemben nyilatkozni. Read-intensive SSD-ket kaptam hozzá, a google által fellelhető user benchmarkokat ki tudtam belőlük préselni ScaleIO-val is (500 Mbyte/s, 10-15k iops), de itt nem a SCIO volt a szűk keresztmetszet nyilván, illetve annyiból igen, hogy írás esetén nem tud annyira párhuzamosítani a device-ok között mint olvasásnál.
Sok esetben érezni rajta viszont, hogy még van vele dolga az EMC-nek bőven. A toolok pl. katasztrofálisak. 3-4 eltérő management felületen lehet támadni (vsphere plugin, javás kliens oldali gui, cli, stb..), és van amit csak itt lehet beállítani, van amit ott. Teljes agyhalál az egész néha. Cserébe egyéb területeken meg faék egyszerű, és józan paraszti ész alapján fejlesztett dolgok köszönnek vissza. Szóval kissé furcsa itt-ott.
-
válasz
kraftxld
#4179
üzenetére
Nem, külön termék, az az állítás hogy from scratch kezdték el fejleszteni, se meglevő EMC se VMware kód nincs benne
Gondolom még a felvásárlás előtt indult, és nem akarják elkaszálni, mert jól teljesít, vagy a franc tudja, az is lehet, hogy mergelik majd a jövőben a kettőt, passz..Annyiból másabb mint a vsan, hogy tud mixelt környezetben is működni. A backend (de a frontend is) futhat bármilyen kukás gépen (esxi, linux, windows támogatás van mindkettőre). Aztán ezek keresztbe-hosszába legózhatóak. Pl. natív linux backend node-okra tud csatlakozni esxi frontend, vagy fordítva, mindezt akár vegyesen. De ha tisztn esxi-k alá deployolod, akkor ugyanolyan HCI megoldást kapsz mint a vsan.
Legperverzebb felállás ami eszembe jut: egy vSphere clusterre telepített ScaleIO szolgáltat datastore-okat a magának a vSphere clusternek meg mondjuk a szomszéd rackben levő Hyper-V-nek is. És ha esetleg a Hyper-V hostokban van disk, akkor azt is be lehet tolni, mert a backend komponensek telepíthetőek rajuk is, a ScaleIO meg nem tesz különbséget a között, hogy milyen OS van a nodejai alatt. Szóval elég beteg, de ugyanakkor érdekes is.
-
válasz
kraftxld
#4115
üzenetére
Szerintem ez úgyis csak akkor fog kiderülni ha már látod a valós terhelést. De ha feltételezed, hogy oversized vm-ek vannak vcpu téren, akkor az 1:10 arány valóban nem vészes. Egyébként meg el kell tőlük lopkodni, még örülni is fognak, ha úgy jön ki a lépés, hogy az eddigi elkúrt config (túl sok vcpu) felszámolása miatt gyorsul az adott vm
-
#4098
Chal
addikt
adriankoooo
#4097
válasz
adriankoooo
#4097
üzenetére
"A kívánt release kiválasztása után klikkelj a táblázatok tetején található "imageprofile" link-re, ott minden le van írva."
Amúgy ha jól rémlik nem elég az utolsó, sorban kell haladni, mert csak azok a patchek vannak benne, amiket a táblázatokban látsz. Tehát ha pl. egy régebbi csomagban van "net-e1000e" bugfix, majd a következő háromban nincs, de a legújabban megint van egy, akkor az nyilván átfedés, és meg fogod kapni a legújabb patchet a net-e1000e-hez. De nem érdemes szerintem ezt így mazsolázgatni, inkább haladj sorban, és tegyél fel mindent.
Ezeket az updatemanager nyilván szépen lekezelné, de mivel az nincs, így manuálisan kell csinálnod, sorban egymásután.
-
válasz
MrSealRD
#4092
üzenetére
Ajánlom ezt az oldalt: VMware esxi patch tracker
Egy fokkal egyszerűbb tud lenni mint a vmware.com-os vadászat
A kívánt release kiválasztása után klikkelj a táblázatok tetején található "imageprofile" link-re, ott minden le van írva. -
Sajna nálam ez nem megoldható, nem vagyok local admin a gépemen. Hop szerver kapcsán meg jött a SOC csapat, hogy fel kell tenni oda is 1 héten belül, mert irgum-burgum. Végül a józan ész győzött: kivételkezeléssel ki lehetett bújni a dolog alól.
Szóval hop/jump szerverről jó vagyok egyelőre, és a munkaállomásomon is megy IE-vel valamiért, pedig a bugos Flash van rajta
-
Durva, nekem meg itt liheg a nyakamban a securitys ember, hogy márpedig azonnal legyen az új flash player telepítve mindenhova is(!)
A laptopomra már terítették ahogy kell, azzal nem tudok mit kezdeni, Chrome-ban crashel is a 6.5-ös Webclient ahogy kell, IE-ben viszont gond nélkül működik (5-ből 5 próba esetén).Nem találtam egyelőre releváns infót, de csak pár perce nyomozok, szóval valaki tudja, hogy az IE is érintett e? Logikusan igen, de a tapasztalat nem ezt mutatja.
IE alatt lekérdezve is 27.0.0.170 a flash verzió, szóval elvileg crashelnie kéne.
-
Ez itt eléggé off, szerintem nézz át a Synology vagy a Qnap topicba.
Dióhéjban: ha Inteles NAS-t veszel a fent említett két cégtől, akkor manapság már mindegyik tartalmaz valamilyen virtualizációs és konténeres megoldást is (jellemzően Virtualbox és Docker). Ram az persze kell hozzá, illetve csodákat sem szabad azért várni a mobil celeronoktól amik ezekben az eszközökben vannak.
Szóval az így telepített vm-eket vagy a NAS webes felületén éred el (local konzol), vagy a vm-be húzol fel hozzá megfelelő szolgáltatást és arra csatlakozol kintről (vnc, rdp, stb..). -
#4009: igen, teljesen jól érted, minden úgy van, vagy úgy kell csinálni ahogy írtad.
A két megoldás között annyi az eltérés, hogy ott nem nat-ol a vm-eknek a management vm, csak a vpn miatt létezik. De egyébként vannak átfedések, nyilván a 2-es megoldásnál sem kell nat-olni, ha van annyi pubilikus IP amennyi kell.
-
Igen, létezik a szolgáltatónál Kliens VPN, plusz pénzért. Tényleg ez lenne a legegyszerűbb megoldás
Szerintem akkor ebbe az irányba menj. Illetve lehet mérlegelni az esetleges következményeket ha mégis a vm alapú vpn-t választod. Ugye ha az a vm lerohad, akkor nem fogod elérni az esxi-t sehogy. Ilyenkor lehet kérni IP KVM konzolt (ha van), vagy be kell menned a géphez.
Ami még eszembe jutott: kérdezz rá arra is, hogy tudnának e tűzfalazni, mert ha igen, akkor vélhetően az jóval olcsóbb lesz, és úgy nyugodtan (nyugodtabban) kiteheted az esxi vagy az "ILO" managemenet IP-jét is publikus IP-re. Persze ekkor a ti oldalatokon (az irodában) fix IP szükséges, és csak onnét fog menni a managemenet.
Hogy tudok vSwitch-hez privát subnetet rendelni? Egyelőre nem találtam sehol ilyen beállítást. Vagy ezt a Web Client-en nem is fogom megtalálni?
Ez csak logikai dolog, nem kell külön sehol beállítani, csinálsz egy vSwitchet fizikai uplink nélkül, azon belül pedig egy vm portgroup-ot és egy vmkernel interfacet (esxi managemenet interface) a subnet az lesz, amit az ide bedobott vm-en (értelem szerűen ez a VPN szolgáltatást nyújtó vm lesz) és a vmkernel porton beállítasz. Szóval a vs olyan mint egy mezei fizikai layer2 switch. A VPN vm-nek ezen kívül lesz még egy virtuális interface, ami egy másik vswitchre kerül, ezt nevezzük PROD-nak vagy PUBLIC-nak. Ugyanezen PUBLIC nevű vs-en legyen a többi vm-ed is (az egyéb szerverek), és ezek fogják megkapni a külső IP-ket amiket a szolgáltatótól kérsz, illetve ez a vs fogja megkapni az uplinket is, amin ezek az IP-k "jönnek". Nyilván fontos, hogy a PUBLIC nevű vs-en ne legyen vmkernel interface, csak vm portgroup.
Nincs kedvem most lerajzolni (pedig lehet hogy egyszerűbb lenne), inkább kérdezz tovább ha nem érthető
-
Ajánlott, stabil, és biztonságos módon kb. sehogy. Mármint plusz eszközök használata nélkül.
Bővebben:
A best practice itt az lenne, hogy ledumálod a szolgáltatóval, hogy adjon +1 switchportot és arra egy VPN elérést. Portot vélhetően tud, VPN szolgáltatást hozzá már nem biztos, ezért ez utóbbi esetben kelleni fog valamilyen eszköz a host elé. Ez pénztárcától függően lehet egy mini PC, olcsó router, Mikrotik router, kisebb Cisco ASA, stb stb... Ezután a hoston létrehozol egy saját virtual switchet saját vmkernel interface-el (persze ehhez a host oldalán is kell +egy fizikai uplink), és ezen keresztül manageled a hostot. Itt még esetleg lehet spórolni azzal, hogy a fent említett VPN/router eszközt egy vm-el valósítod meg. Ezen vm egyik vmnic-ét különálló vs-re teszed, és a szolgáltató igényelsz neki egy publikus IP-t, a másik nic-et pedig bedobod az esxi management networkbe. Ez persze a külső hw-s eszközhöz képest már gányolás kategória. Külső eszköz esetén egyébként pl. a host out-of-band megoldását (mint pl. a HP ILO) is bele tudod kötni, router vm esetén nyilván ez felejtős. Szóval én mindenképpen a külső megoldást ajánlanám, legyen az a szolgáltató által biztosított VPN, vagy saját eszközzel megoldott.
A másik megoldás igazi tákolás: csinálsz egy vs-t fizikai uplink nélkül, ebbe teszed a vmkernel interfészt, majd hozzárendelsz egy privát subnetet és management IP-t. A másik vs kapja meg a szolgáltató által adott fizikai uplinket, és ezt a két hálózatot összekötöd egy router vm-el. A router vm-en természetesen csinálsz VPN szolgáltatást melyen keresztül eléred az mgmt vmkernel interfacet. Ebben az esetben (is) nagy kérdés, hogy a szolgáltató tud e több publikus IP-t biztosítan az uplinken, hiszen a router vm el fogja vinni azt az 1-et amit jelenleg is kaptál. Szóval a további vm-eknek kell igényelni még IP-t, vagy beteszed őket a privát subnetbe (vagy akár egy másikba, ez már rajtad múlik, hogy mennyire akarod szeparálni az esxi mgmt-től) a router vm-en pedig NAT-olod őket a külvilág felé. Természetesen nat esetén át kell gondolni azt is, hogy az alkalmazások támogatják e ezt a felállást, illetve hogy mennyire akarod keresztülküldeni a forgalmukat egy vm-en. Szóval ebből egy bitang nagy SPOF-ot lehet így kihozni, ráadásul a szoftveres-gányolós fajtából.
Én egy helyen a második megoldást használom, évek óta működik, de tudni kell róla, hogy ez egy privát/hobbi/játszós szerver, gombokért bérlem egy német hosting szolgáltatótól, és ha lerohadna rajta a router vm, vagy bármi baja lenne ami miatt nem érem el az egész kócerájt, akkor sem történne semmi, még abban az esetben sem, ha teszem azt 2-3 hétig nem hárítom el a hibát, mert mondjuk nincs kedvem. Ha ez a rendszer pénzt termelne, és ügyfelek lennének rajta, akkor biztosan nem így oldanám meg.
-
Ennek a nézegetését javaslom: link
Különös tekintettel a raid vezérlőre. CPU egyébként biztosan számát? Futni fog cpu igényes alkalmazás? Szerintem az általad leírtak alapján 10% alatt fog malmozni a kisebb xeon is. Szóval én inkább egy normális raid controllerbe tenném a pénzt (ne fakeraid legyen és cache + battery/supercap legyen hozzá) és ram-ba.
-
Persze, mert csak a boothoz használja, ha menet közben kihúzod alóla, akkor is vígan működik tovább, max sír, hogy nem tudja írni a logot meg az esetleges coredump-ot.
Szóval a boot device típusa kb. semmit nem befolyásol performancia téren. Viszont azt nem árt figyelembe venni, hogy ha megdöglik (és erről egy USB/SD eszköz esetén lehet hogy nem is fogsz tudomást szerezni), akkor nyilván nem tud a host bootolni többé róla.
-
válasz
d@minator
#3898
üzenetére
Joggal. Mert a subnet a 200.1.1.0, ezzel próbáld. Egyébként ez egy public routed tartomány (egy venezuelai banké), biztosan ezt akarod használni? Ha igen, biztos hogy jó hozzá a /24 (255.255.255.0) ? Gondolom itt inkább az lehetett, hogy valaki a múltban azon a laptopon hasra ütve kitalált egy subnetet/IP címet, szerintem ha már hozzányúlsz, akkor itt lenne az idő ezt is rendbe tenni, és valamilyen szabványos privát tartományt használni helyette (192.168, 10., 172., etc..).
-
válasz
joysefke
#3807
üzenetére
Azt láttad, hogy kell már hozzá tanfolyam is és egy Foundations vizsga? A lejárt cert hosszabbítása manapság kb. ugyanaz mintha nulláról indulnál. Ha VCP5 volt (vagy nagyobb) ami lejárt, akkor elég egy what's new (illetve Foundations exam ebben az esetben is kell). Ha régebbi volt, akkor game over, lépj vissza a startmezőre
-
1GB a minimum követelmény 5.5 esetén, és a sebesség pedig teljesen mindegy, max lassabban indul el, másra nem használja a rendszer ha már fut. De gondolom nem tervezed gyakran rebootolni, és akkor sem számít túlságosan az a pár másodperc. A scratch és egyebek pedig mehetnek a datastore-ra.
Arra figyelj azért, hogy legyen config mentésed, mert ezek a flash alapú tárolók nem túl biztonságosak 7/24-ben. Ha megdöglik, nem lesz semmi gondod belőle runtime, mert a RAM-ból megy minden, viszont nyilván rebootolni már nem tud róla a rendszer. És ez rossz esetben csak akkor fog kiderülni amikor éppen csinálnád (mármint a rebootot), szóval elég kellemetlen is lehet akár.
Nálunk amúgy a HP bladekben is hullottak a gyári embedded SD kártyák, pedig azt gondolná az ember, hogy azoknál legalább figyeltek rá hogy valami sokat bíró industrial változat legyen benne.
-
Lejárt a szerk....
Szóval az jutott még eszembe, hogy az szép feladat lesz, hogy etherchannelt konfigurálsz a VM-ek load balancingje miatt, de közben ugyanezeken az interfaceken akarsz majd multipath-ozni iscsi-val.
Elvileg LACP-vel megy (nem próbáltam), olyan formában, hogy az iscsi-hoz rendelt 2db vmk interface (1-1 kell ugye mindegyik 10G-s NIC-hez) teamingjét override-olod, és csak 1-et hagysz benne.
Tehát a VM port gorupukhoz a teaming:
- nic1 active
- nic2 activeiscsi vmk1-hez:
- nic1 active
- nic2 unusediscsi vmk2-höz:
- nic2 active
- nic1 unusedMivel te nem fogsz tudni LACP-t csinálni, csak etherchannelt, így azt ki kell próbálni, de véleményem szerint ugyanezzel a megoldással működhet. Így az iSCSI-nál is menni fog a multipath, és a vm-eknél is az ip hash alapú load balancing ugyanazon két interfacen.
Itt egy jó doksi a témában:
https://connect.nimblestorage.com/servlet/JiveServlet/downloadBody/1242-102-1-1173/LACP.pdf
Régi kicsit ugyan, és egy bizonyos storageről van benne szó, de ez figyelmen kívül hagyható.
-
válasz
balaaa88
#3736
üzenetére
iSCSI amúgy más tészta, mert ott ugye protokoll szinten van round-robin multipath, tehát nem szükséges bűvészkedni interface teamingel, simán megy 2x10G NIC-el a 20G, ha jól állítod be a bindinget esxi oldalon, és target oldalon is jó a multipath config. Az már persze más kérdés, hogy ez inkább elvi dolog, mert target oldalon gondolom nincs olyan storaged ami 20G-t ki tudna szolgálni
-
Szerintem az általa vázolt felállásra nincs igazán megoldás. De javítsatok ki ha tévedek.
Ha jól értem, akkor az igazi kérdés az, hogy adott időben 1db vm tud-e 1db backup szerverrel komminikálni, úgy, hogy 20G-t kapjon (2x10G fizikai uplinken). A gond az, hogy ez esetben az ip hash és/vagy a virtaul port id mindig ugyanaz lesz, az esxi-nek pedig nincs olyan load balancing algoritmusa ami erre az esetre tudná biztosítani a 2db fizikai uplink összeadott sávszélességét, függetlenül a uplink teaming megoldástól (etherchannel vs. LACP)
Tehát 2x10G uplink esetén a vázolt forgalom mellett 1db vm-nek mindig csak 10G sávszélessége lesz a backup szerver felé. Persze több vm ki fogja tudni tolni a 2x10G-t, vagy 1db vm is ki tudja több darab backup szerver felé. Ez az egész független attól hogy LACP-t vagy etherchannlet használ (vagy pl LBT-t).
Esetleg alkalmazás vagy guest OS szinten lehet megoldani a dolgot, ha a backup megoldás tud kezelni több kliens oldali IP-t/interfacet, vagy ő maga képes 1db vm-et több saját interface-én menteni, akkor növelhető a sáv, tisztán vmware oldalon viszont nem.
Ha viszont eleve arról van csak szó, hogy a backup windowban a sok vm tudja kitolni mindkét 10G-s kapcsolatot (és nem feltétel hogy 1db vm is tudjon 20G-vel forgalmazni önállóan), akkor etherchannelt kell konfigurálnia mert LACP-t nem tud (nincs vCentere- > nincs dVS -> nincs LACP).
-
válasz
balaaa88
#3732
üzenetére
Itt szerintem minden kérdésedre megvan a válasz:
vCenter nélkül nincs dVS-ed, amivel két módot buksz:
- Route Based on Physical NIC Load (ez viszont nem érint)
- "Route Based on IP Hash" módban az LACP-tAmit tudsz standard vswitchel:
- "Route Based on IP Hash" módban etherchannelt
Mivel ez IP hash alapú, ezért akkor van igazán értelme ha a vm-jeid több destination IP-vel kommunikálnak egyidejűleg. Ha 1db vm-ed akar 1db valamivel kommunikálni, akkor a hash kalkuláció miatt mindig ugyanazon az uplinken fognak kimenni a csomagok, tehát plusz sávszélességet ebben az esetben nem nyersz.
-
#3692
Chal
addikt
Core2duo6600
#3691
válasz
Core2duo6600
#3691
üzenetére
Gondolom mert benne van a driver a sata vezérlődhöz. Nézd meg, hogy konkrétan milyen van a gépedben, és keress rá. Ha szerencséd van, akkor lesz hozzá alternatív vib, és tudsz csinálni a gépeden működő telepítőt.
Amúgy ezt a kliens dolgot, meg web felület támogatást nem teljesen értem, mi a gond konkrétan a 6.5-el?
-
Értem de erre mondtam, hogy nem lehet, nem tud ilyet
Így feleslegesen izgulsz rajta hogy ki tudod e próbálni. Ha nincs supportod a gyártótól (és gondolom nincs, mert akkor nem merült volna fel a kérdés), akkor az egyetlen lehetőséged hogy keresel a neten infót arról hogy működik e hasonló megoldás valakinél, és hogy mik vele a tapasztalatai. -
Szerintem ez nem fog menni. Ilyet nem tud az esxi, gyakorlatilag saját magának kéne emulálnia egy hba-t (nem a vm-eknek) hogy tesztelni tudj.
Inkább válaszd ki a HBA-t, nézd át a compatibility guide-okat, keress rá hogy mások használják e passthrough módban esxi alatt, akár LTO-val, stb..
Kiindulási alapnak jó lehet:
-
Közben kiderült, hogy akkor tapasztalható ez a jelenség, ha wifin csatlakozom és arra bridgel a Fusion. Valószínűleg mindig is ilyen volt, csak nem vettem észre, mert a drótos interfacet is használom.
Pár helyen azt írják, hogy AP függő a dolog, de nem találtam konkrét infókat hogy milyen feature szükséges pontosan. Valaki esetleg nem tudja?
Másik érdekessége a dolognak, hogy a DHCP szerver logja alapján a vm-ek a saját MAC-jükkel küldik a requestet, így kapnak is IP-t, a lease táblában is azokkal vannak benne. Viszont a router, vagy másik LAN-on levő fizikai eszköz ARP táblájában kizárólag a host fizikai wifi interface-ének a címe látható csak. Furcsa.
-
Fusiont használ valaki? Én elég régóta, de ilyet még nem láttam:
https://www.dropbox.com/s/dzuao1vqk5ylxbm/Screenshot%202016-11-27%2019.32.10.png?dl=0
A screenshoton a routerem arp táblája létszik. A megjelölt mac címek mindegyike egy-egy virtuális gép a Fusionben. Maga a cím a host rendszer fizikai mac-je. Nem is működik jól a kifelé forgalmazás. Természetesen bridged network van nekik beállítva. Mi a fenétől van ez?
Rémlik, hogy nemrég jött egy Fusion update, de mintha utána még jó lett volna, viszont nem vagyok benne biztos sajnos, lehet hogy ehhez köthető.
-
válasz
kraftxld
#3655
üzenetére
Ja, a szokásos
A VCP vizsgák nekem mindig is inkább arról szóltak, hogy a kérdések egy részénél ki tudom e találni hogy vajon mi a k* a*-ra gondolhatott a "költő", a többinél meg hogy tudom e fejből karakterre pontosan hogy hogy is van egy fél kilométeres command szintaxisa. -
Jól érted.
CsodaPOK: gondolom azért tiltják mert egy csomó featuret bukik vele az user, ha local diskről van szó. Egyébként amennyire kiveszem ez valami home szerver lehet, szóval ha így akarja megfaragni hát faragja megy így, ha stabilan működik akkor még akár jól is járhat vele, bár én nem így csinálnám
A második tippem meg az, hogy valami virtuális NAS-nak kell talán, bár erős a gyanúm nekem is, hogy nincs ott olyan hálózat meg kliensek amik indokolnák a virtuális disk vs. RDM közötti performancia hajkurászást Egyébként többen is jöttek már ide ezzel a témával, ha jól tévedek akkor valami Synology-tól lenyúlt sw-t hajtanak esxi-vel, Xpenology vagymi. Nekem erről az a véleményem hogy az ilyen vasakra tenni kell egy Linuxot natívan, aztán beállítani rajta azt a kb. 4db szolgáltatást amit az ember használ, a csillvilli "majdnem olyan" cukormázat meg el kell felejteni, mert szerintem sose lesz "olyan". Ráadásul a Linuxban ezer+1 módja van annak hogy vm-eket is létrehozzon az ember a fileshare szolgáltatások (meg gondolom torrent kliens) mellé, ráadásul frankó sw raid, lvm, stb.. megoldásokkal, jó hw támogatással a dzsunka PC vasakon is. Ha nem vSphere labort épít az ember, akkor szerintem százszor jobban jár ezzel.
-
Szerintem marad 0 és 1, csak nem lesznek benne egyik vswitchben sem, mert ezek más kártyák, fel kell vinned őket uplinként. Új telepítés esetén vagy scriptelni tudod a dolgot, vagy ha van licenced akkor használhatod a hostprofile funkciót a vcenterben.
Egyébként még csak nem is unix based. Amire te gondolsz, az szerintem a management konzol. Maga a hypervisor illetve a vmkernel a vmware szerint nem tartalmaz linux kódot, teljesen saját fejlesztés. Viszont ez az állítás egyre inkább sántít, folyamatban is van emiatt egy per. Meglátjuk mi lesz a végeredménye.
-
válasz
pumukli93
#3602
üzenetére
Ez alapján úgy tűnik, hogy a disken levő dolgokkal nem oké valami, nincs mbr/gpt, sérült a filerendszer, etc etc... Szóva ne vmware szinten keresd a hibát. Bootolj be pl. valamilyen live rendszert (vagy add oda a disket másik vm-nek amin rendelkezésre állnak esetleg ilyen toolok), és ellenőrizd le vele a fs-t, mint ahogy amúgy tennéd bármilyen gép esetén (akár fizikai) ami ilyen hibát produkál.
-
válasz
pumukli93
#3589
üzenetére
Mielőtt jobban belebonyolódunk, szerintem fogj egy kábelt, dugd össze őket direktben, mindegyiknek adj manuálisan ip-t ugyanabból a tartományból, és nézd meg úgy. Ha megy, akkor a hálózattal van gond. Ha nem megy, akkor lehet tovább nyomozni esxi vagy kliens oldalon.
-
válasz
pumukli93
#3586
üzenetére
Akkor lehet, hogy tűzfal probléma. Milyen eszközök vannak a két gép (kliens, esxi host) között, illetve milyen hálózatban vannak?
Tuti egyáltalán, hogy az esxi válaszol amikor a kliensről pingelsz? (A kliensen az arp táblában ellenőrizd a mac címet, úgy kiderülhet gyorsan).
-
A vmware-cmd man-ját nézd át.
Minden power parancshoz tartozik egy mode flag, ami lehet soft vagy hard. Soft esetén állítja le a guest OS-t, hard esetén kiveszi alóla az "áramot". Softnál természetesen szükséges a vmware tools. Ha jól rémlik van trysoft opció is, ami első körben soft poweroff-ot próbál, majd ha nem sikerül (pl. a tools hiánya miatt) akkor megy neki egy hard.
-
Sajnos nem tudsz upgradelni ingyen, csak főverzión belül lehet patchelni
Illetve olcsóbban lehet főverziót váltani ha megvetted az előzőt.Amúgy ha hw ügyileg minden rendben van a mac-el, és a rajta levő osx-el is, akkor én írnék a vmware supportnak, mert ez semmiképpen sem normális.
Egyébként én ráadásul hackosx-en (nem gyárt sajna az Apple olyan gépet ami alkalmas lenne vSphere labornak (és a MacPro-t nem számolom ide érthető okokból..), így megoldottam magamnak a dolgot
) hajtottam sokáig 7-est, az utóbbi időben váltottam 8-asra, de soha semmi problémám nem volt a Fusion-el. -
válasz
Rocko007
#3573
üzenetére
Van ehhez egy vicces topic itt, nem tudom olvastad e már:
https://communities.vmware.com/thread/508862?start=0&tstart=0
Egyébként én LSI vezérlők vs. ESXi kapcsán már rég feladtam a harcot a nyavajás vib-jeikkel meg ilyen-olyan szedett vedett moduljaikkal. Van nekik egy lsiutil nevű binárisuk, 1db statikusan fordított tool, minden szarra kiadták, van esxi-re is. Felmásold scp-vel, és ssh-n tudod futtatni, nem kell hozzá semmi. Megfelelően felparaméterezve bármit ki tudsz belőle szedni a monitoringoz, vagy ha csavarni kell valamit a kártya vagy a tömb configján, akkor azt is tudja (ehhez van interaktív menüje is), illetve firmwaret is tudsz vele upgradelni valamint configot menteni/restore-olni. Szóval én ezt scripteltem le, és ez ad a monitoringnak adatokat a kártya/akku/tömb állapotáról.
Itt egy régi kb, amihez csatolták a toolt is:
Jó régi, de amúgy van belőle újabb verzió is ha jól rémlik, csak ki kell túrni, de simán lehet hogy ez is megy, elég fapados az egész, dirketben hívogatja a kártyát pci-e-n, nem igazán függ ESXi verziótól a dolog így. Esetleg az adott kártya támogatása miatt érdemes újabb verziót keresni belőle.
-
-
válasz
MrSealRD
#3562
üzenetére
A VMware azt kommunikálta a kirúgások után, hogy nem fogja érinteni a termék jövőjét a dolog. Ez volt a hivatalos mondás, a többit meg mindenki hozzágondolhatja, igazából nem tudni nagyon róla semmit. Van olyan elmélet, hogy elég közel hozták az utóbbi években az esxi-hez a workstationt hypervisor szinten (hiába type 1 vs type 2, házon belül nem egy nagy kaland ezeket portolni), és így tulképpen a Workstationhöz inkább gui fejlesztői erőforrás kell csak.
Egyébként meg ha bármi gondot okoz ez, annak látszata csak pár év múlva lesz szerintem a WS akkori minőségében/tudásában.
-
válasz
TheProb
#3538
üzenetére
Szerintem első körben nézd meg a logokat, mert ez így kevés infó, illetve az nfs helyett én ISCSI-t javasolnék.
A vcenterben levő nested és fizikai hostot én nem érzem problémának, szerintem a vcentert marhára nem érdekli hogy melyik host milyen platformon fut, illetve ezek relációja (max az EVC beállításoknál futsz bele ebbe, de az más tészta).Látatlanban még: DNS-t és timesync-et ellenőrizd mindenhol (ha lehet használj NTP-t ez utóbbihoz). De tényleg kevés infó ez így, túrni kell a logokat host és NFS szerver oldalon is első körben, másodikban a vcenterben is.
-
válasz
kraftxld
#3531
üzenetére
Szerintem a VCP tesztek elenyésző részben mérnek csak tudást
Nem mondom hogy egyáltalán nem, mert az nem lenne igaz, de jelentős része szívatás, vagy egyéb olyan dolog aminek semmi köze ahhoz hogy kiderítse hogy jó szakember vagy e. Én a hivatalos példa vizsgát néztem a minap, a hajamat téptem amikor megláttam a klasszikus idiótaságot: kilométer hosszú parancs, és mond meg négy közül hogy melyik a jó! Az eltérés közöttük jobbára az, hogy fel van cserélve az opciók sorrendje Csak gratulálni tudok annak aki ezeket a baromságokat kitalálja. -
válasz
kraftxld
#3526
üzenetére
Nem online, az 5.5 deltából van még elérhető online VCP vizsga. Bónusz kérdés: azt tudja valaki hogy ezt meg lehet e csinálni újra, illetve jó e a CERT megtartáshoz? Kényelmes lenne most. Felmerült bennem, hogy most a "túlélésre" játszanék, aztán ha majd kicsit nyugisabb lesz az élet pl. télen, akkor néznék olyat amivel előre is lépek.
-
válasz
bugizozi
#3523
üzenetére
Grat!
Én is éppen tegnap nézegettem a lehetőségeket, mert novemberig lépnem kell. 2 éve csináltam egy vcp 5.5 deltát (online verziót), akkor hozták be ugye a 2 éves elévülést, és nem voltak még kint a 6-os vizsgák, tehát csak a recertificate policy miatt voltam rákényszerülve. Ez alapján jó lenne nekem is most a 2V0-621D ha csak megújítani akarok, illetve 6-osra upgradelni, ugye?
B terv hogy VCAP irányba megyek, de arra még alszok párat, túl sok a zavaró tényező a felkészülésben (nyaralás, meg egyéb hülyeségek
). -
válasz
bugizozi
#3512
üzenetére
Próbálj tolni egy rescan-t ha még nem tetted volna meg. Amúgy a dolognak az is feltétele, hogy a szabad hely fizikailag a növelni kívánt vmfs partíció mögött legyen a disken (sima vmfs grow esetén), vagy legyen szabad device amit hozzá tudsz fűzni (extent összefűzéses növelés esetén).
-
válasz
TheProb
#3507
üzenetére
Mért jobb csinálni egy vNAS-t és azon pl egy iSCSI-t vagy NFS-t beállítani, mint a DAS-ból csinálni egy volume-ot amit mind2 nested host lát? Vagy akár egy vSAN.
Mert ez nem shared storage lesz a nested hostok szintjén (mindegyiknek lesz 1 virtuális diskje, amiről fut, de a másikéról nem fog tudni), tehát nem tudod a cluster funkciókat használni majd a laborodban.
-
válasz
TheProb
#3501
üzenetére
Bocs, de nekem nagyon nem volt tiszta. hogy most szakdolgozatot akarsz írni best practices-ről VDC design-ról, vagy labort akarsz, ezért írtam kétszer is hogy nem értem a kérdéseket. Az egyik esetre túl általánosak voltak, erre így ebben a formában nincs válasz. A másik esetre (labor) meg kevés volt az infó (mit akarsz pontosan, mi a cél, mi áll rendelkezésre, stb..).
De úgy látom most már kezd sínre kerülni az ügy
-
válasz
TheProb
#3499
üzenetére
Ha nincs különálló datastore (pl HP MSA), hanem a serverben lévő diskeket használom akkor a RAID kialakítását a szerver RAID kezelőjében vagy hypervisor-ban érdemesebb megvalósítani, gondolom utóbbi, nem?
Ezt a kérdést sem lehet így megválaszolni. Nincs olyan hogy hogy érdemes, adott feladat határozza meg, és sok esetben még úgy is marad játéktere az üzemeltetésnek, hogy a saját bevált megoldásait alkalmazza, amik eltérőek lehetnek, de ettől még mindegyik jó. A hypervisorban amúgy ilyet eleve nem csinálsz, mert nem erre való/nem tudja. Ha a VSAN-ra gondolsz, akkor arra hunyorítva azt lehet mondani hogy ilyesmi, de durva ára van, eleve nem egy elterjedt dolog.
maradék 6ot nem "bántom" a HP-s RAID managerben, hanem majd VMware-ben állítom be RAID10-nak pl, nem?
Nem tud ilyet a VMware. Vagy a raid controllerel kell megoldani, vagy VSAN de azzal már nagyon más lovon ülünk megint (lásd fent).
-
válasz
TheProb
#3497
üzenetére
Nem egészen értelmezhető a kérdés. Az FT-nek önmagában semmi köze a raidhez. Mi van ha pl. shared storage van az FT alatt raid megoldás nélkül? Keresztet vethetsz rá, hiába működik az FT.
A raid level meg megint design kérdés, illetve itt sem tiszta, hogy mire gondolsz. Az ESXi-t magát is érdemes redundáns volume-ra telepíteni ha éppen nem hálózatról bootol, hiszen ha kiesik a disk alóla, akkor nincs log, coredump, és a következő rebootkor nyilván nem fog tudni elindulni. De ez is egy soktényezős dolog, van aki azt mondja, hogy röhögve telepíti pl egy bladeben levő embedded SD kártyára az ESXi-t, a log meg a coredump remote megy, az esetleges boot disk halála esetén pedig kiveszi a hostot a termelésből mert van egy csomó másik. Akárhogy is, ha már disk van alatta és redundánsra szeretnéd, akkor oda elég egy mirror is, nem kell 1+0.
Aztán ott a vm datastore, ahol viszont elképzelhetetlen a redundancia hiánya. Az alá mindenképpen kell valamilyen megoldás, terheléstől, alkalmazástól, és a használt eszköztől függően kell kiválasztani a raid levelet (már ha raid egyáltalán).
-
válasz
sto1911
#3452
üzenetére
Az amúgy annyiból jobb lett volna, hogy lett volna kézben egy igazolható kifizetésem. Ugye a végén tudod megadni hogy kártya, átutalás vagy voucher. Ha azon átmész, akkor olyan mintha kicsengettél volna 350 dollárt, függetlenül attól hogy vouchert adtál meg. Tehát lett volna egy alapom a reklamációra, és esetleg májusra is lehetett volna tolni ha valami mégsem úgy sül el. Hiszen az nem az én hibám, magának a vouchernek a felhasználása pedig megtörtént a lejárat előtt. Mindegy, késő bánat.
-
Roppant mérges vagyok, muszáj leírnom: a Számalk sikeresen elcseszett nekem egy 100%-os VCAP vouchert. Az történt, hogy regisztráltam náluk a vizsgára 3 hete, telefonon is egyeztettem velük többször, jeleztem hogy a voucher április 30-án le fog járni, illetve 28-ra (mára) kértem időpontot. Meg is jött a visszaigazolás, gondoltam minden rendben. Viszont tegnap jött tőlük egy fél soros e-mail, hogy sorry, MA(!!) akarták a kuponnal regisztrálni a vizsgát a Pearson-nél és nem sikerült, keressek másik vizsgaközpontot, további minden jót, viszlát.
Felhívtam őket, kiderült hogy náluk az a szokás, hogy előtte nap regisztrálnak. Arra a kérdésemre, hogy akkor mi a francért beszéltük meg csomószor hogy ez a voucher le fog járni, és miért nem vették figyelembe, nem kaptam választ. A hölgy folyamatosan mellébeszélt, először azt állította hogy 3 hete beregisztrálta, de ma utasították csak vissza. Mikor kértem tőle az ezzel kapcsolatos e-maileket, amivel tudnék reklamálni a Vmwarenél, akkor elismerte, hogy igazából csak a saját rendszerükbe kerültem be, a Pearsonnál csak ma akartak regisztrálni, és az elmúlt hetekben befutott pár igény online is, így betelt a nap.
Az egészben az a legszebb hogy azt sem mondták hogy "sajnáljuk". Közölték, hogy figyelmesebben is elolvashattam volna a visszaigazoló e-mailt, mert ők abban a jelentkezést igazolták vissza, nem pedig a vizsga regisztrációt (mintha bármi közöm lenne a belső folyamataik hátteréhez).
Természetesen sehol nincs már időpont erre a 2 napra, sem náluk, sem a másik hazai vizsgaközpontban, sem a két legközelebbi külföldiben (Ausztria, Románia). Szóval így jártam.
Hogy miért nem online regisztráltam: egy kollégámmal szerettem volna menni, aki 28-ra regisztrált sikeresen online. Nekem már nem kínálta fel ezt az időpontot, csak 29-et. Felhívtam a Számalkot hogy jó lenne a 29 is, de van e arról infójuk hogy a 28 miért nem megy? Azt mondták hogy azért, mert bugos a Pearson felülete, gyakran előfordul, több szabad helyük is van 28-ra, küldjem el a vouchert meg egy jelentkezési lapot e-mailben, és kézzel megcsinálják, minden rendben lesz. Hát nem lett.
-
válasz
bugizozi
#3422
üzenetére
Hát fizetősen nem lenne nagy hír, mármint ugye ahhoz nem kéne semmilyen támogatás, bárki meg tudná tartani aki kellően bátor a befektetés kapcsán
Én végig úgy értelmeztem, hogy attól nagy dobás ez, hogy a VMware támogatja.Bár most hogy így mondod, a VMworld-ért is le kell tenni egy vagyont, ha az ember mindent beleszámol, szóval logikus a kérdés
-
válasz
Konflikt
#3361
üzenetére
Nagyon sokan már tényként kezelik hogy a Workstation és a Fusion ennyi volt, pont erre akartam célozni, hogy felesleges.
De akkor az én tippem: szerintem core már jó régóta esxi kódbázis lehet (ez itt-ott ki is lóg), azt a vékony réteget amitől type2 lesz, + a GUI-t meg szerintem egy sokkal kisebb csapattal akarják továbbvinni.
-
válasz
Konflikt
#3356
üzenetére
Én az első hírtől kezdve követem, de rohadtul nem találni semmilyen konkrétumot azzal kapcsolatban hogy leállna. Ami biztos: kirúgtak egy csomó embert az USA-ban, akik ebben a teamben voltak. A VMware annyit kommunikált hogy az említett két termék marad, a fejlesztések és a support nem áll meg.
Egyesek szerint csak költséget optimalizálnak, és kiviszik Kínába a fejlesztést. Az egyik kirúgott alkalmazott elejtett egy olyat ugyanis, hogy kapott ezzel kapcsolatos ajánlatot illetve alternatívát.
-
válasz
kraftxld
#3345
üzenetére
Eléggé eszközfüggő a dolog, én nem jelenteném ki biztosra hogy nem megy, volt már nekem is szerencsém smartcard readerrel.
Szóval adott USB devicevel meg kell próbálni, lehet hogy bejön, lehet hogy nem. Mondjuk a tervezési fázisban ez édeskevés segítség, de ott meg úgy kell nekiállni hogy usb-over-ethernettel kalkulálni, aztán max plusz öröm ha nem kell
-
#3330
Chal
addikt
mandriva11
#3329
válasz
mandriva11
#3329
üzenetére
Egyelőre GUI esetén natívan sehogy, csak ha van vcentered, és azáltal Webcliented. Ha minden igaz, akkor ez rövidesen változni fog, mert kapnak az esxi hostok is saját beágyazott webguit, de hogy az első stabil változatok mennyire lesznek használhatóak azt még sajnos nem tudni. Addig linux alól marad az emuláció, virtualizáció, jump szerver, etc.., vagy persze a jó öreg ssh
-
válasz
RoyceHUN
#3322
üzenetére
Én nem bonyolítanám túl, a Windows beépített backup toolja ezer éve tud image alapú mentést készíteni a rendszerdiksről, ráadásul inkrementálni is tudja. A kapott image VHD formátumú, a windows telepítők recovery módja meg tudja nyitni (meg mellesleg a HyperV is, de az most offtopic
), és ki tudják írni fizikai diskre. Így bármilyen virtuális gépben vagy fizikain vissza tudod állítani könnyen, gyártó által támogatott módon.Nagy hirtelen gugli után:
http://www.howtogeek.com/howto/4241/how-to-create-a-system-image-in-windows-7/
A hw kompatibilitással kevés tapasztalatom van, meg eléggé off itt, ha nem oké (és az semmilyen módszerrel nem lesz oké akkor, szóval független az image készítő megoldástól/klónozástól), akkor kérdezd meg inkább a Windows topicban.
-
A CPU kb teljesen lényegtelen, legyen valami modernebb, nyilván mindenféle vt* támogatással, felesleges(*) a xeon, de még az i7 is.
(*)Gondolom csak tudnál róla ha CPU igényes műveleteket akarnál futtatni a vm-ekben, ahhoz méretezz, ne ahhoz hogy hány darab Windows/Linux/akármi lenne rajta. Ezeknek "nulla" a CPU igénye önmagukban. Szóval a CPU-t ugyanúgy méretezd mintha nem virtuális gépet raknál össze. Az alkalmazásokat gondolom ismered, azokkal számolj.
-
A storage traffic mindenképpen legyen külön. Ami alá én nem mennék:
- storage
- vm
- mgmt, vmotionA backupot vagy a vm network, vagy az mgmt/vmotion mellé tenném, a backup jellegét, a hálózati terhelést, meg a biztonsági policyket figyelembe véve.
Hogy ebből hogy csinálsz kettőt, azt nagyon át kell gondolni, nem is tudnék olyan példákat írni amik ne lennének egyformán rosszak. De talán nagyon nagyon halkan azt merném mondani, hogy a storaget betenném az mgmt meg a vmotion mellé, mert azoknak a forgalma tervezhető, és nyilván egy rommá terhelt iscsi network mellett nem állsz neki pl. az mgmt network durva nyúzásának. Ezt pl. a vmnetwork esetén ugye nem biztos hogy meg tudnád tenni, mert annak a forgalma tőled független.
-
Na, közben meg is néztem:
By default, VirtualBox uses the BIOS firmware for virtual machines. To use EFI for a given virtual machine, you can enable EFI in the machine's "Settings" dialog.
Szóval a vbox alapból bios-t használ, ezért megy vele a meglevő pxe setupod. Egyébként VmWare esetén is ez a default ESXi-nél meg Fusionnél is, Workstationnél nemtom miért szaladtak ennyire előre.
-
válasz
Mr Dini
#3289
üzenetére
Ilyen formában nincs igazán összefüggés az uefi és a bios között, PXE esetén mindegyik a DHCP-től fogja megkapni a tftp szerver IP-jét, illetve a bootfile-t (option 66/67). Az persze már valóban nem mindegy, hogy a bináris amit küldesz neki, milyen formátumú. UEFI-hez más kell, a sima pxelinux.0 nem fog vele menni. Viszont a pxelinux tartalmaz (U)EFI kompatibilis kódot is, itt megtalálod hogy pontosan hogy érdemes használni:
http://www.syslinux.org/wiki/index.php/PXELINUX#UEFI
De ha nem akarod ácsolgatni, akkor tényleg kapcsold át a vm-jeid BIOS-ra és ennyi. Vbox-al gondolom azért megy mert az bios -t használ a vm-ekhez, vagy valamilyen hibrid megoldást.
) hogy hogy kellene lekapcsolni. És ez csak a jéghegy csúcsa.
Új hozzászólás Aktív témák
- GoodSpeed: Windows 11 PRO FPP (Full Packaged Product) - Retail, Box, dobozos
- iPhone topik
- Honor Magic5 Pro - kamerák bűvöletében
- Genshin Impact (PC, PS4, Android, iOS)
- Óra topik
- Eredeti játékok OFF topik
- Renault, Dacia topik
- Revolut
- Path of Exile (ARPG)
- Milyen monitort vegyek?
- További aktív témák...
- Játékkulcsok olcsón: Steam, Uplay, GoG, Origin, Xbox, PS stb.
- Game Pass Ultimate előfizetések 1 - 36 hónapig azonnali kézbesítéssel a LEGOLCSÓBBAN! AKCIÓ!
- Adobe Előfizetések - Adobe Creative Cloud All Apps - 12 Hónap - 15% AKCIÓ
- Windows 10 11 Pro Office 19 21 Pro Plus Retail kulcs 1 PC Mac AKCIÓ! Automatikus 0-24
- Bitdefender Total Security 3év/3eszköz! - Tökéletes védelem.
- Dobozos ASUS TUF A15 Ryzen 7 7735HS 16 GB DDR5 512 GB SSD RTX 4060 140W (8 GB) Garancia
- HIBÁTLAN iPhone 11 Pro Max 64GB Gold -1 ÉV GARANCIA - Kártyafüggetlen, MS4584
- Akció! Csere-Beszámítás! Asus Zenbook 14 UM425IA! R7 4700U / 8GB / 512GB SSD!
- Apple iPhone 13 128GB, Kártyafüggetlen, 1 Év Garanciával
- REFURBISHED - DELL Docking Station WD19, WD19S + 130W, 180W töltővel
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest