VM (Virtual Machine)

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 17:12, 24 августа 2017.
Open book.svg Авторство
Д.Б. Малышева
Согласовано: 02.05.2016

Содержание

История

History1.jpg

В наши дни лидерами рынка виртуализации являются VMware, Microsoft, Citrix и Red Hat, однако эти компании не стояли у истоков технологии. В 1960-х годах прошлого века все начиналось с разработок специалистов таких компаний, как General Electric (GE), Bell Labs, IBM и др. За более чем полвека область виртуализации прошла значительный путь.

Истоки

Виртуализация зародилась в качестве средства для расширения размеров оперативной памяти компьютеров в 60-х годах прошлого века. В те времена речь шла о том, чтобы добиться возможности исполнения нескольких программ — первым суперкомпьютером, в котором процессы операционной системы были разделены, стал проект департамента электротехники Университета Манчестера под названием Atlas (финансировался компанией Ferranti Limited).

Суперкомпьютер Atlas

Atlas.jpg

Atlas был самым быстрым суперкомпьютером своего времени. Частично это достигалось благодаря разделению системных процессов с помощью суперзвизора (компонент, отвечающий за контроль ключевых ресурсов — процессорного времени и т.д.) и компонента, осуществлявшего исполнение пользовательских программ. Впервые в Atlas была использована виртуальная память (one-level store) — системное хранилище памяти было отделено от использовавшегося пользовательскими программами. Данные разработки стали первыми шагами по направлению к созданию уровня абстракции, использованного в дальнейшем во всех основных технологиях виртуализации.

Проект M44/44X

Следующим шагом в развитии технологий виртуализации стал проект корпорации IBM. Американские исследователи пошли дальше британских коллег и разработали концепцию «виртуальной машины», попытавшись разделить компьютер на отдельные небольшие части. Основным компьютером был «научный» IBM 7044 (M44), на котором запускались виртуальные машины 7044 (40X) — на данном этапе виртуальные машины не симулировали полностью работу «железа».

CP/CMS

CP CMS.jpg

IBM работала над мейнфреймом S/360 — планировалось, что этот продукт станет заменой предыдущим разработкам корпорации. S/360 была однопользовательской системой, которая могла запускать несколько процессов одновременно. Фокус деятельности корпорации начал меняться после 1 июля 1963 года, когда ученые Массачусетского технологического института (MIT) запустили проект MAC. Изначально сокращение системы было образовано от фразы Mathematics and Computation, показывая направленность разработки, но позднее под MAC стали понимать Multiple Access Computer («компьютер множественного доступа»).

IBM S/360

IbmS360.jpg

Проект MAC получил грант от американского оборонного агентства DARPA в размере $2 млн — среди поставленных задач было проведение исследований в области операционных систем, искусственного интеллекта и теории вычислений. Для решения некоторых из этих задач ученым MIT понадобилось компьютерное «железо», с помощью которого могли бы работать несколько пользователей одновременно. Запросы о возможности создания таких систем были отправлены в IBM, General Electric и некоторым другим вендорам. IBM в то время не была заинтересована в создании подобного компьютера — в руководстве корпорации считали, что на рынке отсутствует спрос на такие устройства. В MIT, в свою очередь, не захотели использовать для исследований модифицированную версию S/360. Потеря контракта стала настоящим ударом для IBM — особенно после того, как в корпорации узнали об интересе к многозадачным компьютерам со стороны Bell Labs. Для удовлетворения нужд MIT и Bell Labs был создан мейнфрейм CP-40. Частным клиентам этот компьютер никогда не продавался и использовался лишь учеными, однако данная разработка является крайне важной вехой в истории виртуализации, поскольку именно она позднее эволюционировала в систему CP-67, которая стала первым коммерческим мейнфреймом с поддержкой виртуализации. Операционная система CP-67 называлась CP/CMS — первые две буквы были сокращением от Control Program, а CMS — сокращением фразы Console Monitor System. CMS была однопользовательской интерактивной операционной системой, а CP была программой, которая создавала виртуальные машины. Суть системы заключалась в запуске модуля CP на мейнфрейме — на нем запускались виртуальные машины, работающие на операционной системе CMS, с которой, в свою очередь, уже работали пользователи. В данном проекте была впервые реализована интерактивность — ранее системы IBM могли только «съедать» поданные на вход программы и печатать результаты вычислений, в CMS появилась возможность взаимодействия с программами во время их работы. Публичный релиз CP/CMS состоялась в 1968 году. В дальнейшем IBM создала многопользовательскую операционную среду на компьютерах IBM System 370 (1972 году) и System 390 (операционная система VM/ESA).

Виртуализация в СССР

Xedit.png

В СССР аналогом IBM System/370 являлся проект СВМ (Система Виртуальных Машин), запущенный в 1969 году. Одной из главных задач проекта была адаптация системы IBM VM/370 Release 5 (её более ранняя версия CP/CMS). В СВМ была реализована последовательная и полная виртуализация (на виртуальной машине можно было запустить другую копию СВМ и т.д.).

SoftPC, Virtual PC и VMware

В 1988 году компания Insignia Solutions представила эмулятор программного обеспечения SoftPC, с помощью которого можно было запускать приложения DOS на рабочих станциях Unix — функциональность, которая ранее была недоступна. В то время PC с возможностью запуска MS DOS стоил около $1500, а рабочая UNIX-станция с SoftPC обошелся бы всего в $500. В 1989 году была выпущена Mac-версия SoftPC — пользователи этой ОС смогли не только запускать приложения DOS, но и Windows-программы. Успех SoftPC сподвиг другие компании к выпуску аналогичных продуктов. В 1997 году Apple создала программу Virtual PC (продавалась через компанию Connectix). С помощью этого продукта пользователи Mac получили возможность запускать ОС Windows, что позволило сгладить недостаток софта под Mac. В 1998 года была основана компания VMware, которая в 1999 году вывела на рынок аналогичный продукт под названием VMware Workstation. Первоначально программа работала только на Windows, однако позднее была добавлена поддержка других операционных систем. В этом же году компания выпустила первое средство виртуализации для платформы x86 под названием VMware Virtual Platform.

Развитие рынка в 2000-х

Hyper.gif

В 2001 году VMware выпуcтила два новых продукта, которые позволили компании выйти на корпоративный рынок — ESX Server и GSX Server. GSX позволил пользователям запускать виртуальные машины внутри операционных систем вроде MS Windows (данная технология является гипервизором второго типа — Type-2 Hypervisor). ESX Server относится к гипервизорам первого типа (Type-1 Hypervizor) и не требует наличия домашней операционной системы для запуска виртуальных машин. Гипервизоры первого типа гораздо эффективнее, поскольку обладают большими возможностями по оптимизации и не требуют траты ресурсов на запуск и поддержание работы операционной системы. После выпуска ESX Server компания VMware стремительными темпами захватила корпоративный рынок, опередив конкурентов. Вслед за VMware на данный рынок вышли и другие игроки — в 2003 году Microsoft купила Connectix и перезапустила продукт Virtual PC, а затем, в 2005 году выпустила и энтерпрайз-решение Microsoft Virtual Server. В 2007 году на рынок корпоративной виртуализации вышла корпорация Citrix, купившая open source платформу для виртуализации под названием Xensource. Этот продукт затем был переименован в Citrix XenServer.

Определение и понятие виртуальной машины

Виртуальная машина - программная или аппаратная среда, эмулирующая аппаратное обеспечение некоторой платформы, исполняющая некоторый код (например, байт-код, шитый код, p-код или машинный код реального процессора), или спецификация такой системы (например: «виртуальная машина языка программирования Си»).То есть, виртуальная машина - это программа, которую запускают из своей операционной системы. Программа эмулирует физический компьютер, поэтому у виртуальной машины есть:

  • BIOS
  • жесткий диск (отведенное место на вашем жестком диске)
  • CD-ROM (ваш CD-ROM или подключенный ISO-образ)
  • сетевые адаптеры для соединения с вашей реальной машиной, сетевыми ресурсами или другими виртуальными машинам

На виртуальные машины, как и на реальные, можно ставить операционные системы.На одном компьютере может функционировать несколько виртуальных машин (это может использоваться для имитации нескольких серверов на одном реальном сервере с целью оптимизации использования ресурсов сервера).

Архитектура виртуальной машины

Arhitektura.png
Vm7.png
00 03.gif

Операционная система, управляющая реальным оборудованием и предоставляющая функции для доступа к нему, называется "хостовой операционной системой". Хостовая операционная система загружается самостоятельно и не требует виртуальной машины для своей работы. Операционные системы, работающие в виртуальных машинах, называются "гостевыми операционными системами". На одном физическом компьютере может быть запущена одна хостовая и много гостевых операционных систем. Общая системная архитектура виртуальной машины построена на взаимодействии трех основных компонентов:

  • приложение виртуальной машины;
  • драйвер виртуальных машин;
  • монитор виртуальной машины.

Приложение виртуальной машины - это обычное приложение, выполняющееся под управлением хостовой операционной системы. Приложение виртуальной машины имеет графический интерфейс и позволяет пользователю взаимодействовать с виртуальной машиной и гостевой операционной системой. Приложение является непереносимым компонентом виртуальной машины, поскольку разрабатывается для конкретной хостовой операционной системы и использует ее функции для отображения графического интерфейса и доступа к внешним устройствам. Как правило, для портирования виртуальной машины под другую хостовую операционную систему, необходимо полностью переписать приложение. Приложение виртуальной машины построено по многопоточной технологии и поддерживает три основных потока:

  1. Поток виртуализации для передачи управления монитору и обмена информационными сообщениями с ним;
  2. Графический поток для отображения видеобуфера гостевой операционной системы;
  3. Поток GUI для работы пользовательского интерфейса и передачи событий от мыши и клавиатуры гостевой операционной системе.

Для каждой виртуальной машины запускается своя копия приложения виртуальной машины. Приложение виртуальной машины выполняет следующие основные функции:

  1. Создание, удаление и конфигурирование виртуальных машин;
  2. Включение, выключение и управление работой виртуальных машин;
  3. Обеспечение интерфейса пользователя с гостевой операционной системой ввод с клавиатуры (мыши) и отображение экрана гостевой операционной системы;
  4. Выделение памяти для виртуальной машины и загрузка (инициализация) монитора виртуальной машины;
  5. Взаимодействие с физическими ресурсами компьютера через функции хостовой операционной системы (работа с жесткими и гибкими дисками, видеокартой, последовательными и параллельными портами и т.д.).

Драйвер виртуальных машин - это системный драйвер работающий на уровне привилегий ядра хостовой операционной системы. Драйвер является шлюзом между приложением и монитором виртуальной машины, позволяющий им передавать управление и обмениваться информационными сообщениями между собой. Кроме того, драйвер выполняет функции взаимодействия с хостовой операционной системой, такие как выделение и закрепление страниц памяти по физическим адресам. Драйвер виртуальной машины является непереносимым компонентом виртуальной машины. Для портирования виртуальной машины под другую хостовую операционную систему необходимо полностью переписать драйвер используя средства этой операционной системы. Все виртуальные машины пользуются одной копией драйвера виртуальных машин. Монитор виртуальной машины - это основной компонент виртуальной машины. Монитор не зависит от конкретной хостовой операционной системы и отвечает за создание виртуальной среды для исполнения гостевой операционной системы. Монитор работает на уровне привилегий ядра хостовой операционной системы и реализует выбранную технологию виртуализации. Поскольку монитор включает в себя блок эмуляции процессора и внешних устройств, то время от времени он вынужден обращаться к приложению для доступа к реальным внешним устройствам. Для каждой виртуальной машины запускается своя копия монитора виртуальной машины. Монитор может взаимодействовать с приложением двумя способами:

  1. Синхронно при помоши обмена информационными сообщениями через драйвер виртуальных машин;
  2. Асинхронно при помощи разделяемых системных структур и участков памяти.

Монитор работает в изолированном от хостовой операционной системы контексте и поддерживает свои собственные системные таблицы GDT, LDT, IDT и т.д. При переключении контекста между монитором и хостовой операционной системой выполняется операция сохранения одного контекста и загрузка другого. Переключение контекста напоминает процедуру переключения задач операционной системы, но включает в себя дополнительный набор данных. Также, монитор должен отлавливать и перенаправлять хостовой операционной системе все прерывания от реальных внешних устройств.

Классификация виртуальной машины

Sxema.gif

Процессные виртуальные машины

Процессные ВМ создают виртуальные среды ABI или API для пользовательских приложений. Различные их разновидности позволяют в многозадачном режиме осуществлять репликацию операционной среды, эмулировать систему команд, оптимизировать код или выполнять программы на языках высокого уровня.

Многозадачные системы

Самая распространенная процессная ВМ стала настолько привычной, что мало кто воспринимает ее как виртуальную машину. Большинство операционных систем могут работать в многозадачном режиме, поддерживая несколько пользовательских процессов одновременно, благодаря чему у каждого из них «создается иллюзия единоличного владения» машиной. Каждый процесс имеет собственные адресное пространство, регистры и файловую структуру. Операционная система организует работу базового оборудования в режиме разделения времени. Фактически операционная система предоставляет процессную ВМ каждому из одновременно выполняемых приложений.

Интерпретаторы и динамические трансляторы двоичного кода

Более сложной проблемой для процессных ВМ является поддержка программ в двоичном коде, которые скомпилированы для системы команд, отличающейся от системы команд хоста. Свежий пример процессной ВМ — программный пакет Intel IA32-EL, позволяющий на платформе Itanium выполнять приложения, рассчитанные на IA-32. Проще всего эмулировать команды путем интерпретации. Программа-интерпретатор одну за другой выбирает из памяти, декодирует и выполняет команды гостевой программы. Этот процесс может быть довольно медленным и требовать десятков команд хост-машины для интерпретации каждой исходной команды. Более высокая производительность достигается путем динамической трансляции двоичного кода, в ходе которой команды гостевой программы поблочно преобразуются в команды хоста и сохраняются для повторного использования в кэш-памяти команд. Таким образом, в случае циклического выполнения транслированных команд удается амортизировать относительно высокие затраты на трансляцию.

Оптимизаторы двоичного кода

Для повышения производительности динамические трансляторы иногда оптимизируют двоичный код. Эта возможность приводит к идее создания виртуальной машины, в которой гость и хост используют одну и ту же систему команд. Единственным назначением такой ВМ становится оптимизация двоичного кода. Оптимизаторы используют информацию из профиля, собранную при интерпретации или трансляции, чтобы оптимизировать двоичный код «на лету». Примером такого оптимизатора является система Dynamo — один из результатов реализации научно-исследовательского проекта компании Hewlett-Packard.

Виртуальные машины для языков высокого уровня

Основное назначение процессных ВМ — обеспечить переносимость программного обеспечения. При этом эмуляция одной распространенной системы команд с помощью другой требует значительных усилий программистов, но обеспечивает кроссплатформенную совместимость лишь в некоторых случаях. Полной переносимости проще достичь путем встраивания процессной ВМ в среду разработки приложений на языках высокого уровня. ВМ языка высокого уровня не связана напрямую ни с одной реальной платформой; скорее, она предназначена для упрощения переноса программ и реализации функций одного или нескольких языков высокого уровня. Преимуществом ВМ языка высокого уровня является простота переноса прикладных программ при условии, что ВМ и библиотеки уже реализованы на базовой платформе. Хотя реализация ВМ требует некоторых усилий, это намного проще, чем разработка полнофункционального транслятора и перенос каждого приложения путем перекомпиляции. Известными примерами ВМ языка высокого уровня являются архитектура виртуальной машины Java компании Sun Microsystems и среда Microsoft Common Language Infrastructure, на которой основана платформа .NET Framework. В обеих системах применяются стековые архитектуры ISA, что позволяет устранить необходимость в регистрах, использовать абстрактную спецификацию данных и модель памяти, поддерживающие безопасное объектно-ориентированное программирование.

Системные виртуальные машины

Рис21.gif

Системная ВМ обеспечивает полнофункциональную среду, в которой могут сосуществовать операционная система и несколько процессов, относящихся к разным пользователям. С помощью системных ВМ одна аппаратная платформа способна одновременно поддерживать несколько изолированных гостевых операционных систем. Системные ВМ появились в середине 60-х годов. В то время компьютерные системы на базе мэйнфреймов были очень большими и дорогими, обычно обслуживали многочисленные группы пользователей. С появлением технологий ВМ эти группы получили возможность на общем оборудовании эксплуатировать различные операционные системы. По мере снижения цен на компьютерное оборудование и развития настольных ПК интерес к первым системным ВМ постепенно снизился. Однако сегодня системные ВМ снова набирают популярность, поскольку на смену мэйнфреймам пришли серверы и серверные комплексы, обслуживающие большие группы потребителей. Одним из важнейших применений технологии системных ВМ является изоляция систем, одновременно работающих на общей аппаратной платформе. В таких случаях отказ в работе или нарушение безопасности одной из гостевых систем не влияет на программное обеспечение, выполняющееся на других гостевых системах. В системной ВМ монитор VMM обеспечивает репликацию платформы. Основной проблемой является распределение аппаратных ресурсов между несколькими гостевыми операционными системами. VMM управляет всеми аппаратными ресурсами. Гостевая операционная система и ее прикладные процессы работают под скрытым контролем VMM. Когда гостевая ОС пытается выполнить привилегированную команду или операцию, непосредственно затрагивающую общие аппаратные ресурсы, VMM ее перехватывает, проверяет правильность и исполняет от имени гостя. Гостевое ПО «не знает» об этой негласной работе.

Классические системные ВМ

Большинство системных ВМ обеспечивают примерно одинаковые функциональные возможности, но различаются деталями реализации. При классическом подходе монитор VMM устанавливается на «голом железе», а ВМ располагается поверх него. VMM выполняется в привилегированном режиме, в то время как гостевые операционные системы лишены почти всех привилегий. Это необходимо, чтобы VMM мог перехватывать и эмулировать те их действия, которые в обычных условиях связаны с управлением жизненно важными аппаратными ресурсами.

Вложенные ВМ

В альтернативной реализации системной ВМ программное обеспечение виртуализации располагается поверх существующей хост-системы. Такая ВМ называется вложенной. Преимущество вложенных ВМ состоит в том, что пользователь устанавливает их точно так же, как любую прикладную программу. Чтобы получить доступ к драйверам устройств и другим низкоуровневым услугам, программное обеспечение виртуализации обращается к хост-системе, а не к VMM. Примером вложенной ВМ может служить сервер VMware GSX Server , который выполняется на аппаратной платформе IA-32.

Интегральные ВМ

В обычных системных ВМ хост-система, все гостевые операционные системы и прикладные программы используют архитектуру ISA базового оборудования. Однако в некоторых ситуациях гость и хост не имеют общей ISA. Например, две самые популярные настольные системы, Windows PC и Apple PowerPC, используют различные ISA и разные операционные системы. Интегральные ВМ справляются с такой ситуацией, виртуализируя все программное обеспечение, в том числе операционную систему и приложения. Из-за различий в системах команд ВМ должна эмулировать и код приложений, и код операционной системы. Примером ВМ такого типа служит эмулятор Virtual PC, в котором система Windows работает на платформе Macintosh. Программное обеспечение ВМ выполняется на хосте как обычная прикладная программа и не использует системных операций ISA.

Многопроцессорная виртуализация

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

Встроенные ВМ

Функциональность и мобильность — вот цели большинства системных ВМ, реализованных на уже имеющихся аппаратных средствах со стандартной архитектурой ISA. В отличие от них, встроенные ВМ реализуют новые частные архитектуры, нацеленные на повышение производительности и эффективности работы. ISA хост-машины может быть полностью новой или расширять возможности существующей.
IBM AS400.jpg

Для встроенной ВМ нет готовых приложений, а монитор VMM выглядит как составная часть оборудования, единственным назначением которого является эмуляция гостевой ISA. Для поддержания этой иллюзии VMM располагается в области памяти, скрытой от обычного программного обеспечения. В его состав входит транслятор двоичного кода, который преобразует гостевые команды в оптимизированные последовательности базовых команд и помещает их в скрытую кэш-память. Наиболее известный пример встроенной ВМ — процессор Transmeta Crusoe. Его базовые аппаратные средства используют архитектуру команд со сверхдлинным командным словом (very long instruction word, VLIW), а гостевая ISA — это Intel IA-32. Благодаря простоте аппаратной части, предназначенной для выполнения команд VLIW, разработчикам Transmeta удалось существенно снизить энергопотребление процессора. В системе IBM AS/400 (сегодня известна как iSeries) также используется технология встроенных ВМ. В отличие от других встроенных ВМ, основное назначение AS/400 — поддержка объектно-ориентированной системы команд, позволяющей по-новому взглянуть на интерфейс между оборудованием и программным обеспечением. Сегодняшние реализации AS/400 основаны на расширенной архитектуре PowerPC, тогда как ранние версии использовали существенно отличавшуюся от нее частную архитектуру ISA.

Обзор технологии виртуальной машины

Квази-эмуляция

Workstation.png

Процессор изначально может быть спроектирован так, чтобы аппаратно поддерживать виртуализацию. Это значит, что на пользовательском уровне привилегий все инструкции, работающие с системными регистрами процессора, вызывают исключение процессора, позволяя виртуализующему монитору эмулировать их поведение. К сожалению, архитектура процессора IA-32 не поддерживает полностью виртуализацию на аппаратном уровне. Некоторые инструкции на пользовательском уровне привилегий при записи в системные регистры генерируют исключение процессора, а при чтении из системных регистров нет. Таким образом, при попытке виртуализовать эти системные регистры для гостевой операционной системы мы столкнемся с ситуацией, когда гостевой код прочтет из этих регистров совсем не то, что он туда записывал. И, следовательно, путь исполнения гостевой операционной системы изменится. Говоря по-простому, гостевая операционная система вылетит с синим/черным/зеленым/желтым экраном. Квази-эмуляция - это технология, позволяющая аппаратно невиртуализуемый процессор виртуализовать программным путем. Основные задачи квази-эмуляции можно сформулировать следующим образом:

  • Необходимо определить множество инструкций процессора, которые можно исполнять без эмуляции. Все системные регистры и области процессора, с которыми работают эти инструкции, надо поддерживать в состоянии, ожидаемом гостевой операционной системой;
  • Необходимо определить множество инструкций процессора, которые нельзя исполнять без эмуляции. Надо обеспечить обнаружение этих инструкций в гостевом коде и произвести их эмуляцию. В тех случаях, когда для эмуляции требуется взаимодействие с хостовой операционной системой (например, при эмуляции внешних устройств), надо обеспечить переключение в контекст хостовой операционной системы и использовать ее функции; Для нормального функционирования хостовой операционной системы надо обеспечить передачу ей прерываний от внешних устройств, произошедших в контексте монитора или гостевой операционной системы.

Примеры проектов, выполненных по технологии квази-эмуляции:

  • Виртуальная машина Serenity Virtual Station (SVISTA)(бывшая twoOStwo), разработанная российской компанией Параллели по заказу немецкой компании NetSys GmbH. SVISTA позволяет запускать такие гостевые операционные системы, как OS/2, Linux, QNX, MSDOS и другие. В настоящий момент существует три продукта: SVISTA для Windows NT/2000/XP, twoOStwo для Linux и twoOStwo для FreeBSD;
  • Технология Virtual Platform компании VMware, позволяющая запускать большое количество Intel х86 гостевых операционных систем. Компания VMware предлагает четыре продукта: VMware Workstation для Windows NT/2000/XР, VMware Workstation для Linux, VMware GSX Server (group server) и VMware ESX Server (enterprise server);
  • Проект с открытым кодом Plex86, позволяющий запускать различные операционные системы Intel х86 под Linux;
  • Проект с открытым кодом L4Ka, использующий микроядро;
  • Проект с открытым кодом Xen, позволяет запускать модифицированные ОС Linux, FreeBSD, NetBSD и Windows XP под Linux, FreeBSD, NetBSD. При соблюдении некотрых условий позволяет получить даже прирост производительности.

Существуют различные программные техники, позволяющие решать задачи квази-эмуляции. Две наиболее популярные техники, используемые в большинстве проектов виртуализации и эмуляции, "техника программного отладчика" и "техника динамической трансляции".

Техника программного отладчика

Эта техника позаимствована у программных отладчиков и заключается в установке точек прерывания на эмулируемые инструкции гостевого кода. При старте виртуального компьютера монитор начинает анализировать гостевой код с процедуры POST из ROM BIOS, расположенный по адресу FFFF:FFFO. Он выбирает по очереди инструкции гостевого кода и проставляет точки прерывания на все эмулируемые инструкции. Как только встречается инструкция ветвления с неопределенным адресом перехода (например, косвенный JMP), монитор проставляет на нее точку прерывания и передает управление отсканированному коду. При исполнении гостевого кода монитор гарантированно получает прерывания по каждой эмулируемой инструкции и выполняет соответствующий код эмуляции, В момент получения прерывания от последней отсканированной инструкции монитор определяет адрес перехода и повторяет процедуру сканирования для нового адреса. Таким образом обеспечивается постоянный контроль за выполнением гостевого кода и эмуляция всех необходимых инструкций. Основная проблема техники программного отладчика это значительные накладные расходы на обработку прерывания и переключение контекста "гостевая операционная система" - "монитор" при эмуляции каждой инструкции.

Техника динамической трансляции

При использовании техники динамической трансляции монитор выступает как компилятор гостевого кода. Монитор просматривает исходный гостевой код и преобразует его в исполняемый гостевой код. При этом эмулируемые инструкции заменяются на набор инструкций эмуляции непосредственно в исполняемом гостевом коде. Поскольку вместо одной эмулируемой инструкции может быть вставлено 10 - 20 инструкций эмуляции, линейные адреса отдельных участков гостевого кода съезжают. Следовательно, адреса всех инструкций перехода тоже должны быть скорректированы. Для всех инструкций гостевого кода необходимо поддерживать hash-таблицу преобразований линейных адресов, чтобы по адресу инструкции в исходном коде можно было получить ее адрес в откомпилированном коде и наоборот. Это требует значительных накладных расходов на процедуру трансляции гостевого кода. Зато уже обработанный гостевой код исполняется очень быстро и без накладных расходов, так как эмуляция производиться непосредственно в исполняемом коде. Обе описанные техники модифицируют исходный гостевой код перед его исполнением. Поэтому при виртуализации "самомодифицирущегося" и "самочитающегося" кода возникают проблемы. Существуют различные пути решения этих проблем. С "самомодифицирующимся" кодом легко справиться при помощи механизма страничной защиты. А вот для решения проблемы "самочитающегося" кода архитектура IA-32 не предлагает никакого адекватного средства. Поэтому способы защиты от "самочитающегося" кода являются важнейшими know-how авторов различных технологий виртуализации. Очень часто технология квази-эмуляции использует как технику программного отладчика, так и технику динамической трансляции. Техника программного отладчика эффективней для однократно исполняемых участков кода с небольшим содержанием эмулируемых инструкций. А техника динамической трансляции эффективней для часто повторяемых участков кода с большим содержанием эмулируемых инструкций. Например, можно использовать динамическую трансляцию для виртуализации ядра гостевой операционной системы, а программную отладку для виртуализации кода приложений.

Эмуляция процессора

По аналогии с контекстом отдельного процесса можно ввести понятие контекста операционной системы. Для этого контекст процесса надо расширить системными регистрами CROx, дескрипторными таблицами GDT, LDT, IDT, страничными таблицами PDE, PTE, отладочными регистрами DROx. В схеме виртуализации присутствует три независимых контекста

  • контекст хостовой операционной системы
  • контекст монитора виртуальной машины
  • контекст гостевой операционной системы

Если контексты хостовой и гостевой операционных систем абсолютно независимы, то контекст монитора является некоторым расширением контекста гостевой операционной системы. Контекст монитора является расширением контекста гостевой операционной системы. Величина этого расширения зависит от выбранной стратегии виртуализации. Существует два противоположных подхода к эмуляции системных областей процессора:

  • Использование механизма страничной зашиты для эмуляции системной области и запуск всех работающих с областью инструкций без эмуляции (например, защита и эмуляция таблицы GDT и запуск инструкций загрузки/чтения сегментных регистров без эмуляции);
  • Разрешение свободной записи/чтения системной области и эмуляция всех работающих с областью инструкций (например, свободная запись/чтение в таблицу GDT и эмуляция инструкций загрузки/чтения сегментных регистров).

Схема виртуализации должна обеспечивать:

  • Эмуляцию сегментной модели процессора GDT, LDT и IDT;
  • Эмуляцию страничной модели процессора PDE и PTE;
  • Эмуляцию колец защиты процессора;
  • Эмуляцию исключений и прерываний процессора;
  • Эмуляцию набора инструкций процессора.
  • Эмуляция внешних устройств

Для взаимодействия с внешними устройствами процессор использует инструкции ввода/вывода ( IN, OUT). Виртуализационная схема может использовать два различных метода эмуляции внешних устройств: метод полной эмуляции и/или метод сквозного взаимодействия. В первом случае, все регистры и области устройства полностью эмулируются, а для взаимодействия с реальным устройством используются функции хостовой операционной системы. При этом реальное устройство может использоваться виртуальной машиной совершенно не так, как это предполагалось гостевой операционной системой. Например, виртуальный CD-ROM может быть отображен как на реальный CD-ROM, так и в файл на жестком диске. Несмотря на то, что виртуальная машина может запускаться на самых разных компьютерах с разными конфигурациями, для гостевой операционной системы всегда будет эмулироваться единый набор виртуального "железа". То есть, один раз настроенную и проинсталлированную виртуальную машину можно переносить с одного компьютера на другой, не заботясь о совместимости. Для метода сквозного взаимодействия необходимо осуществить монопольный захват реального устройства одной виртуальной машиной. В процессе работы оно будег недоступно ни хостовой операционной системе, ни другим виртуальным машинам. При этом устройство не эмулируется, а напрямую используется гостевой операционной системой. Все команды гостевой операционной системы перехватываются монитором и перенаправляются захваченному устройству. Естественно, ни о какой совместимости здесь речь уже не идет. Зато возможна работа гостевой операционной системы с устройствами, которые не поддерживаются хостовой операционной системой.

Эмуляция API операционной системы

Virtuozzo.jpg

Обычно приложения работают в изолированном адресном пространстве и взаимодействуют с оборудованием при помощи API (ApplicationProgrammingInterface) , предоставляемым операционной системой. Если две операционные системы совместимы по своим АРI (например, Windows 98 и Windows 2000), то приложения, разработанные для одной из них, будут работать и на другой. Если две операционные системы несовместимы по своим API (например, Windows 2000 и Linux), то существует способ перехватить обращения приложений к АРI и сымитировать поведение одной операционной системы средствами другой операционной системы. При таком подходе можно поставить одну операционную систему и работать одновременно как с ее приложениями, так и с приложениями другой операционной системы. Поскольку весь код приложения исполняется без эмуляции и лишь вызовы API эмулируются, потеря в производительности незначительная. Но из-за того, что многие приложения используют недокументированные функции API или обращаются к операционной системе в обход API, даже очень хорошие эмуляторы API имеют проблемы совместимости и позволяют запустить не более 70% от общего числа приложений. Кроме того, поддерживать эмуляцию API бурно развивающейся операционной системы (например, такой как Windows) очень нелегко, и большинство эмуляторов АРI так и остаются эмуляторами какой-то конкретной версии операционной системы. Так, в Windows NT/2000 до сих пор встроен эмулятор для приложений OS/2 версии I.х, а в последних версиях OS/2 Warp 4 есть возможность запуска приложений Windows 3.11. Но самый большой минус способа эмуляции API - это его строгая ориентация на конкретную операционную систему. Для того, чтобы запустить в нем приложения другой операционной системы, необходимо все переписывать с нуля. Примеры продуктов, выполненных по технологии эмуляции АРI операционной системы:

  • Проект с открытым кодом Wine (Wine Is Not an Emulator), позволяющий запускать приложения DOS, Win16 и Win32 под операционными системами Unix;
  • Продукт Win4Lin компании Netraverse, позволяющий запускать операционные системы семейства Windows под операционной системой Linux;
  • Проект с открытым кодом DOSEMU, позволяющий запускать приложения MS DOS под операционной системой Linux;
  • Проект с открытым кодом User Mode Linux (UМL), позволяющий запускать несколько копий операционной системы Linux на одном компьютере(в настоящее время встроен в ядро Linux версий 2.6);
  • Технология Virtuozzo, разработанная российской компанией SWsoft и позволяющая запускать несколько копий операционной системы Linux на одном компьютере;
  • Технология, используемая во FreeBSD для запуска приложений Linux.
  • Проект SoftPear, в перспективе позволяющий запускать приложения Mac OS X на Linux и FreeBSD

Полная эмуляция

Images12.png

Проекты, выполненные по технологии полной эмуляции работают как интерпретаторы. Они последовательно выбирают код гостевой операционной системы и эмулируют поведение каждой отдельно взятой инструкции. Поскольку при этом полностью эмулируется поведение как процессора, так и всех внешних устройств виртуального Intel х86 компьютера, то существует возможность запускать эмулятор на компьютерах с совершенно другой архитектурой, например, на рабочих станциях Mаc или на RISC'овых серверах Sun. Самый серьезный недостаток этого подхода заключается в катастрофической потере производительности гостевой операционной системы. Скорость работы гостевых приложений может упасть в 100-1000 раз, что означает практическую невозможность нормальной работы с гостевой операционной системой внутри эмулятора. Тем не менее, существуют некоторые технологии, такие как динамическая трансляция, позволяющие увеличить скорость полной эмуляции. Полные эмуляторы чаще всего используются в качестве низкоуровневых отладчиков для исследования и трассировки операционных систем. Примеры проектов, выполненных по технологии полной эмуляции:

  • Проект с открытым кодом Bochs, позволяющий запускать различные операционные системы Intel х86 под Linux, Windows, BeOS и Мас OS;
  • Продукт Simics компании Virtutech, позволяющий запускать и отлаживать различные операционные системы Intel х86 под Windows и другими операционными системами;
  • Продукт Virtual PC фирмы Connectix(ныне купленной Microsoft) позволяющий запускать различные x86-ОС на PC и Mac;
  • Проект Qemu - самый быстрый эмулятор различных архитектур на PC. При использовании модуля Accelerator практически сравнивается по производительности с виртуальными машинами.

Преимущества и недостатки виртуальной машины

Преимущества виртуальных машин

  • Виртуальная машина работает под управлением гостевых операционных систем и содержит все стандартные компоненты компьютера, а значит виртуальная машина полностью совместима со стандартными операционными системами, программным обеспечением и т.д.;
  • В рамках виртуальной машины можно работать с устаревшими программными решениями и операционными системами;
  • Возможность создать защищенные пользовательские окружения для работы с сетью, в этом случае вирусные атаки могут нанести вред операционной системе, а не виртуальной машине;
  • Несколько виртуальных машин, развернутых на физических ресурсах одного компьютера, изолированы друг от друга, таким образом, сбой одной из виртуальных машин не повлияет на доступность и работоспособность сервисов и приложений других;
  • Поскольку каждая виртуальная машина представляет собой программный контейнер, то она может быть перенесена или скопирована, как и любой иной файл;
  • Виртуальные машины не зависят от аппаратного обеспечения, на котором функционируют в том смысле, что в качестве значений параметров виртуальной машины, таких как оперативная память, процессор и т.п., можно указать значения и типы, отличающиеся от реальной физической конфигурации компьютера;
  • Виртуальные машины идеально подходят для процессов обучения и переподготовки, поскольку позволяют развернуть требуемую платформу вне зависимости от параметров и программного обеспечения хоста (физического компьютера, на котором функционирует виртуальная машина);
  • Возможность сохранения состояния виртуальной машины позволяет быстро вернуться к точке до внесения изменений в систему;
  • В рамках одной гостевой операционной системы может быть развернуто несколько виртуальных машин, объединенных в сеть и взаимодействующих между собой;
  • Виртуальные машины могут создавать представления устройств, которых физически нет (эмуляция устройств).

Недостатки виртуальных машин

  • Для плодотворной работы нескольких операционных систем одновременно необходимы достаточные аппаратные ресурсы.
  • Медленная графика. Виртуальная машина не имеет возможности использования функций трехмерной графики с процессора, поэтому программе приходится симулировать работу обычного видеоадаптера.
  • Скорость работы. Виртуальная операционная система работает несколько медленнее, чем хостовая.

Известные виртуальные машины

Операционные системы и гипервизоры

  • Система виртуальных машин
  • ICore Virtual Accounts
  • Kernel-based Virtual Machine
  • Hyper-V
  • OpenVZ
  • Parallels Virtuozzo Containers
  • User-mode Linux
  • Virtual Iron
  • VM/CMS
  • VMware ESX
  • Xen

Автономные эмуляторы компьютеров

  • bochs
  • DOSBox
  • Virtual PC
  • Parallels Workstation
  • QEMU
  • VirtualBox
  • VMware Fusion
  • VMware Workstation

Среды языков программирования

  • ActionScript Virtual Machine
  • Clipper
  • Common Language Runtime
  • Harbour
  • Java Virtual Machine
  • Dalvik Virtual Machine
  • UCSD p-System
  • Форт

Ссылки