Ссылки - Auriga, Inc.

Опубликовано в журнале «Мир Компьютерной Автоматизации: мир Встраиваемых Компьютерных Технологий», № 1 2009
Сергей Зимин, Auriga Inc.
Virtual Machine: проблема выбора
Тема виртуализации является актуальной на протяжении, наверное, всего последнего
десятилетия, а в последнее время она стала особенно популярной и охватывает уже не только
сервера и ПК, но и мобильные устройства. На рынке существуют множество различных решений,
покрывающих практически все аспекты виртуализации и возникает лишь проблема выбора
наилучшего из возможных. В тоже время всегда находятся задачи, с несколько нестандартной
постановкой проблемы, не покрытые в полной мере ни одним из существующих решений. В такой
ситуации встает вопрос о выборе наиболее близкого решения с последующей его доработкой.
Разумеется, специфика постановки задачи является ключевой при выборе подходящего базового
решения. Это может быть метод виртуализации, список поддерживаемых Host и Guest OS и
Hardware (включая CPU), различные тонкости с лицензиями и т.п. В ряде простых случаев для
решения поставленной задачи достаточно лишь правильной настройки или небольших изменений
в подходящем open source проекте. В более сложных случаях может потребоваться значительная
переделка или даже реализация системы «с нуля».
В данной статье рассмотрен некий абстрактный проект, целью которого является разработка
виртуальной машины с нечетко сформулированными требованиями. Рассматриваются
возможные вариации этих требований и приводятся рекомендации в отношении путей его
реализации на базе имеющихся оpen source проектов.
Термины
Согласно [7], виртуализация (вообще) скрывает реальные характеристики
вычислительной платформы, заменяя их другой абстрактной или
эмулируемой платформой. A виртуальная машина (Virtual Machine, VM) –
это программная реализация машины, которая исполняет программы
также как и настоящая машина. Т.е. для абстрактной эмулируемой
платформой является сама настоящая машина, на которой и запущена
реализация VM.
Мы будем использовать термин виртуальная машина несколько шире,
допуская эмулируемой платформе отличаться от настоящей машины и
понимая под ней некую платформу, существующую в реальном мире.
Существует несколько разновидностей виртуальных машин. В данной
статье рассматриваются машины, эмулирующие работу реальной
компьютера (платформы) целиком; так называемая системная
виртуальная машина (System Virtual Machine). При этом платформа, на
которой запускается виртуальная машина, называется хозяйской, хост или
Host, а эмулируемая платформа гостевой или Guest.
На виртуальную машину, также как и на реальный компьютер, можно устанавливать операционную
систему (Guest OS), у виртуальной машины обычно есть оперативная память, жёсткий диск, могут
эмулироваться периферийные устройства (Guest Hardware). На одной хозяйской платформе может
быть запущено несколько виртуальных машин.

Целостное состояние виртуальной машины называется слепок или VM Snapshot. Он включает
состояние всех устройств виртуальной машины, а также OS и приложений, запущенных на
виртуальной машине.
Существует двойственность в использовании термина виртуальная машина. Это и программное
обеспечение и эмулируемая им платформа. Чтоб избежать этой двойственности, в статье
используются термин виртуализатор для определения программного обеспечения, эмулирующего
гостевую виртуальную машину, и виртуальная машина в смысле виртуальная гостевая платформа.
Постановка Задачи
Рассмотрим некий проект, задачей которого является разработка (возможно даже просто
минимальная модификация или настройка существующего) виртуализатора. Формальные требования
к этому проекту изложены ниже. Как и в реальном проекте, некоторые из требований жесткие и не
подлежат изменению, другие можно обсудить и возможно смягчить. Какие‐то требования совсем не
указаны.
Итак, виртуализатор должен удовлетворять следующим требованиям:
1. Поддерживать несколько виртуальных машин.
1. При этом виртуальные машины должны быть полностью изолированы друг от друга и
контролируемо изолированы от реальной платформы.
2. Предоставлять доступ виртуальных машин к реальному оборудованию через эмуляцию
реального оборудования.
1. Виртуальное оборудование Guest Hardware должно быть единообразным и не
зависеть он реального оборудования.
3. Интерфейс виртуального оборудования Guest Hardware не должен быть тесно связан с
реальным оборудованием Host Hardware и быть одинаковым на любом Host Hardware,
поддерживаемом Host OS.
1. В некоторых случаях (прежде всего из соображений производительности)
отступления от этого правила возможны. В частности, Guest Hardware может в
реализации использовать акселерацию реального оборудования, однако это никак
интерфейс Guest OS к Guest Hardware.
4. Виртуальная машина должна поддерживать сохранение в и восстановление из слепка, т.е.
должна иметь возможность стартовать VM не из начального состояния с последующей
загрузкой и запуском Guest OS, а с некоторой стабильной точки сохраненной в виде VM
Snapshot‐а, когда необходимые Guest OS и Applications уже загружены.
1. VM Snapshot не должен быть специфичным для данной конкретной инсталляции
виртуальной машины или Host Hardware. Любая виртуальная машина (с той же
конфигурацией Guest Hardware) на любом Host Hardware должна быть в состоянии
загрузиться из слепка VM Snapshot, который мог быть скопирован, передан по сети
или подвергнуться архивации.
5. Метод виртуализации, используемый виртуализатором, не задан
1. В то же время, метод виртуализации является основным критерием
производительности, требование к которой должно соблюдаться.
6. Прочие требования:
1. Host Hardware
1. CPU
1. x86 compatible (Intel или AMD)
2. Поддержка Symmetric Multi Processing (SMP)
2. Прочее оборудование
1. Любое, поддерживаемое Host OS для эмулирования Guest Hardware

2. Host OS
1. Linux
2. Другие
3. Guest Hardware
1. CPU
1. То же, что и для Host Hardware
2. Поддержка Symmetric Multi Processing (SMP)
2. Прочее оборудование
1. Минимум, необходимый для работы популярных OS
4. Guest OS
1. Любая OS или firmware, запускаемая на Guest Hardware
5. Производительность
1. Скорость исполнения OS и приложений на виртуальной машине должна
быть близка к скорости их исполнения на реальной платформе. Т.е. потери
вследствие виртуализации должны быть минимальными (близкими к нулю).
6. Лицензии
1. За основу может быть взят любой open source виртуализатор, выпущенный
под любой свободной лицензией
На первый взгляд может показаться, что требования достаточно стандартны и найдется множество
виртуализаторов, способных покрыть их или уж точно подходящих за основу для будущего решения,
а вариации же требований незначительны и могут быть легко устранены небольшими
модификациями. На самом деле это не так и ниже будет показано, что «тонкости» являются
ключевыми для выбора подходящей основы.
Вариации требований
В требованиях, приведенных выше, курсив использовался для требований, которые могут быть
смягчены и жирный шрифт и () вопросительный знак для требований не полностью определенных, в
некоторых случаях являющихся предположениями. Они то и являются основным местом вариации
требований.
Метод Виртуализации
Выбор метода виртуализации, вероятно, является одним из самых важных решений в разработке
виртуализатор. Безусловно, на его выбор накладывают ограничения Host, а иногда и Guest
платформы.
Существует несколько методов виртуализации, имеющих различные свойства и особенности.
Полная виртуализация обеспечивает полную имитацию гостевой платформы и позволяет любому
программному обеспечению, работающему на реальном аппаратном обеспечении (эквиваленте
гостевой платформы), работать и под управлением виртуальной машины. Ни ОС, ни приложения не
нуждаются в изменениях. Для поддержания полной виртуализации поведение устройств гостевой
платформы эмулируется.
Особое место занимает эмуляция CPU, т.к. это определяет производительность всей виртуальной
машины. Продвинутые виртуализаторы используют метод динамической трансляции. Данный метом
позволяет получить производительность близкую к скорости реальной платформы.
В некоторых случаях (наиболее интересных с практической точки зрения) поддержка виртуализации
обеспечивается аппаратным обеспечением, что упрощает процесс виртуализации и позволяет
достичь производительности, мало отличающейся от скорости работы реальной машины.

Альтернативу полной виртуализации составляет паравиртуализация, которая не имитирует реальное
аппаратное обеспечение полностью, а предоставляет некую среду исполнения, похожую на
эмулируемую машину, но требующую от гостевого кода кооперации для осуществления
определенных действий внутри виртуальной машины. Как следствие, паравиртуализация не
позволяет исполнять гостевой код без изменений. Обычно, эти изменения касаются лишь Guest OS, в
то время как приложения могут быть запущены без изменений.
По сравнению с полной виртуализацией, паравиртуализация обладает лучшей производительностью,
т.к. виртуализатор не эмулирует работу CPU, а за счет кооперации с гостевой ОС, просто позволяет
ему исполнять гостевой код.
При паравиртуализации Guest OS обычно не взаимодействует с аппаратурой напрямую.
Программные запросы на такие операции переправляются в Host OS, которая и осуществляет
взаимодействие с Hardware от лица Guest OS. В некоторых случаях виртуализаторы позволяют Guest
OS взаимодействовать напрямую с Host Hardware.
Следует отметить, что на современных процессорах, обладающих аппаратной поддержкой
виртуализации, разница в производительности при паравиртуализации и полной виртуализации не
значительна. Однако, если аппаратной поддержки нет, то выигрыш весьма ощутим.
Итак, не смотря на то, что паравиртуализационный подход не позволяет удовлетворить некоторые из
формальных требований, он может дать значительный прирост производительности, что может стать
весомым аргументом в пользу пересмотра требований.
Поэтому, первый вопрос, который должен быть уточнен ‐ допустима ли паравиртуализация или
полноценная виртуализация является жестким требованием
Кстати, полная виртуализация может не конкурировать, а дополнять паравиртуализацию. Т.е. в
случае, когда Guest OS не имеет поддержки, требуемой для паравиртуализации, полная
виртуализация может быть использована.
Такой смешанный подход может быть «третьим» решением, беря все лучшее от паравиртуализации,
но не ограничиваясь ей.
Поддерживаемое Host Hardware и Host OS
Требования к поддержке Host платформы являются теми параметрами, которые определяют выбор
решения. Например, может оказаться, что решение, идеально подходящее по функциональности, но
не предназначенное для данного Host CPU будет абсолютно неприемлемо, а его портирование (если
это вообще возможно) по трудоемкости будет сопоставимо с написанием виртуализатора «с нуля».
Применительно к рассматриваемому проекту, необходимо определить ‐ Является ли платформа x86
единственной, на которой должна работать виртуальная машина Требуется ли поддержка 64‐bit
Должна ли осуществляться поддержка Symmetric Multi Processing (SMP)
Как уже отмечалось, некоторые современные процессоры обладают аппаратной поддержкой
виртуализации. Такая поддержка есть в современных x86 процессорах от Intel (технология Intel VT) и
AMD (AMD‐V). Есть подобная поддержка и для архитектуры PowerPC и некоторых других.
В связи с этим важно выяснить, можно ли полагаться на то, что процессоры, которые будут
исполнять код виртуальной машины, будут обладать поддержкой виртуализации на аппаратном
уровне

Список Host OS влияет на выбор виртуализатора не меньше, чем Host Hardware. Виртуализаторы
тесно интегрированы с Host OS. Они могут иметь код, исполняемый на уровне ядра или в
значительной степени полагаться на поведение системы.
В связи с этим вопрос о том, какие Host OS нужно поддержать – является очень важным. Очевидно,
что в отличие от списка Guest OS, этот список должен быть ограниченным.
Наиболее «поддержанной» платформой является Linux, следующая по популярности платформа ‐
Windows. Найти виртуализатор с поддержкой VxWorks или QNX может быть нетривиальной задачей.
Поддерживаемое Guest Hardware и Guest OS
В целом, вопросы относительно поддерживаемой гостевой платформы не столь значительны.
Пожалуй, по настоящему важным являться только один – Может ли процессорная архитектура Guest
ОS отличаться от архитектурой Host OS
В этом случае обычно речь идет о полной виртуализации гостевой платформы и, как правило, без
поддержки со стороны аппаратного обеспечений, т.е., виртуализация, по сути является кроссплатформенной
эмуляцией.
Остальные вопросы, которые следует уточнить:
Какие устройства должны быть поддержаны в рамках Guest Hardware Должна ли быть поддержка
Symmetric Multi Processing (SMP) Может ли количество доступных процессоров быть больше чем
на Host Hardware
Наиболее важными из них являются два последних. В случае, если ответ на них утвердительный, то
решение, которое будет взято за основу должно подходить по этим параметрам, т.к. добавление
эмуляции многопроцессорности затрагивает ядро виртуализатора и может быть ресурсоемким.
Рассматривая влияние списка поддерживаемых Guest OS, следует разделять случаи полной
виртуализации и паравиртуализации. В случае полной виртуализации любая Guest OS будет работать
автоматически, поэтому список Guest OS (который может быть вообще не ограничен) никак не влияет
на выбор виртуализатора.
Говоря о паравиртуализации, список Guest OS является серьезным параметром, определяющим
выбор виртуализатора. Разумно выбирать тот из них, кооперация с которым уже поддержана в
большинстве требуемых Guest OS. В остальных Guest OS она должна быть добавлена в рамках
проекта. Кстати, важно понимать, что для поддержки других OS, почти наверняка потребуются их
исходные тексты всех Guest OS.
Допустимые лицензии
В настоящее время доступно большое количество виртуальных машин с самыми разными
лицензиями, которые могут быть взяты за основу данного проекта ([4]). Некоторые с открытым
кодом, другие коммерческие.
Важно выяснить ‐ можно ли пользоваться кодом, выпущенным под open source лицензиями И
какие из них являются допустимыми (LGPL/GPL v2/v3, BSD и т.п.)
Другой путь – использование за основу коммерческого продукт. Некоторые open source продукты
имеют несколько лицензий, что позволяет договориться об использовании решения в обход жестких
open source лицензий.
Обзор доступных решений

Ниже приводятся обзор доступных open source проектов с комментариями и рекомендациями. Это
сделано в предположении, что и Host платформа – Intel x86/Linux, Guest платформа, не полностью
определена, а open source код, выпущенный под любой лицензией, может быть использован.
Xen
Пожалуй, наиболее подходящим проектом, является Xen ([1]). Он создан специально для требований
подобного проекта, он очень хорошо поддерживается и широко используется (в том числе и
крупными компаниям, такими как Sun Microsystems, RedHat, HP, Fujitsu, Dell, Intel, AMD) и фактически
является основной платформой в индустрии для виртуализации x86 архитектуры.
Методы виртуализации: Паравиртуализация, Полная виртуализация (требует аппаратной поддержки)
Тип: Гипервизор
Host CPU / OS: x86, x86‐64, IA‐64, PowerPC, SMP поддержан / Linux
Guest CPU / OS: Идентичное Host CPU, SMP поддержан /
Лицензия: GPL
Паравиртуализация: NetBSD, Linux, Windows
Полная виртуализация: любая ОС
Одним из ярких использований Xen является Amazon EC2, достаточное количество информации по
которому доступно в сети ([5]).
Изначально Xen был разработан как монитор виртуальных машин или гипервизор ([10]),
поддерживающий исключительно паравиртуализацию. После того как аппаратная поддержка
виртуализации была добавлена в процессоры Intel и AMD, поддержка полной виртуализация была
добавлена в Xen. В настоящее время Xen комбинирует оба метода.
Архитектурно, Xen несколько отличается от обычного виртуализатора. Xen является гипервизором,
который распределяет ресурсы и процессорное время между виртуальными машинами (доменами) и
контролирует их работу. Один из доменов domain 0 является выделенным. Xen взаимодействует с
ним для обеспечения работы остальным доменов
(domU).
На domain 0 запущена модифицированная версия ядра
ОС Linux (Host OS), которая имеет специальные права
доступа к оборудованию и которая может
взаимодействовать с другими доменами. Она является
неотъемлемой частью Xen и нужна для
функционирования системы в целом.
Виртуальные машины, поддерживаемые Xen, бывают двух типов – это гостевые машины с
паравиртуализацией (domU PV) и машины с полной виртуализацией (domU HVM). Операционные
системы, запущенные на domU PV, имеют модификации необходимые для кооперативной работы с
Xen. Системы, работающие в domU HVM, могут быть запущены без модификаций.
Доступ виртуальных машин к ресурсам контролируется гипервизором. Виртуальные машины не
имеют прямого доступа к разделяемым ресурсам (таким как диск или сеть). Доступ осуществляется
только из dom0, по явному запросу domU PV или неявному от dom HVM. В последнем случае dom0
приходится эмулировать поведение Guest Hardware. Виртуальные
машины могут иметь
эксклюзивный прямой доступ к некоторым устройствам.

Xen удовлетворяет практически все требованиям со следующими комментариями:
1. Xen реализует два метода виртуализации (паравиртуализация и полная виртуализация,
требующая аппаратуры). В случае, если требуется эмуляция (например, процессорная
архитектура Guest Hardware – x86 или используется Host процессор без поддержки
виртуализации), Xen не может быть использован.
2. В добавлении требуемой x86 процессорной архитектуре Xen поддерживает архитектуры
x86_64, IA64, PowerPC. Поддержка других платформ очень ресурсоемка и иногда даже не
возможна в требуемом объеме. Рекомендация, не использовать Xen в таком случае.
3. В качестве Host OS, Xen поддерживает Linux, NetBSD и Solaris. Поддержка остальных ОС может
быть добавлена, однако требуемые изменения могут быть значительными.
4. В режиме полной виртуализации, эмулируется фиксированный небольшой набор устройств. В
случае если этого набора не достаточно, эмуляцию устройств необходимо будет добавить.
5. Xen является лучшим решением, существующим в индустрии с точки зрения
производительности при использовании паравиртуализации (потеря производительности
лишь 0.1%‐5%). В случае с полноценной виртуализацией это может быть не так, но даже в
этом случае показатели производительности очень хорошие.
VirtualBox
Другим интересным open source решением является проект VirtualBox, поддерживаемый Sun
Microsystems.
Методы виртуализации: Полная виртуализация
Тип: Виртуальная машина (виртуализатор)
Host CPU / OS: x86, x86‐64, SMP не поддержан / Linux, Mac OS X, OS/2 Warp, Windows и Solaris
Guest CPU / OS: Идентичное Host CPU, SMP не поддержан / любая
Лицензия: GPLv2
VirtualBox предназначен для полной виртуализации x86 архитектуры на ней же. Он также как и Xen
может использовать аппаратную поддержку виртуализации (Intel VT, AMD‐V) ([6]), если она имеется, а
если нет, то выполняет эмуляцию платформы.
Это преодолевает ограничения Xen, платой за что становится некоторая потеря производительности.
Впрочем, она не значительная, так что производительность Guest платформы все еще близка к Host
Hardware.
VirtualBox, вероятно, является лучшим свободном средством эмуляции x86 платформы и вполне
может конкурировать с платными продуктами от VmWare ([9]).
В отличие от Xen, код VirtualBox работает в рамках Host OS. Для его работы запускается несколько
процессов, которые используют процессорное время и ресурсы ОС. Процессы VirtualBox планируются
и управляются также, как и все остальные процессы в система, что добавляет системе удобства и
гибкости.
Host OS практически не претерпевает изменений. Требуется лишь небольшой драйвер, работающий
на уровне ядра (ring‐0), который:
• Выделяет физическую память для VM
• Управляет аппаратной поддержкой (Intel VT, AMD‐V)

• Выполняет переключение в Guest VM режим
• Сохраняет и восстанавливает CPU регистры и таблицы дескрипторов, если прерывание
произойдет в момент выполнения кода в Guest VM.
Требования удовлетворяет требованиям со следующими комментариями:
1. В качестве Host и Guest платформ VirtualBox поддерживает только x86 архитектуру, причем
делает это максимально эффективно даже на оборудовании без аппаратной поддержки. Если
требуется поддержка других Host или Guest платформ, то VirtualBox не стоит использовать.
2. Большим недостатком является отсутствие поддержки SMP. В скором времени это должно
быть исправлено.
3. VirtualBox эмулирует широкий ряд устройств, однако, возможно, что требуемое Guest
Hardware не поддерживается. В этом случае потребуется реализовать его эмуляцию.
Qemu
В случае, когда требуется реализовать полную виртуализацию средствами эмуляции на помощь
приходит проект Qemu ([2]).
Методы виртуализации: Полная виртуализация, эмуляция
Тип: Эмулятор
Host CPU / OS: x86, AMD64, IA‐64, PowerPC, Alpha, SPARC 32 и 64, ARM, S/390, M68k, SMP поддержан / Windows, Linux, Mac OS
X, Solaris, FreeBSD, OpenBSD, BeOS
Guest CPU / OS: x86, AMD64, ARM, SPARC 32 и 64, PowerPC, MIPS, SMP поддержан / любая
Лицензия: GPL/LGPL
Qemu эмулирует широкий круг Guest платформ (осуществляя в том числе кросс‐платформенную
эмуляцию) средствами динамической трансляции. Этот подход позволяет достичь высокой
производительность, а реализация Qemu позволяет облегчить портирование Qemu на другие Host
платформы. Наряду с полной эмуляцией платформ, Qemu может осуществлять виртуализацию
приложений, позволяя запускать на x86 платформе приложения, собранные под Linux для ARM.
В добавок к эмуляции, Qemu поддерживает акселерированный режим, позволяющий смешивать
бинарную трансляцию с непосредственным запуском кода. Этот режим позволяет достичь очень
высокой производительности сравнимой с VirtualBox или Xen.
Qemu эмулирует широкий круг устройств, что позволяет без труда запускать большинство ОС.
Процесс добавления новых устройств прост и при необходимости легко может быть осуществлен.
Интересным является тот факт, что Xen, VirtualBox так или иначе используют различные части Qemu.
Это динамический компилятор Qemu, эмуляции различных устройств и некоторые другие части.
Как и VirtualBox, Qemu запускается в рамках обычного процесса под одной из множества
поддерживаемых Host OS, который планируется и контролируется также как и прочие процессы
системы. Для акселерации, специальный драйвер должен быть загружен в Host OS.
Не смотря на то, что динамическая трансляция значительно более эффективна, чем интерпретация,
производительность все же сильно страдает. В то же время, Qemu вероятно является наиболее
эффективным эмулятором с открытыми исходными кодами.
Покрытие требований:

1. Qemu поддерживает и эмулирует широкий круг процессоров, и если требуемое оборудование
еще не поддержано, то Qemu является хорошей платформой для ее добавления. Важно все
же понимать, что Qemu – это прежде всего эмулятор.
2. За исключением акселерированного режима, производительность Guest платформы
значительно ниже чем у Host платформы по понятным причинам. В акселерированном
режиме скорость практически идентична.
Заключение
Итак, в статье был рассмотрены абстрактный проект виртуализации, обсуждены возможные вариации
его требований и варианты его реализации его на основе доступных open source проектов. В центре
рассмотрения была Linux/x86 платформе, являющаяся, вероятно, наиболее популярной платформой
для виртуализации.
Рекомендации вкратце можно сформулировать так:
1. Проект Xen идеально подходит для создания виртуальных x86 серверов на реальной x86
платформе. При этом либо паравиртуализация используется либо требуется аппаратная
поддержка для полной виртуализации.
2. VirtualBox идеален для полной виртуализации x86 платформы на ней же в качестве
пользовательского приложения. Аппаратная поддержка виртуализации желательна, но не
критична.
3. Qemu следует использовать когда требуется кросс‐платформенная эмуляция.
Подводя итог можно сказать, что в настоящее время имеется достаточное количество open source
проектов, на базе которых можно построить широкий круг виртуализационных решения. Эти проекты
без изменений покрывают наиболее востребованные задачи и могут быть легко модифицированы
для покрытия многих остальных.
Ссылки
1. Xen ‐ http://xen.org/
2. Qemu ‐ http://bellard.org/qemu/
3. Sun VirtualBox ‐ http://www.virtualbox.org/
4. Сравнение виртуальных машин ‐ http://ru.wikipedia.org/wiki/Сравнение_виртуальных_машин
5. Amazon EC2 ‐ http://aws.amazon.com/ec2/
6. x86 virtualization ‐ http://en.wikipedia.org/wiki/X86_virtualization
7. Virtual machine ‐ http://en.wikipedia.org/wiki/Virtual_machine
8. Xen Architecture Overview ‐
http://wiki.xensource.com/xenwiki/XenArchitectureaction=AttachFile&do=get&target=Xen+Archit
ecture_Q1+2008.pdf
9. VmWare ‐ http://en.wikipedia.org/wiki/VMware
10. Гипервизор ‐ http://ru.wikipedia.org/wiki/Гипервизор