Добавлен: 29.10.2018
Просмотров: 48202
Скачиваний: 190
566
Глава 7. Виртуализация и облако
Для мультиплексированного оборудования у каждой виртуальной машины имелась
иллюзия наличия выделенного центрального процессора и конфигурируемого, но
фиксированного количества непрерывной оперативной памяти, начиная с физического
адреса 0.
Архитектурно эмуляция каждого виртуального устройства была разбита на компо-
нент внешнего интерфейса, видимый виртуальной машине, и компонент внутреннего
интерфейса, взаимодействующий с основной операционной системой (Waldspurger
and Rosenblum, 2012). Внешний интерфейс по своей сути был программной моделью
аппаратного устройства, которое могло управляться немодифицированными драй-
верами устройств, запущенными внутри виртуальной машины. Вне зависимости от
конкретного физического оборудования хост-машины, внешний интерфейс всегда
показывал одну и ту же модель устройства.
Например, первым внешним интерфейсом Ethernet-устройства была микросхема AMD
PCnet «Lance», когда-то популярная карта расширения персонального компьютера со
скоростью передачи данных 10 Мбит/с, а внутренний интерфейс обеспечивал сетевое
подключение к физической сети хост-машины. По иронии судьбы, VMware долго со-
храняла поддержку устройства PCnet и после того, как из обихода исчезли физические
карты расширения Lance, и на самом деле достигалась скорость ввода-вывода на по-
рядок выше 10 Мбит/с (Sugerman et al., 2001). Для устройств хранения информации
исходными внешними интерфейсами были IDE-контроллер и Buslogic Controller,
а внутренним интерфейсом был обычно либо файл в основной файловой системе, на-
пример виртуальный диск или образ ISO 9660, или же простой ресурс, такой как раздел
диска или физический компакт-диск.
У разделения внешних и внутренних интерфейсов есть еще одно преимущество: вир-
туальная машина VMware может быть скопирована с одного компьютера на другой,
возможно, с другими аппаратными устройствами. К тому же, поскольку виртуальная
машина взаимодействует только с компонентами внешнего интерфейса, ей не придется
устанавливать новые драйверы устройств. Это свойство, называемое аппаратно-неза-
висимой инкапсуляцией
(hardware-independent encapsulation), дает сегодня огромные
преимущества в серверных средах и облачных вычислениях. Оно позволяет вводить
последующие инновации, такие как приостановка-возобновление, расстановка кон-
трольных точек и незаметная миграция работающих виртуальных машин через физи-
ческие границы (Nelson et al., 2005). В облаке оно позволяет клиентам развертывать
их виртуальные машины на любом доступном сервере, не вникая в детали основного
оборудования.
Роль основной операционной системы
Завершающим важным конструкторским решением в VMware Workstation стало
развертывание этой системы поверх существующей операционной системы. Такое
решение классифицируется как гипервизор второго типа. У этого выбора было два
основных преимущества.
Во-первых, благодаря ему решалась вторая часть тех сложностей, которые были связа-
ны с разнообразием периферийных устройств. VMware реализовала эмуляцию внеш-
него интерфейса различных устройств, но с опорой на драйверы устройств основной
операционной системы для внутреннего интерфейса. Например, VMware Workstation
будет вести чтение или запись файла в основной файловой системе, чтобы эмулиро-
7.12. Изучение конкретных примеров: VMWARE
567
вать устройство виртуального диска, или выводить графику в окно рабочего стола
хост-машины, чтобы эмулировать видеокарту. Пока у основной операционной системы
есть соответствующие драйверы, VMware Workstation может запускать виртуальные
машины поверх нее.
Во-вторых, программный продукт может устанавливаться и восприниматься поль-
зователем как обычное приложение, упрощая тем самым его освоение. Как и любое
другое приложение, установщик VMware Workstation просто записывает файлы своих
компонентов в существующую основную файловую систему, не вмешиваясь в конфи-
гурацию оборудования (не требуя переформатирования диска, создания нового раз-
дела диска или внесения изменений в настройки BIOS). Фактически система VMware
Workstation может устанавливаться и приступать к запуску виртуальных машин, не
требуя никаких перезагрузок основной операционной системы, по крайней мере там,
где в ее роли выступает Linux.
Но обычное приложение не имеет необходимых методов, и для того, чтобы гипервизор
мультиплексировал ресурсы центрального процессора и памяти, нужны API-функции,
обеспечивающие близкий к обычному уровень производительности. В частности, рас-
смотренная ранее основа технологии виртуализации машин семейства x86 работает
только в том случае, если VMM запущен в режиме ядра и способен контролировать все
аспекты процессора без всяких ограничений, включая возможность изменять адресное
пространство (создавать теневые таблицы страниц), таблицы сегментов и все обработ-
чики прерываний и исключений.
У драйвера устройства имеется более прямой доступ к оборудованию, особенно если он
запущен в режиме ядра. Хотя он способен (теоретически) выдавать любые привилеги-
рованные инструкции, на практике от драйвера устройства ожидается взаимодействие
с его операционной системой с использованием четко определенных API-функций
при абсолютной невозможности произвольной переконфигурации оборудования.
А поскольку гипервизоры предназначены для основательной переконфигурации обо-
рудования (включая все адресное пространство, таблицы сегментов, обработчики ис-
ключений и прерываний), запуск гипервизора в виде драйвера устройства также был
нереальным вариантом.
Поскольку основными операционными системами ни одно из этих предположений не
поддерживается, запуск гипервизора как драйвера устройства (в режиме ядра) также
не подходил.
Эти строгие требования привели к разработке размещаемой архитектуры — VMware
Hosted Architecture. В ней программное обеспечение разбито на три отдельных явно
выраженных компонента (рис. 7.8).
Каждый из этих компонентов выполняет различные функции и работает независимо
от других компонентов:
Программа, запускаемая в пространстве пользователя (VMX), которую поль-
зователь воспринимает как программу VMware. VMX выполняет все функции
пользовательского интерфейса, запускает виртуальную машину, а затем выполняет
основную часть эмуляции устройств (внешний интерфейс) и совершает обычные
системные вызовы основной операционной системы для взаимодействий во вну-
треннем интерфейсе. Обычно это один многопоточный VMX-процесс для каждой
виртуальной машины.
568
Глава 7. Виртуализация и облако
CPU
IDTR
write()
fs
scsi
(i)
(ii)
(iii)
(iv)
(v)
Âèðòóàëüíàÿ
ìàøèíà
Îñíîâíàÿ ÎÑ
Äèñê
Êîíòåêñò îñíîâíîé ÎÑ
Êîíòåêñò VMM
Ðåæèì ÿäðà
Ïîëüçîâàòåëüñêèé ðåæèì
VMM-
äðàéâåð
Ïåðåêëþ-
÷åíèå
ìèðîâ
VMM
VMX
Ëþáîé
ïðîöåññ
Îáðàáîò÷èê
ïðåðûâàíèé
Îáðàáîò÷èê
ïðåðûâàíèé
Рис. 7.8. VMware Hosted Architecture и три ее компонента: VMX, VMM-драйвер и VMM
Небольшой драйвер устройства, выполняемый в режиме ядра (VMX-драйвер),
устанавливаемый в основную операционную систему. Он используется в основном
для получения возможности запуска VMM путем временной приостановки всей
основной операционной системы. В операционную систему обычно во время на-
чальной загрузки устанавливается один VMX-драйвер.
VMM, включающий все программное обеспечение, необходимое для мультиплек-
сирования центрального процессора и памяти, в том числе обработчики исключе-
ний, обработчики перехватов и эмуляции, двоичный транслятор и модуль теневой
страничной организации памяти. VMM запускается в режиме ядра, но не работает
в контексте основной операционной системы. Иными словами, он не может на-
прямую полагаться на службы, предлагаемые основной операционной системой, но
он также не связан какими-либо правилами или соглашениями, декларируемыми
основной операционной системой. Для каждой виртуальной машины имеется один
экземпляр VMM, создаваемый при запуске виртуальной машины.
VMware Workstation выглядит так, будто запускается поверх существующей операци-
онной системы, и, фактически ее компонент VMX запускается как процесс этой опе-
рационной системы. Но VMM работает на системном уровне, имея полный контроль
над оборудованием и не испытывая никакой зависимости от основной операционной
системы. На рис. 7.8 показаны взаимоотношения между объектами: два контекста (ос-
новной операционной системы и VMM) являются равноправными по отношению друг
к другу, и у каждого есть компонент пользовательского уровня и компонент ядра. VMM
при запуске (в правой половине рисунка) проводит переконфигурацию оборудования,
обрабатывает все прерывания и исключения ввода-вывода и поэтому безопасным
способом временно удаляет основную операционную систему из своей виртуальной
памяти. Например, размещение таблицы прерываний настраивается внутри VMM
путем назначения регистру IDTR нового адреса. И наоборот, когда работает основная
7.12. Изучение конкретных примеров: VMWARE
569
операционная система (левая половина рисунка), VMM и его виртуальная машина
точно так же удаляются из ее виртуальной памяти.
Переход между этими двумя совершенно независимыми контекстами системного
уровня называется переключением миров (world switch). Самим названием подчерки-
вается, что во время переключения миров все касающееся программного обеспечения
изменяется в отличие от обычного переключения контекстов, реализуемого операци-
онной системой. На рис. 7.9 показана разница между двумя видами переключений.
Обычное переключение контекстов между процессами А и Б меняет местами пользо-
вательскую часть адресного пространства и регистры двух процессов, но ряд важных
системных ресурсов оставляет без изменений. Например, часть адресного пространства,
принадлежащая ядру, идентична для всех процессов, также не изменяются обработ-
чики исключений. В отличие от этого при переключении миров изменяется все: все
адресное пространство, все обработчики исключений, привилегированные регистры
и т. д. В частности, адресное пространство ядра основной операционной системы ото-
бражается только при работе в контексте основной операционной системы. После пере-
ключения миров в контекст VMM оно удаляется из адресного пространства целиком,
освобождая пространство для работы как VMM, так и виртуальной машины. Хотя это
может показаться довольно сложным процессом, его можно реализовать весьма эффек-
тивно и занять для его выполнения всего лишь 45 инструкций на языке машины x86.
Êîíòåêñò
îñíîâíîé
ÎÑ
Ïðîöåññ
À
Îáû÷íîå
ïåðåêëþ÷åíèå
êîíòåêñòà
Ïåðåêëþ÷åíèå
ìèðîâ VMwar
e
Êîíòåêñò
VMM
VMM
Kernel Address space
Ëèíåéíîå àäðåñíîå ïðîñòðàíñòâî
Ïðîöåññ
Á
À (ïîëüçîâàòåëüñêîå
ïðîñòðàíñòâî)
Àäðåñíîå
ïðîñòðàíñòâî ÿäðà
Á (ïîëüçîâàòåëüñêîå
ïðîñòðàíñòâî)
Âèðòóàëüíàÿ ìàøèíà
Àäðåñíîå ïðîñòðàíñòâî
ÿäðà (îñíîâíàÿ ÎÑ)
VMX (ïîëüçîâàòåëüñêîå
ïðîñòðàíñòâî)
Рис. 7.9. Разница между обычным переключением контекста и переключением миров
Внимательный читатель может удивиться: а как насчет адресного пространства ядра
гостевой операционной системы? Ответ простой: оно является частью адресного про-
странства виртуальной машины и присутствует при работе в контексте VMM. Поэтому
гостевая операционная система может использовать все адресное пространство, в част-
ности те же места в виртуальной памяти, что и основная операционная система. При
совпадении основной и гостевой операционных систем (например, обе Linux) именно
так все и происходит. Разумеется, все это «просто работает», потому что есть два неза-
висимых контекста и между ними происходит переключение миров.
Затем тот же внимательный читатель может вновь удивиться: а как насчет области
VMM, находящейся на верхушке адресного пространства? Как уже говорилось, это
пространство резервируется самим VMM, и эта часть адресного пространства не мо-
жет быть использована виртуальной машиной напрямую. К тому же эта небольшая
570
Глава 7. Виртуализация и облако
4-мегабайтная часть используется гостевой операционной системой крайне редко, так
как каждое обращение к ней должно быть отдельно эмулировано и влечет за собой за-
метные программные издержки.
Вернемся к рис. 7.8: на нем показаны различные этапы того, что происходит в случае
прерывания от диска, возникшего во время работы VMM (этап I). Разумеется, VMM не
может обработать прерывание, потому что у него нет драйвера устройства из внутрен-
него интерфейса. На следующем этапе (II) VMM осуществляет переключение миров
с возвращением основной операционной системы, а именно: код переключения миров
возвращает управление VMware-драйверу, который на этапе III эмулирует аналогичное
прерывание, выданное диском. Таким образом, на этапе IV обработчик прерывания, при-
надлежащий основной операционной системе, проходит всю свою логическую цепочку,
как будто прерывание от диска произошло во время работы VMware-драйвера (а не
VMM!). И наконец, на этапе V VMware-драйвер возвращает управление приложению
VMX. К этому моменту основная операционная система может сделать выбор в пользу
диспетчеризации другого процесса или же продолжить выполнение процесса VMware
VMX. При продолжении выполнения процесса VMX он после всего этого возобновит
работу виртуальной машины путем выдачи специального вызова в драйвер устройства,
который сгенерирует переключение миров для возвращения в контекст VMM. Как
видите, это весьма ловкий прием, скрывающий весь VMM и виртуальную машину от
основной операционной системы. А что более важно, он предоставляет VMM полную
свободу по перепрограммированию оборудования согласно его предпочтениям.
7.12.5. Развитие VMware Workstation
В те десять лет, что последовали за разработкой исходного VMware Virtual Machine
Monitor, технологические перспективы сильно изменились.
Архитектура, применяющая основную операционную систему, используется и по
сей день для таких самых последних интерактивных гипервизоров, как VMware
Workstation, VMware Player и VMware Fusion (продукт, предназначенный для основ-
ных операционных систем Apple OS X), и даже для продуктов компании VMware,
предназначенных для сотовых телефонов (Barr et al., 2010). Переключатель миров
и его способность отделять контекст основной операционной системы от контекста
VMM остался основным механизмом сегодняшних продуктов VMware, применяющих
основные операционные системы. Например, несмотря на то что с годами реализация
переключателя миров получила развитие, для поддержки 64-разрядных систем до
сих пор остается в силе основная идея полного разделения адресных пространств для
основной операционной системы и VMM.
В отличие от этого с появлением средств аппаратного содействия виртуализации
довольно резко изменился подход к виртуализации архитектуры x86. Аппаратные
средства содействия виртуализации, такие как Intel VT-x и AMD-v, были представ-
лены в двух фазах. Первая фаза, стартовавшая в 2005 году, была разработана с явной
целью обойтись либо без паравиртуализации, либо без двоичной трансляции (Uhlig
et al., 2005). Вторая фаза, стартовавшая в 2007 году, предоставляла аппаратную под-
держку в MMU в форме вложенных таблиц страниц. Тем самым исключалась необхо-
димость в обслуживании программным способом теневых таблиц страниц. Сегодня,
когда процессор поддерживает как виртуализацию, так и вложенные таблицы страниц,
гипервизоры VMware главным образом применяют подход, основанный на использо-
вании оборудования с перехватом и эмуляцией (в формулировке Попека и Голдберга
сорокалетней давности).