Добавлен: 29.10.2018
Просмотров: 48203
Скачиваний: 190
7.12. Изучение конкретных примеров: VMWARE
561
VMware Workstation является гипервизором второго типа, состоящим из различных
модулей. Одним из важных модулей является VMM, отвечающий за выполнение ин-
струкций виртуальной машины. Вторым важным модулем является VMX, который
взаимодействует с основной операционной системой.
Сначала в разделе будет рассмотрено, как VMM решает проблему неприспособлен-
ности x86-архитектуры к виртуализации. Затем будет дано описание стратегии, скон-
центрированной на операционной системе и используемой разработчиками в течение
всей стадии разработки. После этого будет рассмотрена конструкция платформы вир-
туального аппаратного обеспечения, которая берет на себя половину всех сложностей,
связанных с разнообразием периферийных устройств. И наконец, будет рассмотрена
роль в VMware Workstation основной операционной системы, в частности взаимодей-
ствие между компонентами VMM и VMX.
Виртуализация x86-й архитектуры
VMM запускает текущую виртуальную машину, позволяя ей двигаться дальше. VMM,
который создан для виртуализированной архитектуры, использует технологию, извест-
ную как перехват и эмуляция, для непосредственного выполнения последовательности
инструкций виртуальной машины, но безопасным образом, на оборудовании. При не-
возможности подобных действий одним из подходов было указание виртуализируемого
поднабора процессорной архитектуры и портирование гостевой операционной системы
на эту заново определенную платформу. Эта технология называется паравиртуализа-
цией (Barham et al., 2003; Whitaker et al., 2002) и требует модификации операционной
системы на уровне исходного кода. Точнее говоря, при паравиртуализации гостевая
операционная система модифицируется во избежание выполнения тех действий, ко-
торые не могут быть обработаны гипервизором. В VMware паравиртуализация была
невозможна из-за требований обеспечения совместимости и необходимости запуска
операционных систем, чей исходный код был недоступен, в частности Windows.
Нужно было воспользоваться альтернативным подходом и провести полную эмуляцию.
При этом инструкции виртуальных машин вместо непосредственного выполнения
на оборудовании эмулировались VMM. При этом можно было добиться достаточной
эффективности. Предыдущий опыт с машинным симулятором SimOS (Rosenblum et
al., 1997) показал, что использование таких технологий, как динамическая двоичная
трансляция, запущенных в виде программы, выполняемой в пользовательском режиме,
может ограничить издержки от полной эмуляции пятикратным замедлением. При всей
своей эффективности и несомненной пригодности в целях моделирования пятикратное
замедление было абсолютно неприемлемым и не могло соответствовать желаемым
требованиям производительности.
Решение данной проблемы было в сочетании двух основных идей. Во-первых, хотя
для виртуализации всей архитектуры x86 технология непосредственного выполнения
инструкций после их перехвата и эмуляции не всегда подходила, в отдельные моменты
ее можно было применить. В частности, она могла использоваться в ходе выполнения
тех прикладных программ, на долю которых приходится большая часть времени при
соответствующих рабочих нагрузках. Дело в том, что инструкции, чувствительные
к виртуализации, являются таковыми не всегда, а только при определенных обсто-
ятельствах. Например, инструкция POPF чувствительна к виртуализации, когда от
программного обеспечения ожидается возможность блокировки прерываний (напри-
мер, при запуске операционной системы), но она нечувствительна к виртуализации,
562
Глава 7. Виртуализация и облако
когда программное обеспечение не может заблокировать прерывания (что случается
при выполнении почти всех приложений на уровне пользователя).
На рис. 7.7 показаны модульные строительные блоки исходного монитора VMware
VMM. Видно, что он состоит из подсистемы непосредственного выполнения, подси-
стемы двоичной трансляции и алгоритма решения, определяющего, какая из подсистем
должна использоваться. Обе подсистемы зависят от ряда совместно используемых
модулей, например для виртуализации памяти посредством теневых таблиц страниц
или эмулирования устройств ввода-вывода.
VMM
Ñîâìåñòíî èñïîëüçóåìûå ìîäóëè
(òåíåâîé MMU, îáðàáîòêà ââîäà-âûâîäà è ò. ä.)
Íåïîñðåäñòâåííîå
âûïîëíåíèå
Äâîè÷íàÿ
òðàíñëÿöèÿ
Àëãîðèòì
ðåøåíèÿ
Рис. 7.7. Высокоуровневые компоненты монитора виртуальных машин VMware
(за исключением аппаратной поддержки)
Предпочтительнее, конечно, использование подсистемы непосредственного выпол-
нения, а подсистема динамической двоичной трансляции предоставляет резервный
механизм, когда непосредственное выполнение невозможно. Такой случай представля-
ется, к примеру, когда виртуальная машина находится в таком состоянии, при котором
она может выдать чувствительную к виртуализации (служебную) инструкцию. Таким
образом, каждая подсистема постоянно переоценивает алгоритм решения, чтобы опре-
делить возможность переключения подсистем (с двоичной трансляции на непосред-
ственное выполнение) или необходимость такого переключения (с непосредственного
выполнения на двоичную трансляцию). Этот алгоритм имеет ряд входных параметров,
таких как текущее кольцо выполнения виртуальной машины, возможность включения
прерываний на этом уровне и состояние сегментов. Например, двоичная трансляция
должна использоваться при возникновении следующих обстоятельств:
виртуальная машина в данный момент запущена в режиме ядра (кольцо 0 в архи-
тектуре x86);
виртуальная машина может заблокировать прерывания и выдать инструкции вво-
да-вывода (в архитектуре x86, когда уровень привилегий ввода-вывода установлен
на уровне кольца);
виртуальная машина в данный момент запущена в реальном режиме, кроме всего
прочего, для BIOS используется устаревший 16-разрядный режим выполнения.
Фактический алгоритм решения содержит несколько дополнительных условий. Под-
робности можно найти в работе Bugnion et al. (2012). Интересно, что алгоритм не
зависит от инструкций, которые сохранены в памяти и могут быть выполнены, он за-
висит только от значения нескольких виртуальных регистров, таким образом, он весьма
эффективно может быть вычислен всего лишь за несколько инструкций.
7.12. Изучение конкретных примеров: VMWARE
563
Второй ключ к пониманию заключался в том, что при надлежащей конфигурации
оборудования, особенно при осмотрительном использовании имеющегося в x86 ме-
ханизма защиты сегментов, системный код при динамической двоичной трансляции
также может выполняться на близких к исходным скоростях. Это сильно отличается
от пятикратного замедления, обычно ожидаемого от машинных симуляторов.
Разницу можно объяснить путем сравнения того, как динамическая двоичная транс-
ляция преобразует простую инструкцию обращения к памяти. Чтобы эмулировать
эту инструкцию в программе, классическому двоичному транслятору, эмулирующему
полный набор инструкций архитектуры x86, придется сначала проверить, попадает ли
эффективный адрес в диапазон сегмента данных, затем преобразовать адрес в физиче-
ский адрес и, наконец, скопировать слово, на которое была ссылка, в симулируемый
регистр. Разумеется, все эти действия могут быть оптимизированы путем кэширования
способом, весьма похожим на тот, которым процессор кэширует отображение в табли-
цах страниц в буфере ассоциативной трансляции. Но даже такая оптимизация приведет
к расширению отдельных инструкций в последовательность инструкций.
Двоичный транслятор в программах подобных действий не совершает. Вместо этого
он конфигурирует оборудование таким образом, чтобы эти простые инструкции могли
быть заново выданы в виде идентичных инструкций. Это возможно только потому, что
VMware VMM (компонентом которого является двоичный транслятор) имеет заранее
настроенное под конкретную спецификацию виртуальной машины оборудование:
VMM использует теневые таблицы страниц, гарантирующие, что блок управления
памятью может использоваться напрямую (а не эмулироваться);
VMM использует такой же подход с теневыми таблицами для таблиц дескрипторов
сегментов (играющих большую роль в 16- и 32-разрядном программном обеспече-
нии на более старых операционных системах для x86).
Разумеется, без сложностей и тонкостей не обошлось. Одним из важных аспектов
конструкции является обеспечение целостности в песочнице виртуализации, то есть
обеспечение того, что никакая программа, запущенная внутри виртуальной машины
(включая и вредоносную программу), не сможет вмешиваться в работу VMM. Эта
проблема обычно называется изоляцией сбоя программы и, если решение реализовано
в программе, добавляет к каждому обращению к памяти издержки времени выполнения.
Здесь также VMware VMM использует другой, основанный на оборудовании подход. Он
разбивает адресное пространство на две разделенные зоны. Верхние 4 Мбайт адресного
пространства VMM резервирует под собственные нужды. Тем самым для использова-
ния виртуальной машиной освобождается все остальное пространство (то есть 4 Гбайт
– 4 Мбайт, если речь идет о 32-разрядной архитектуре). Затем VMM конфигурирует
аппаратную часть, занимающуюся сегментацией, таким образом, чтобы никакие инструк-
ции виртуальной машины (включая и те, что сгенерированы двоичным транслятором)
никогда не получали доступ к верхней 4-мегабайтной области адресного пространства.
Стратегия, сконцентрированная на гостевой операционной системе
В идеале VMM должна быть разработана так, чтобы не приходилось беспокоиться за
запущенную на виртуальной машине гостевую операционную систему или за то, как
эта система конфигурирует оборудование. Идея, положенная в основу виртуализации,
заключается в создании интерфейса виртуальной машины, идентичного аппаратному
интерфейсу, чтобы все программное обеспечение, запускаемое непосредственно на
564
Глава 7. Виртуализация и облако
оборудовании, могло запускаться также на виртуальной машине. К сожалению, этот
подход реализуем на практике только при наличии виртуализируемой и простой архи-
тектуры. В случае с x86 явной проблемой стала чрезвычайная сложность архитектуры.
Инженеры VMware упростили эту проблему, сфокусировавшись только на выборе под-
держиваемых гостевых операционных систем. В первом выпуске VMware Workstation
официально в качестве гостевых операционных систем поддерживались только Linux,
Windows 3.1, Windows 95/98 и Windows NT. С годами с каждым пересмотром про-
граммного обеспечения к списку добавлялись новые операционные системы. Тем не
менее эмуляция была вполне подходящей для запуска некоторых весьма неожиданных
операционных систем, например MINIX 3, причем взятой прямо из коробки.
Такое упрощение не изменило общую конструкцию — VMM по-прежнему обеспечивал
точную копию основного оборудования, но это помогло направить процесс разработки
в нужное русло. В частности, инженерам пришлось позаботиться только о сочетаниях
тех свойств, которые реально использовались поддерживаемыми операционными
системами.
Например, архитектура x86 в защищенном режиме содержит четыре кольца при-
вилегий (от 0 до 3), но ни одна из операционных систем практически не использует
кольца 1 и 2 (за исключением давно изжившей себя операционной системы OS/2 от
IBM). Следовательно, вместо того чтобы выяснять, как правильно виртуализировать
кольца 1 и 2, VMware VMM просто содержит код для обнаружения попыток вхож-
дения гостевой операционной системы в кольцо 1 или 2, и в таком случае монитор
прекращает выполнение кода виртуальной машины. Таким образом не только был
удален ненужный код, но, что более важно, VMware VMM получил возможность
полагать, что кольца 1 и 2 никогда не будут использоваться виртуальной машиной,
поэтому монитор может воспользоваться ими для собственных нужд. Фактически
для виртуализации кода в кольце 0 входящий в состав VMware VMM двоичный
транслятор работает в кольце 1.
Платформа виртуального оборудования
До сих пор разговор в основном шел о проблеме, связанной с виртуализацией про-
цессора x86. Но компьютер на основе семейства x86 состоит не только из процессора.
В нем имеются также микропроцессорный набор, ряд прошивок и набор периферий-
ных устройств ввода-вывода для управления дисками, сетевыми картами, приводами
компакт-дисков, клавиатурой и т. д.
Большое разнообразие периферийных устройств ввода-вывода в персональных ком-
пьютерах x86 сделало невозможным соответствие виртуального оборудования реаль-
ному, основному оборудованию. В то время как моделей процессоров на рынке было
не много и их возможности на уровне набора инструкций имели незначительные
вариации, устройств ввода-вывода было несколько тысяч и большинство из них не
имело общедоступной документации на интерфейс или функциональные возмож-
ности. Основным замыслом специалистов VMware был не отказ от попытки добиться
соответствия виртуального оборудования конкретному основному оборудованию,
а достижение постоянного соответствия определенной конфигурации, составленной
из отобранных канонических устройств ввода-вывода. Затем гостевые операционные
системы использовали собственные встроенные механизмы для обнаружения и работы
с этими (виртуальными) устройствами.
7.12. Изучение конкретных примеров: VMWARE
565
Платформа виртуализации состояла из комбинации мультиплексированных и эмули-
рованных компонентов. Мультиплексирование означало конфигурирование оборудо-
вания таким образом, чтобы оно могло непосредственно использоваться виртуальной
машиной и совместно использоваться (в пространстве или времени) несколькими
виртуальными машинами. Эмулирование означало экспортирование программной си-
муляции отобранных канонических компонентов оборудования виртуальной машине.
В табл. 7.2 показано, что в VMware Workstation мультиплексирование использовалось
для процессора и памяти, а эмулирование — для всего остального.
Таблица 7.2. Варианты конфигурации виртуального оборудования, характерные
для раннего образца VMware Workstation, ca. 2000
Оборудова-
ние
Виртуальное оборудова-
ние (внешний интерфейс)
Внутренний интерфейс
Мультиплек-
сированное
Один виртуальный централь-
ный процессор x86 CPU с од-
ними и теми же расширени-
ями набора инструкций, что
и у центрального процессора
основного оборудования
Работа регламентировалась основной опера-
ционной системой либо на однопроцессорной,
либо на мультипроцессорной хост-машине
До 512 Мбайт непрерывной
динамической оперативной
памяти
Распределялась и управлялась основной опе-
рационной системой (постранично)
Эмулирован-
ное
Шина PCI Bus
Полностью эмулируемая совместимая PCI bus
4x IDE-диска
7x Buslogic SCSI-диска
Виртуальные диски (хранящиеся в виде фай-
лов) или непосредственный доступ к заданно-
му простому устройству
1x IDE-привод компакт-дис-
ков
ISO-образ или эмулируемый доступ к реально-
му компакт-диску
2x 1,44-мегабайтного приво-
да гибких дисков
Физический привод гибких дисков или образ
гибкого диска
1x VMware графическая карта
с поддержкой VGA и SVGA
Запускалась в окне и в полноэкранном режи-
ме. Для SVGA требовался гостевой драйвер
VMware SVGA
2x последовательных порта
COM1 и COM2
Подключались к последовательному порту
хост-машины или к файлу
1x принтер (LPT)
Мог подключаться к LPT-порту хост-машины
1x клавиатура (104 клавиши)
Полностью эмулировалась; события кода
клавиши генерировались после их получения
приложением VMware
1x мышь PS-2
Аналогично клавиатуре
3x Ethernet-карты AMD Lance
Режим моста и режимы только для хост-
машины
1x Soundblaster (звуковая
карта)
Полностью эмулировалась