OpenVZ - jak to funguje?

[to_je_jedno]

mozny zdroj informaci je vpsfree.cz a lide kolem nej.

[Reklama]

[piter_sk]

mozny zdroj informaci je vpsfree.cz a lide kolem nej.

pravda.

[piter_sk]

Zil som v tom, ze stolen time je cpu cas "ukradnuty" pre dom0, nie pre inu VM.

Je to mozny, zas tak jsem to nikdy nepotreboval resit - coby jenom uzivatele toho virtualu me jenom zajimalo, jak zjistit svoji zatez, nad zbytkem jsem nedumal

Podle tohodle
http://www.axibase.com/cloud/2010/07/22/ec2-monitoring-the-case-of-stolen-cpu/ kdyz je virtual omezenej na 40% cpu, tak zbytek je oznacenej jako stolen - prijde mi divny, ze by hypervisor ten cas nepridelil jinymu virtualu, proc by to tak bylo?

Kazdopadne jak psal Jenda, u OpenVZ neni zadny "virtual" a procesy by mely byt schedulovany uplne normalne jako procesy AFAIK.

Ak ten stroj limitujes schvalne na 40%, je logicke ze zvysok cpu casu pouzijes inde. Popravde som nevedel ze to xen dokaze.  amazon ma "xen na mieru", nepouzivaju open source xen pokial viem.

Jenda nepisal o openVZ, ale o full virtuali:

V pripade hypervisorov (ja pracujem s xenom) idle cpu virtualnej masiny moze vyuzivat iba dom0, nie ina masina.

Tohle je podle mě nesmysl. Nemám problém na stroji se 4 jádry spustit 8 KVM virtuálů po 2 jádrech. Ten virtuál vypadá jako proces a ty se schedulují normálně mezi procesory. A když CPU výkon dojde, tak se prostě přepínají a každý chvíli běží a chvíli je scheduled.

To, ze sa full alebo paravirtualne servery navzajom neovlyvnuju co sa tyka CPU je podla mna pravda. Vidim to v produkcii a pripada mi to logicke. Ak treba, mozem to testnut v praci.
To, ze sa ovlyvnuju kontajnery (povodna otazka) mi tiez pride logicke. Tu ale zalezi na konfiguracii limitov. Mohli by to potvrdit ludia z vpsfree, ako napisal to_je_jedno, alebo by sa to dalo vyskusat. Staci vytvorit a spustit 10 rovnakych  kontajnerov, na vsetkych spustit napr. "cat /dev/zero > /dev/null &" a monitorizovat load. Potom na jednom spustit to iste 10x. Tiez mozem testnut ak nikto iny nemoze.
Zdravim.

[Mirek Prýmek]

To, ze sa full alebo paravirtualne servery navzajom neovlyvnuju co sa tyka CPU je podla mna pravda. Vidim to v produkcii a pripada mi to logicke. Ak treba, mozem to testnut v praci.
To, ze sa ovlyvnuju kontajnery (povodna otazka) mi tiez pride logicke. Tu ale zalezi na konfiguracii limitov. Mohli by to potvrdit ludia z vpsfree, ako napisal to_je_jedno, alebo by sa to dalo vyskusat. Staci vytvorit a spustit 10 rovnakych  kontajnerov, na vsetkych spustit napr. "cat /dev/zero > /dev/null &" a monitorizovat load. Potom na jednom spustit to iste 10x. Tiez mozem testnut ak nikto iny nemoze.
Zdravim.

Nejak jsme se do toho zamotali, uz ztracim prehled, co nam vlastne neni jasne. Kdyz spustis tri virtualy na dvoujadre, tak se o to dvoujadro budou delit - tj. na jeden virtual vyjde o neco min nez 2/3 jadra, to je prece jasny, ne? Neovlivnovat by se mohly jenom v pripade, ze bys jedno konkretni jadro vylozene vyhradil exkluzivne pro jeden konkretni VM.

[Tomáš Crhonek]

- Jsou jakoby přímo namountované, jsou „vidět“. U plné virtualizace se ten disk musí nejdřív namountovat. Nemyslím si ale, že by ten jeden příkaz mount dělal nějaký rozdíl v bezpečnosti.

Příkaz mount v bezpečnosti rozdíl neudělá, ale pokud má virtuálka vlastní blokové zařízení (a na něm až oddíly a fs), tak si to blokové zařízení může šifrovat. Dělá se to. Při každém bootu potom admin zadá heslo ("lokálně" přes konzoli, nebo nějak vzdáleně přes boot time ssh).

[Reklama]

[Jenda]

Příkaz mount v bezpečnosti rozdíl neudělá, ale pokud má virtuálka vlastní blokové zařízení (a na něm až oddíly a fs), tak si to blokové zařízení může šifrovat. Dělá se to. Při každém bootu potom admin zadá heslo ("lokálně" přes konzoli, nebo nějak vzdáleně přes boot time ssh).

To jsem adresoval v té části, jestli klíč a rozšifrovaná data uloží do paměti, kterou host může taky dumpovat.

Konzoli není problém logovat a z boot-time sshd (nejspíš na nešifrované /boot partition) si zkopírovat privátní klíč. Možná tohle myslel předřečník tou vyšší bezpečností; je pravda, že už to není chvilkové „nakouknutí“, ale rozhodně nic nepřekonatelného.

[Tomáš Crhonek]

To jsem adresoval v té části, jestli klíč a rozšifrovaná data uloží do paměti, kterou host může taky dumpovat.

Konzoli není problém logovat a z boot-time sshd (nejspíš na nešifrované /boot partition) si zkopírovat privátní klíč. Možná tohle myslel předřečník tou vyšší bezpečností; je pravda, že už to není chvilkové „nakouknutí“, ale rozhodně nic nepřekonatelného.

Ano, toho jsem si všiml po té, co jsem reagoval na uvedený komentář. Je pravda, že rozšifrovaný klíč bude uložen v paměti (jak snadné je jej lokalizovat netuším, rád se nechám poučit). Na druhou stranu pokud už někdo řeší toto, tak pravděpodobně nebude chtít provozovat takto citlivý server jako vmko na veřejném hostingu.

[to_je_jedno]

a v tu chvili uz mu zase staci kontejnery

[piter_sk]

To, ze sa full alebo paravirtualne servery navzajom neovlyvnuju co sa tyka CPU je podla mna pravda. Vidim to v produkcii a pripada mi to logicke. Ak treba, mozem to testnut v praci.
To, ze sa ovlyvnuju kontajnery (povodna otazka) mi tiez pride logicke. Tu ale zalezi na konfiguracii limitov. Mohli by to potvrdit ludia z vpsfree, ako napisal to_je_jedno, alebo by sa to dalo vyskusat. Staci vytvorit a spustit 10 rovnakych  kontajnerov, na vsetkych spustit napr. "cat /dev/zero > /dev/null &" a monitorizovat load. Potom na jednom spustit to iste 10x. Tiez mozem testnut ak nikto iny nemoze.
Zdravim.

Nejak jsme se do toho zamotali, uz ztracim prehled, co nam vlastne neni jasne. Kdyz spustis tri virtualy na dvoujadre, tak se o to dvoujadro budou delit - tj. na jeden virtual vyjde o neco min nez 2/3 jadra, to je prece jasny, ne? Neovlivnovat by se mohly jenom v pripade, ze bys jedno konkretni jadro vylozene vyhradil exkluzivne pro jeden konkretni VM.

ja si myslim ze nie. ak spustis 3 virtuali na dvojjadre, ubytok vykonu bude rovnaky pre vsetky a vykon jedneho virtualu nebude zavisiet na zatazi ostatnych dvoch. Prikontajneroch toto neplati.

[Mirek Prýmek]

ja si myslim ze nie. ak spustis 3 virtuali na dvojjadre, ubytok vykonu bude rovnaky pre vsetky a vykon jedneho virtualu nebude zavisiet na zatazi ostatnych dvoch. Prikontajneroch toto neplati.

Pokud spustim na dvojjadre tri VirtualBoxy, tak jsou to tri procesy. Kdyz virtual nic nedela, proces nevytezuje procesor, kdyz dela, vytezuje. Čili plánování je imho úplně stejný jako u procesů a oproti kontejnerům je jedinej rozdíl: když si v kontejneru spustím deset procesů, budou mít desetinásobnou převahu proti kontejneru s jedním procesem (za předpokladu, že tam nemám nějaký omezení na hw).

[piter_sk]

ja si myslim ze nie. ak spustis 3 virtuali na dvojjadre, ubytok vykonu bude rovnaky pre vsetky a vykon jedneho virtualu nebude zavisiet na zatazi ostatnych dvoch. Prikontajneroch toto neplati.

Pokud spustim na dvojjadre tri VirtualBoxy, tak jsou to tri procesy. Kdyz virtual nic nedela, proces nevytezuje procesor, kdyz dela, vytezuje. Čili plánování je imho úplně stejný jako u procesů a oproti kontejnerům je jedinej rozdíl: když si v kontejneru spustím deset procesů, budou mít desetinásobnou převahu proti kontejneru s jedním procesem (za předpokladu, že tam nemám nějaký omezení na hw).

suhlas. takto som to myslel celu dobu.

[Jenda]

Ano, toho jsem si všiml po té, co jsem reagoval na uvedený komentář. Je pravda, že rozšifrovaný klíč bude uložen v paměti (jak snadné je jej lokalizovat netuším, rád se nechám poučit). Na druhou stranu pokud už někdo řeší toto, tak pravděpodobně nebude chtít provozovat takto citlivý server jako vmko na veřejném hostingu.

Na AES existuje velice rychlá utilita aeskeyfind (vyzkoušeno, funguje i pro dm-crypt s AES-XTS, klíč v GB dumpu najde i na horším počítači pod minutu), pak ještě existuje rsakeyfind (nezkoušeno). Na ostatní šifrovací algoritmy nevím o tom, že by něco existovalo, takže se klíč musí najít buď vyzkoušením všech možností, nebo nějak chytře debuggerem (pokud máš distribuční jádro, mohlo by pomoct opatřit si debug symboly a ten klíč si prostě přečíst).