Neverim, ze ti jakykoli provozovatel VPS pripoji do hypervizoru primo blokovy device, pokud se hodne dobre nedomluvite, a hlavne to je past, protoze vsechno se chce mit jistene proti HW vypadku (cti v RAIDU). Jinak se prave vytvareji virtualni disky na raidovych polich. iSCSI je mozna reseni.. Ale o tomhle se uz do debaty poustet neodvazuju, protoze o tom vim kulove a hlavne se mi to nelibi, ac to tak na par mistech mam.
Nenapsal jsem to nejstastneji. Mam samozdrejme nad par diskama softwarovy raid, nad tim LVM a jednotlive lv mam pridelene ke KVM VM.
Chapu ze obrovska vyhoda u vpsFree je ze jejich storage je vzdy podporeny na nejakym SSD. Jen si ted nevybavuji jakym systemem to maji resene, jestli pomoci ZFS, nebo na nizsi vrstve.
Primarne me jde o to, pokud bych pouzil KVM virtualizaci, tak neprichazel o vykon tim ze budu pouzivat 2 filesystemy nad sebou. ZFS pro moji VPS, kde vytvorim disk image v souboru, ktery je prirazeny do nove KVM VM a ve ktere znova tento prostor naformatuji nejakym FS, napr ext4.
(Priznam se ze praci s datasety neovladam)
Předtím jsem si qemu-kvm ve VPS nespustil? Nebo to jen nebylo popsané/podporované? Nebo to prostě nefungovalo? V čem spočívá ta změna?
Takhle mi přijde ta zprávička lehce matoucí, protože jsem si myslel, že si při objednání VPS můžu vybrat zda chci OpenVZ neb plnou KVM virtualizaci. Ve skutečnosti mám vždy OpenVZ.
Prosím o upřesnění.
Dříve nebylo v kontejneru k dispozici rozhraní KVM. Tedy byl k dispozici jen kontejner, nebylo možné si tam spustit vlastní jádro. Žádný výběr k dispozici nikdy nebyl a ani teď není. Člen dostane automaticky přidělené nějaké zdroje a nad nimi si spouští vlastní kontejnery. Nově je možnost si uvnitř pak dále dělit prostor pomocí KVM a dělat si libovolně třeba síť.
Ano, s mizerným výkonem, to je jasné.
Díky za upřesnění. Myslím, že ta zprávička nebyla úplně štastně formulovaná, ostatně nejsem jediný, kdo to blbě pochopil. Prostě jde o to, že v OpenVZ kontejneru si nově spustím qemu včetně kvm akcelerace. Čili se změnila konfigurace hostitelského jádra, nic jiného. Zprávička budí dojem nové služby a člověk pak tápe, o co vlastně jde.
Samotná změna je skvělá, umožňuje to dělat a testovat řadu věcí, mám tam nějaké VPS a už jsem nad tím dřív přemýšlel (aniž bych vědět, že to pořádně nejde).
No, asi jsme to meli napsat jasneji, problem je v tom, ze mi v poslednich dnech neni moc dobre a nebyl jsem u toho, kdyz se tohle psalo.
Jde o zpristupneni KVM funkcionality na urovni, jakou umi rozumne nove RHEL6 jadro do OpenVZ kontejneru, cili potom jde v CT (kontejneru) pustit libvirt, pripojim se na nej od sebe z virt-manageru a mam neco jako svuj KVM hypervisor. S tim, ze vetsina funkcionality, kterou potrebuje qemu-kvm, aby jelo, tam je. Sitovani taky funkcni, jenom ma nektera omezeni co se iptables a ebtables tyce, nicmene portforwardovat na verejnou IP v pohode jde.
Cilem je umoznit si spustit aplikace, ktere na linuxu nebo v prostredi OpenVZ kontejneru nejdou spustit.
Zaroven se to da pouzit na vyrobu vlastniho KVM clusteru v nasem prostredi, GlusterFS v defaultu pod OpenVZ nebezi, ale v mailing listu jsme resili a vyresili, jak Gluster rozchodit, takze napriklad tak by se dalo.
Moznosti vyuziti je spousta, jelikoz jde o prvni level hw virtualizace, OpenVZ jsou jenom OS-level kontejnery - a na drtivou vetsinu aplikaci, co u nas clenove chteji spoustet, se hodi spise ty, proto je nase prostredi unifikovane nad OpenVZ - a tahle KVM feature je tak nejak odpoved na vsechny chybejici dilky, co se runtime tyce. Jeste potom "zbyva" poladit HA (uz mam rozplanovane s Infinibandem, chystam se to testovat v base48 v Brne, tak se muzete po novem roce prijit podivat a pokecat, kdo budete chtit) a budu spokojeny, co se infrastruktury tyce :)
Tedy, rad bych NVIDIA karty do kontejneru pro to KVM, jenze NVIDIA ma nejakou dohodu s Citrixem a hw virtualizace s GPU jde pouzit jenom pod Xenem, na ktery OpenVZ kontejnery nemaji dosah by design, narozdil od KVM.
Novejsi datacentrove cipy od NV umi hw virtualizaci, tzn. rozdelit se na nekolik logickych grafickych karet, s tim, ze nektera funkcionalita je sdilena a vsechno resi hw scheduler primo na cipu. Tohle by melo jit nejak pouzit, z doslechu od cloveka, co se tim zabyval vim, ze NV driver posle jakehokoliv consumera toho interface nekam, pokud to neni Xen. No nejak se to pry dalo otento, takze by to pod KVM jet mohlo, ale aktualne takovou kartu nemam k dispozici a mam pred tim jeste dlouhy TODO list :)
Teoreticky by mohlo jit tu kartu pak zpristupnit v kontejneru, otazka je ta NVidia userspace cast - neznam to zatim vubec.
Dovolim si k tomu par poznamek - zatim nejdal je ve virtualizaci GPU Intel a to hned v nekolika rezimech pouzivani (bohuzel jejich GPU zase neoplyvaji prilis vykonem).
To o cem pises od Nvidie je obdoba Inteli technologie GVT-s, neboli API Forwarging, ale to se zatim zda bejt slepou vetvi vyvoje a spis se zacina tlacit na GVT-g viz: https://software.intel.com/en-us/blogs/2014/05/02/intel-graphics-virtualization-update
Jinak samozrejme je tu porad GVT-d (Direct Pass-through), coz je ale v pripade VpsFree nepouzitelny...
Co se tyka vGPU technologie od Nvidie, tak ta opravdu funguje jen na XENu a to ne prilis stabilne co jsem mel moznost pozorovat.