Редактирование: Спецкурс по Linux, весна 2007, 07 лекция (от 06 апреля)

Раньше вирт. была уделом матёрых профессионалов, а тут внезапно эта теория приобрела горячую востребованность.

* Самая старая, существовала ещё 10---20 лет назад. Задача собственной изоляции, ограничения доступа. Когда-то давным-давно это была проблема. Был компьютер, был процессор, была память, были программы и была задача этим программам работать.

** Когда их нужно несколько штук, и производительность их при этом не критична, например, для тестирования сетевых приложений

* Есть потребность разделить три пункта (ограничение доступа, распределение, унификация) по уровням. То есть сделать так, чтобы, например, унификация происходила до всего остального. То есть из кривого железа делаем виртуальное нормальное железо. Или мы занимаемся распределением времени процессора, нам всё равно, какая ОС, какие процессоры, но есть конкретная задача, которую надо решить. Ещё мы например хотим сделать так, чтобы приложения не могли обмениваться информацией, даже по сговору.

То есть задача следующего уровня не знает ничего о решении задачи предыдущего. Но ОС это монолитная система, а нам нужно независимость.

Фактически, мы говорим следующее: ограничение/унификация/распределение доступа внутри ОС это здорово, но мы хотим сделать так, чтобы решение некоторых задач не зависело от среды, которую мы отдаём программисту. Кроме того, поскольку эти уровни независимы, у них разные администраторы. В частности, это решает проблему рута. Рут может делать ваще всё, а нам нужно, чтобы он мог делать всё только со своими ресурсами.

В. Если несколько виртуальных машин гоняют нативный код?

Вот. На самом деле никакого жёсткого ограничения нет, то есть, ситуации, когда мы можем чётко разграничить. Именно поэтому приведён пример с нинтендо.

* Дальше идёт вот что: чрут это изоляция только по ФС, например если два процесса запущены, то они могут послать друг другу сигнал, и они пошлют, или через shared memory несмотря на то, что работают в разных кусках ФС. Тогда нужно разграничить их и по всем системным вызовам друг от друга. Для этого есть V Server (Jail). То есть каждый заперт в свою тюрьму. В солярисе аналогичные вещи называаются зонами, правда, они чуть более крутые.

Потихоньку можнео начать задачу распределения ресурсов. Например, чтобы 10 процессов, запущенные на одном вирт сервере, не сожрали все ресурсы, и чтобы что-нибудь осталось другим 10 процессам. Помимо огранич доступа на след этапе иерархизируется распределение ресурсов.

* Где-то между ними лежат решения на основе гипервизора. Можно написать очень маленькую ОС, которая решала бы три задачи, причём не ко всем, а только к самым главным — процессор и оперативная память. Поэтому это и называется гипервизор — визор, который управляется супервизорами. А под гипервизорами запускаятся почти любая ОС. Примеры: L4 (тут была другая задача — сделать микроядерную ОС, то етсь идею, что все Настоящие ОС должны выполнять ровно эту функцию по отношению к одному ресуру, всю остальную логику нужно выносить в юзерспейс. То есть при запуске регистрируется специальный процесс, который реализует логику раздачи страниц, а потом уже ядро делает по необходимости запрос к нему). Самый старый — HURD. Есть L4 linux, который сделан чтобы показать, что оно работает, и оно работает. Ещё один проект — Lquest. XEN. У XEN есть домены, есть нулевой домен, у которого ресурсы настоящие, и есть другие домены с синт ресурсами. Оверхед у Зена очень низкий. Ибо он реализован в виде гипервизора. У OVZ фактически все программы пользуются одним ядром. У зена ядер может быть много. И XEN, и OVZ очень внимательно относятся к появившиейся аппаратной виртуализации.

* Осталось сделать вирт машину как она есть, то есть программу, которая всем рассказывает, что она — компьютер. У неё есть своё оборудование: ком-порт, видеокарта. И когда нужно загрузиться, то можно сказать, что этот файл не файл а образ, и можно с него загрузиться, и ось, которая с него грузится, видит виртуальное оборудование. Которого не существует, но которое может взаимодействовать с реальным миром. В первую очередь это VMWare, QEmu. Но VMWare подгружает ядрёные модули и валит иногда этим систему. Ещё есьт kvm, который позволяет задействовать апп виртуализацию. Ещё kqemu — модуль для Qemu, который позволяет исполнять нативный код и использовать апп виртуализацию.

Зачем нам иерархия? Есть частная задача, для которой она нужна — хостинг. Долго ГК считал, что это есть главная движущая сила. Задача хостинга: есть мнение, что существует закон Мура, есть мнение, что это коммерческий трюк. Так или иначе, он пока наблюдается, и это означает, что рост производительности и индекс производительности экспоненциальный. А программные продукты растут линейно. Так что то, объём передаваемых данных человеку расти не может.

Один отдельно взятый процессор нельзя полностью нагрузить своими задачами. За исключением игр. Так что если мы не отмороженые геймеры, то нам не нужно покупать новый компьютер.

Это довольно частое решение. И когда в след раз возникнет такая задача, то поставятся те же пакеты, и так же настроить. Это не проблема. Проблема возникает, когда таких установок по 10 штук, или делать их какому-то оператору. Процесс воссоздания требует наблюдения специалиста. Надо автоматизировать. Но если машина не чистая, то может вохникнуть много проблем.

Третье замечание: в идеале получаем решение которое не зависит от аппаратного окружения, особенно в случае с XEN'ом. То есть, туда не будет входит специальных модулей ядра и всего такого.

Есть прогноз, что в будущем все ОС будут поддерживать средства виртуализации.