[Megoldva] Laptopon virtualizálnék - ha lehet

Virtualizáció

Tanácsot kérek a témában tapasztaltaktól, hogy laptoppon, mely tipusokkal és milyen sarok paraméterekkel lehet "normálisan" dolgozni. A gazda gépen, 2- 3 db virtuális gépnek kellene futni, program fejlesztés, tesztelés, kvázi server cliens kapcsolatokkal. (A gép hurcolászása elkerülhetetlen.)

Tapasztalatok nélkül amire gondoltam:
Intel Core i7 + Processzor órajel: 2.33 - 2.50 GHz + 8 GB memória + Kijelző mérete: 16 - 17.30" + Merevlemez kapacitása: 760 - 1 000 GB

Ezt dobta a gép : http://www.arukereso.hu/notebook-c3100/f:intel-core-i7-processzor,proce…

Melyiket ajánljátok és miért?
- -
üdv : virtualm

szerk: [Megoldva]
A megcélzott kaliberű gépet az elkövetkezendő hetekben kapom meg. Mindenkinek köszönöm a segítséget. Ha esetleg érdekel valakit, akkor majd beszámolok.

  • 11058 megtekintés

( Fisher v | 2013. 03. 28., cs – 22:47 )

Tapasztalatom szerint a memória mennyisége az, amit nem lehet fölébecsülni :) Amúgy nekem egy msi pr200-ason fut hol egy xp hol egy win7 teszteléshez, és én elvagyok vele. De én másra használom, szóval először be kéne lőni hogy mennyit esznek a virtuális gépek, ahhoz hozzáadni annyit, amennyi szerinted kell a gazdagépnek, és máris mindent tudsz.

Ja és marhára nem mindegy hogy kvm/virtualbox vagy lxc/openvz féle virtualizációt használsz.

http://www.arukereso.hu/notebook-c3100/16-gb/
http://www.interstore.hu/termek/ASUS-NOTEBOOK-G75VX-CV042H-FULL-HD--3D-… - ez aztán vagy van, vagy nincs, de elméletileg ilyen is létezik.

( uid_2716 | 2013. 03. 28., cs – 23:10 )

A fejlesztéshez-teszteléshez használt keretrendszer memóriaigényétől függően környezetenként 4GB is indokolt lehet (== 16 GB).

Legalább egy SSD elengedhetetlen szerintem. Tf. két VM párhuzamosan hajtaná a "saját" virtuális diszkjét, te pedig a hoston valamilyen interaktív, diszkfüggő műveletet végeznél (git blame hideg cache-sel, páldául). SSD(-k) nélkül beleőszülsz.

Szerkesztés: legutóbb azt olvastam (ha jól emlékszem), hogy bizonyos ThinkPad modellekbe akár három diszket is be lehet rakni (egyet a normál helyre, egyet az optikai meghajtó helyére dokkolva, a harmadikat meg valami speckó helyre; bocsánat, nem emlékszem). Három 256GB-s SSD-vel RAID 0-ban már ellennél. (A hosszútávú adatbiztonság másodlagos, a teljesítmény elsődleges.)

Túlzásnak tűnhet a fenti, de ránézésre szerverjellegű terhelést akarsz hordozható eszközön futtatni, interaktív munka mellett. Normálisan ilyesmire van fejlesztői munkaállomás (esetleg erősebb laptop) plusz egy külön fejlesztői teszt-szerver.

Az interaktivitás megőrzését a host környezetben nem lehet túlhangsúlyozni. Feltételezve mondjuk egy 5 percig tartó tesztet, annak futása közben valószínűleg képes akarsz lenni dokumentációt olvasni, forrást greppelni, fordítani, levelezni.

Alternatív megoldásként érdekes lehet egy az Ebay-en árult DVD-HDD átalakító keret beszerzése.

Múltkor elgondolkoztam a dolgon, miután egy ismerős gépét SSD-sítettem - persze szárnyra kapott szépen.
Ekkor nézegettem kicsit és egész szimpatikus megoldásnak tűnik.
Egyfelől CD/DVD-hez manapság viszonylag ritkán nyúl az ember, másfelől ki lehet tenni külső USB "adapterbe" és elfér a notebook táskájában, ill. arra az időre nem zavar, amíg az ember használja.

Viszont így SSD mellé bepakolhatok egy HDD-t is.
Az IDE DVD meghajtónál kell egy átalakítás is, SATA DVD esetén gyakorlatilag közvetlenül mehet a vezérlőre.

Tapasztalatom még nincs a dologgal, ehhez a géphez is csak mostanában lett megrendelve - tulaj pedig visszament Angliába, így egy darabig nem is igazán fogom látni közvetlenül.

Viszont két HDD gyakorlatilag bármelyik gépben megoldható így.

Ha lesz egy kis időm ilyesmire és erre szánt pénzem, a sajátomat is meg fogom csinálni hasonlóképpen.
Időnként érzem, hogy a HDD eléggé visszafogja a gépem... SSD viszont nagyon sokat dobott azon a másikon... túl sokat. :)

Így van a T430i-ben van egy mSATA csatlakozó ide lehet max. 128GB méretű SSD-t rakni. Kicserélheted a normál vinyót is 2,5" SSD-re, és van gyári hdd keret az optikai meghajtó helyére amibe szintén tehetsz SSD-t. Az mSATA használata esetén a T430i-be nem tehetsz 3G adaptert, mivel ugyanazt a csatlakozót használják.

Attól függ. :)

Milyen SSD (SLC vagy MLC pl.), milyen gyakori írásműveleteket hajtasz végre és milyen előzetes intézkedéseket tettél az SSD megóvása érdekében.

Az én megoldásomban az SSD kisegíti a HDD-t a rendszer pörgőssé tételében, de az adattárolás végső soron a HDD-n marad.
Így elméletben nincs gond vele.

Ha minden erről megy és hosszabb távra tervezel, érdemes lehet beruházni egy drágább, SLC példányra.

Előzetes intézkedések

Nekem most kettő jut eszembe: TRIM támogatása/áteresztése az összes szoftverrétegben, illetve partíciók / md / LVM / dm-crypt / fs struktúrák olyan elhelyezése, hogy végső soron minden írás elég nagy blokkhatárra essen. Ha jól tudom, modern disztribúciókban az összes általánosan használt utility fel van készítve az utóbbira, az előbbihez viszont különféle opciók kellhetnek.

https://wiki.archlinux.org/index.php/Solid_State_Drives

TRIM hiányában olyan tanácsot hallottam, hogy a diszk 1/5-ét érdemes particionálatlanul hagyni (a diszk teljes élettartama alatt egyetlen írás se essen abba a (logikai) szektor-tartományba).

kisegíti a HDD-t

Azokat a file-okat, amelyek kicsik, ésvagy többnyire véletlenszerűen vannak elérve, ésvagy az elérés többnyire olvasás (+ relatime mount opció, ma már default), az SSD-re teszed. Ez megkíméli a HDD-t a fejrángatástól (nagy szekvenciális elérések maradnak rá).

SSD-vel megnövelheted a swap-et is. Létezhet olyan adathalmaz, ahol a méret miatt kénytelen vagy HDD-t használni, de bármennyi extra RAM, amit cache-ként szolgálatba tudsz állítani, javít a teljesítményen. Ilyenkor (az archlinux wiki ajánlásával némileg szembemenve) magas swappiness érteket beállítva a kernel a processzek régebben használt privát/írott lapjait hajlamos lesz a swap-ba írni, és a felszabadult RAM-ot inkább cache-ként használni.

SSD nélkül ez általában azt jelentette, hogy egy érintett (kilapozott) processz feléledésekor akár tíz másodperceket is várni kellett; SSD swap-pel (plusz a processz binárisának (= text page-einek) szintén SSD-n tartásával) ez valószínűleg lényegesen felgyorsul. Magyarul SSD-t swap-ként használva a RAM-odból többet tudsz cache célra fordítani, úgy, hogy egyidejűleg az interaktivitásról sem kell végleg lemondanod. Hátránya, hogy a gyakori írás gyorsabban csökkenti az SSD élettartamát.

pl.

- Partíciók illesztésére figyelsz (lehetőleg amit az SSD egy tömbként kezel, azt te is egy tömbként kezeld és ne akard kettő határára tenni, mert lassú lesz és fölösleges köröket ír miatta)
- Nem írod feleslegesen a file/könyvtár-hozzáférések időpontját (noatime mount opció)
- Gyakran változó, de nem kritikus dolgokat tmpfs-re teszed. Pl. /tmp, /var/tmp, /var/spool, ilyenek.
/var/log mehet a HDD-re vagy ez is tmpfs-re, ha nem hordoz kritikus információkat (esetleg bizonyos időközönként készítesz mentést róla)

Kisegítést úgy értettem, hogy a sebesség-kritikus dolgok az SSD-n lehetnek, a nem vagy ritkán változó adatok, ill. egyéb dolgok (filmek, zenék, képek, miegymás) nyugodtan mehetnek a HDD-re.

SWAP a hibernálás funkció miatt elengedhetetlen, de ha SSD-re teszed és nincs szükséged így kiegészíteni a memóriát, a swapiness értéket leveheted 0-ra (így nem "öregbíti" feleslegesen, de hibernálni tudsz), ill. ha van mellette HDD, ez mehet arra.

Eddig nem írtam, de most már látom, hogy fontos lehet, hogy mik a szándékaim, céljaim. ( ez sok mindent meghatározhat )
0 - Gazda gépnek egy w7x64- re gondoltam, itt programfejlesztés, videoszerkesztés, konvertálás, váltakozna, egyéb dokumentációs irodai munkával. A fejlesztés sok írási művelettel jár, futási tesztek logjairól nem is beszélve.

1 - A VM1 - w7 x64 4GB RAM - fejlesztés, tesztelés
2 - A VM1 - xp x86 3GB RAM - fejlesztés, tesztelés
3 - A VM1 - Ubuntu64 ? RAM - tesztelés, tanulás
4 - A VM1 - Ubuntu32 ? RAM - tanulás, tesztelés

Azonos időben 2db VM feltétlenül, de ha a kapacitás engedi 3- 4 is célszerű lenne. Ezek alapján milyen prevenció és milyen kisegítő config ajánlható?

Ezeket a feladatokat lehet e, szabad e SSD- n csinálni, illetve, ha abszolute nem tudok megfelelő prevencióval élni akkor mire számíthatok?
--
üdv: virtualm

Öcsém kiszámolta, hogy mivel videóvágás eszi az SSD-t !!!!!! (ehe) ezért óvatosnak kell lenni, mert a folyamatosan vág, akkor csak 10 (20?) évig fog menni az SSD-je. A pontos számokra nem emlékszem, meg nyilván számháború az egész, de nekem az jött le - és érdemes lenne utánaszámolni -, hogy ez nem egy reális probléma. Sokkal hamarabb lesz gond az SSD apró mérete.

( maszili | 2013. 03. 28., cs – 23:02 )

Én nagyon sokat használok virtuális környezeteket. Sokszor van úgy, hogy egy időben több is fut. Pl: http://hup.hu/node/111664#comment-1429426
Teljesen használható sebességgel fut a gazda rendszer és a virtualizált rendszerek is egy notebook-on.

Paraméterek:
-HP EliteBook 2540p (J2189887)
-Intel(R) Core(TM) i5 CPU M540 @2.53GHz
-8GByte DDR3
-120GByte SSD KINGSTON SH100S3
-Ubuntu 12.04.1 LTS
-VMware® Workstation 9.0.0 build-812388

--
maszili

( virtualm v | 2013. 03. 28., cs – 23:07 )

Úgy veszem ki a szavaitokból, a RAM sarkalatos kérdés.
Van olyan gép amiben 2 db fizikai HDD van ?
Vagy a host az SSD- ről fusson és a VM- ek a HDD- ről?
--
üdv: virtualm

Ld. fentebb; kiegészítettem a korábbi hozzászólásomat. Minden azon múlik, mit csinálnak a VM-jeid. Java alkalmazásszerver + adatbázis? Vagy inkább számolgatás? Stb.

Szerintem az 1HDD + 1SSD felállásnak megvalósíthatónak kellene lennie. Mindkettőből csinálj LVM PV-t és tedd őket külön VG-be, hogy rugalmas maradj. Kezdetben valószínűleg a host 

/

, 

/home

stb. alá raknám az SSD-t (interaktív munka), és a VM disk image-eket tartanám a HDD-n; ahogy mondod.

( GergA84 v | 2013. 03. 28., cs – 23:17 )

Kérdés hogy mit takar a program fejlesztés/tesztelés.
C kódot fogsz fordítani vagy valami gui-t.

Szerintem amit meghtároztál az elején az elég lesz.
A nem nagy erőforrás igényes vm-eket kiteheted külső merevlemezre.

Általában ez a legkisebb kérdés. Részben azért, mert a CPU folyamatosan szét van osztva, szemben a memóriával, amit ha odaadsz egy VM-nek, akkor az oda van adva örökre - vagy nem, pl. OpenVZ esetén elég jól túl lehet allokálni, de persze ez se csoda, ezzel nem lesz több memória. Illetve ha kifut a CPU-ból akkor nem lesz százszor (ezerszer?) lassabb mint a RAM vs. swap esetén.

qemu+KVM alatt minden VCPU-nak (= a VM minden egyes logikai processzorának) egy-egy thread felel meg a host oldali qemu processzben. Egy ilyen thread a guest kód futtatásához a KVM kernel modulba hív bele egy megfelelő 

ioctl()

-lel. Ezen felül van még egy IO thread (más néven event loop thread), amely (lényegében) a különféle device-okat emulálja, meg néhány feladat-specifikus worker thread (amelyeknek a száma független a guest VCPU count-tól).

Vagyis host oldalról ez úgy néz ki, hogy van egy többszálú processz, amely egyszerűen viszonylag sok CPU-időt tölt kernel kód (ioctl()) futtatásával. A host oldali ütemező szemében nem különbözik más többszálú processztől.

Ha host oldalon van pl. 8 logikai CPU-d (négy mag, HT on), akkor egy adott qemu+KVM guest-nek nem igazán értelmes dolog 8-nál több VCPU-t adni. Kevesebbet értelmes lehet (ha korlátozni akarod, hány logikai host CPU-t húzhat ki). Természetesen ha a guest tokkal-vonóval alszik, akkor a host-oldali CPU "megtakarítás" rendelkezésre áll minden más host-oldali igény lefedésére (ami lehet host oldali tömörítés, egy másik guest (= qemu processz), vagy bármi más).

http://blog.vmsplice.net/2011/03/qemu-internals-overall-architecture-an…

http://www.linux-kvm.org/wiki/images/2/24/2012-forum-Jan-Kiszka-BQL.pdf

A PDF 3. diája jól mutatja. A kék dobozok a VCPU thread-ek, amelyek célja a guest kód gyors, párhuzamosított futtatása. A sárga dobozok a "funkcionális" thread-ek; ezek közül a középső az IO thread (más néven event loop thread), attól jobbra-balra pedig a helper thread-ek találhatók (amelyek "pusztán" programozástechnikai okokból és nem a skálázhatóság érdekében vannak kiszervezve; túl hosszú időre tudnák feltartani az event loop thread-et).

( uid_6201 v | 2013. 03. 29., p – 00:36 )

VT-x -et mindenképp tudja a proci. Ezt bármelyik Core i3, i5, i7 tudja. A magokon időosztásban osztoznak, így egy 2 magoson is elfut 4 virtuálgép. Persze az erősebb proci jobban terhelhető, ellenben drágább. Néhány év távlatában pedig a low-end is gyorsabb lesz a mostani drágánál.

Memória legyen legalább annyi, ami az összes virtualizált gép és a gazdagép memóriaigénye.

Háttértár sebessége: betöltődéskor kritikus, egyébként ha jó az oprendszerben a disk cache, akkor a szoftver újra betöltésekor már nem nyúl a háttértárolóhoz, leginkább csak az eredmények kiírása miatt.

Nem kell annyira félni a témától, mára már jól működő technológia. A VT-x hajnalán ez még nem volt elmondható.

És mégegy gondolat: amelyik virtuális gépet nem nyúzod, az a megmaradó CPU teljesítményt "visszaadja" a közösbe.
Így ha fut például 3 alig terhelt virtuális gép, akkor a 4. részére megmarad a teljes CPU erőforrás nagy része.

Örülök, ha segítettem vele. Sokan félnek ettől a technológiától. Pedig nem ördögtől való.

Háttértár sebessége: betöltődéskor kritikus, egyébként ha jó az oprendszerben a disk cache, akkor a szoftver újra betöltésekor már nem nyúl a háttértárolóhoz, leginkább csak az eredmények kiírása miatt.

Ha qemu-t (+ KVM-et) fog használni, akkor a cache-elést többféleképpen is beállíthatja; lásd 

-drive ...,cache=...,...

: http://qemu.weilnetz.de/qemu-doc.html

( petya | 2013. 03. 29., p – 08:48 )

Kb ugyanez a felhasznalas nalam is, esetenkent 7+ virtualis geppel. A gep T420s, i5-2540M, 16G memoria, 512G SSD, 1600x900 kijelzo. A kijelzo felbonatasa fontos, ha mobil modon is akarod hasznalni, nem a merete (ezt kozelebbrol nezed). Tobbszor volt mar, hogy jol jott volna 32 GB memoria, a mostani gepek kozul a W530 meg az ehhez hasonlo dell precision tudja ezt, de 2 kg-os sulyhatar alatt akartam maradni, meg intel VGA-t szerettem volna, mert az optimusos megoldasok szerintem meg nem tul jok linux alatt.

( secretx v | 2013. 03. 29., p – 22:13 )

Szia,
Én egy demot csináltam nemrég a céges gépen, volt rajta egy win2k3 ad-val, egy xp, és egy debian, ezt egy i5 + 4Gb ram röhögve elvitte.

üdv, Andris

---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

( virtualm v | 2013. 04. 05., p – 03:38 )

Ezt szűrtem le az olvasottakból:
Intel Core i7 : 2.33 - 3.50 GHz
8- 16 GB memória
Kijelző mérete: 16"
SSD 120 GB - SLC fontos
HDD 500 GB

-
Egy ilyen HP servert adnék érte, cserébe : http://hup.hu/node/123163

--
üdv: virtualm

( dikki | 2013. 04. 05., p – 08:41 )

Az SSD-s ThinkPad T[45]X0 + UltraBayben HDD megoldast en is javaslom. Ennel jobbat hurcolni biztosan nem fogsz mas gyartonal talalni.

( uid_2716 | 2013. 04. 20., szo – 14:20 )

A megcélzott kaliberű gépet az elkövetkezendő hetekben kapom meg. Mindenkinek köszönöm a segítséget. Ha esetleg érdekel valakit, akkor majd beszámolok.

Engem érdekel.

( deje | 2013. 04. 20., szo – 17:31 )

Ha sokat hurcolászod, ne vetessél Dell Inspiron-t! Amúgy se való konzumer kategória munkára. Kollégáimnak van ilyesmi, és nagyon sok gond van velük: hiába van benne Core i7 meg minden csillivilli cucc, nyeklik-nyaklik a ház, a billentyűzet behajlik, az USB portok rendszeresen lehalnak, stb. A múltkor a kollégám a sarkánál megemelte és kifagyott. Szerintem ha már megrendelték az Insipront, mondd vissza, hidd el, szívni fogsz vele.

Ha már Dell, inkább Latitude széria, sokkal masszívabb.
Én viszont ThinkPad Txxx párti vagyok.