Добавлен: 29.10.2018
Просмотров: 48204
Скачиваний: 190
7.2. Требования, применяемые к виртуализации
531
2. Эквивалентность — поведение программы на виртуальной машине должно быть
идентичным поведению этой же программы, запущенной на реальном оборудо-
вании.
3. Эффективность — основная часть кода в виртуальной машине должна выполнять-
ся без вмешательства гипервизора.
Несомненно, безопасный способ выполнения инструкций заключается в поочередном
рассмотрении каждой инструкции в интерпретаторе (например, в Bochs) и в выпол-
нении именно того, что нужно для данной инструкции. Некоторые инструкции могут
быть выполнены напрямую, но их не много. Например, интерпретатор может быть
способен выполнить инструкцию INC (инкремент) просто как есть, но инструкции, ко-
торые небезопасно выполнять напрямую, должны быть эмулированы интерпретатором.
Например, нельзя разрешать гостевой операционной системе блокировать прерывания
для всей машины или модифицировать отображения страниц в таблицах. Нужно при-
менить прием, заставляющий операционную систему, посаженную поверх гипервизора,
полагать, что она заблокировала прерывания или изменила отображение страниц на
машине. Позже будет показано, как это делается. А сейчас хочется лишь сказать, что
интерпретатор может быть безопасным и при тщательной реализации, возможно, даже
высококачественным, но производительность его может оказаться не на высоте. Далее
будет показано, что для того, чтобы соответствовать также критериям производитель-
ности, мониторы виртуальных машин (VMM) стараются выполнить основную часть
кода непосредственным образом.
Теперь обратимся к точности. Виртуализация долгое время была проблемой для архи-
тектуры x86 из-за дефектов в архитектуре Intel 386, которые упорно в течение 20 лет
переносились на новые центральные процессоры во имя обратной совместимости.
В двух словах, каждый центральный процессор с режимом ядра и пользовательским
режимом имеет набор инструкций, ведущих себя по-разному в зависимости от того,
в каком режиме они выполняются, в режиме ядра или в пользовательском режиме.
В их число входят инструкции, осуществляющие ввод-вывод, изменяющие настройки
блока управления памятью (MMU) и т. д. Попек и Голдберг назвали их служебными
инструкциями
(sensitive instructions), или инструкциями, чувствительными к виртуа-
лизации. Есть также набор инструкций, которые при выполнении в пользовательском
режиме вызывают системные прерывания. Попек и Голдберг назвали их привилегиро-
ванными инструкциями
(privileged instructions). В статье этих специалистов впервые
утверждалось, что машина может быть подвергнута виртуализации, только если слу-
жебные инструкции являются поднабором привилегированных инструкций. Проще
говоря, при попытке сделать в пользовательском режиме то, что вы не должны делать
в этом режиме, оборудование должно вызвать системное прерывание. В отличие от
IBM/370, обладающей эти свойством, у Intel 386 его нет. При выполнении в поль-
зовательском режиме будут проигнорированы или выполнены по-другому многие
служебные инструкции 386-е машины. Например, инструкция POPF заменяет регистр
флагов, который изменяет бит, благодаря которому блокируются и разблокируются
прерывания. В пользовательском режиме этот бит просто не изменяется. Вследствие
этого 386-е машины и их преемники не могли быть виртуализированы, следовательно,
они не могли поддерживать гипервизор напрямую.
На самом деле ситуация была еще хуже, чем в этом кратком обзоре. Вдобавок к про-
блемам с инструкциями, которые, выполняясь в пользовательском режиме, вызывали
системные прерывания, были еще и инструкции, которые могли считывать конфиден-
532
Глава 7. Виртуализация и облако
циальное состояние, не вызывая системных прерываний. Например, на процессорах
x86 выпуска до 2005 года программа путем чтения селектора своего кодового сегмента
могла определять, в каком режиме она выполняется, в пользовательском или в режиме
ядра. Операционная система, выполнявшая такое действие и позволявшая обнаружи-
вать, что она в данный момент находится в пользовательском режиме, могла на основе
этой информации принимать неправильные решения.
Эта проблема была окончательно решена, когда в начале 2005 года Intel и AMD пред-
ставили виртуализацию на своих центральных процессорах (Uhlig, 2005). На цен-
тральных процессорах Intel она называлась технологией виртуализации (Virtualization
Technology (VT)), а на центральных процессорах AMD она называлась безопасной
виртуальной машиной
(Secure Virtual Machine (SVM)). Далее в общем смысле будет
использоваться термин VT. Обе технологии были вдохновлены примером работы IBM
VM/370, но при этом имеют от нее небольшие отличия. Основной замысел заключался
в создании контейнеров, в которых могли бы запускаться виртуальные машины. При
запуске в контейнере гостевой операционной системы она продолжает работать в нем,
пока ею не будет вызвано исключение и не будет осуществлено системное прерывание
в гипервизоре, например, при выполнении инструкции ввода-вывода. Набор операций,
вызывающих это системное прерывание, контролируется битовым массивом, уста-
навливаемым гипервизором. С таким расширением появилась возможность создания
классической виртуальной машины, работающей по принципу вызова системного
прерывания и эмуляции.
Дотошный читатель, наверное, заметил явное противоречие в предложенном до сих
пор описании. С одной стороны, было сказано, что x86-машины не могли быть вир-
туализированы вплоть до появления архитектурного расширения, представленного
в 2005 году, а с другой — было сказано, что VMware запустила свой первый гиперви-
зор на x86 в 1999 году. Как все это вместе может быть правдой? Ответ заключается
в том, что гипервизоры до 2005 года фактически не запускали настоящие гостевые
операционные системы. Вместо этого они переписывали часть кода на лету, заменяя
проблемные инструкции безопасной кодовой последовательностью, эмулирующей
исходную инструкцию. Предположим, к примеру, что гостевая операционная система
выполняет привилегированную инструкцию ввода-вывода или модифицирует один
из привилегированных управляющих регистров центрального процессора (например,
регистр CR3, содержащий указатель на каталог страниц). Важно, чтобы последствия
выполнения таких инструкций ограничивались данной виртуальной машиной и не
оказывали влияния на другие виртуальные машины или на сам гипервизор. Таким об-
разом, небезопасные инструкции ввода-вывода заменялись системным прерыванием,
которое после проверки безопасности выполняло эквивалентную инструкцию и воз-
вращало результат. Поскольку происходила перезапись, этим трюком можно было
воспользоваться для замены инструкций, являвшихся служебными, но не входивших
в число привилегированных. Все остальные инструкции выполнялись обычным по-
рядком. Эта технология известна как двоичная трансляция и более подробно будет
рассмотрена в разделе 7.4.
Переписывать абсолютно все служебные инструкции нет необходимости. В част-
ности, пользовательские процессы на гостевой операционной системе могут, как
правило, выполняться без модификации. Если инструкция не входит в число при-
вилегированных, но относится к служебным и ведет себя в пользовательских про-
цессах не так, как в процессах ядра, то все нормально. Она все равно запускается
7.3. Гипервизоры первого и второго типа
533
в пользовательской среде. Что же касается служебных инструкций, входящих в состав
привилегированных, то можно, как обычно, прибегнуть к классической схеме с си-
стемным прерыванием и эмуляцией. Разумеется, VMM должен обеспечить получение
соответствующих системных прерываний. Обычно в VMM имеется модуль, выпол-
няемый в ядре и перенаправляющий системные прерывания к своим собственным
обработчикам.
Другая форма виртуализации известна как паравиртуализация. Она сильно отли-
чается от полной виртуализации, поскольку никогда даже не стремится представить
виртуальную машину, которая бы выглядела как настоящее основное оборудование.
Вместо этого она представляет машиноподобный программный интерфейс, который
явно раскрывает факт наличия виртуальной среды. Например, он предлагает набор
гипервызовов
(hypercall), позволяющих гостю отправлять явные запросы к гипер-
визору (во многом это похоже на то, как системный вызов предлагает службы ядра
приложениям). Гостевые системы используют гипервызовы для привилегированных
служебных операций, таких как обновление таблиц страниц, но поскольку они делают
это явным образом во взаимодействии с гипервизором, в целом система может полу-
чаться проще и быстрее.
Наверное, то, что в паравиртуализации нет ничего нового, уже не вызовет у вас удив-
ления. Разработанная IBM операционная система VM уже предлагала такую возмож-
ность, правда, под другим именем, еще с 1972 года. Идея была возрождена в мони-
торах виртуальных машин Denali (Whitaker et al., 2002) и Xen (Barham et al., 2003).
По сравнению с полной виртуализацией, недостатком паравиртуализации является
то, что гостевая система должна знать о существовании API виртуальной машины.
Как правило, это означает, что она должна быть специально настроена под гипервизор.
Перед тем как еще больше углубиться в рассмотрение гипервизоров первого и второ-
го типов, важно отметить, что не все технологии виртуализации пытаются обмануть
гостевую систему, заставляя ее поверить в обладание всей системой. Иногда цель
заключается в простом разрешении запуска процесса, изначально написанного для
другой операционной системы и/или архитектуры. Поэтому нужно различать полную
систему виртуализации и виртуализацию на уровне процесса. Хотя далее в главе
основное внимание будет уделено первой из них, практикуется также и технология
виртуализации на уровне процесса. К широко известным примерам можно отнести
уровень совместимости WINE, который позволяет приложениям Windows запускаться
на POSIX-совместимых системах, таких как Linux, BSD и OS X, и версию эмулятора
QEMU на уровне процесса, которая позволяет приложениям для одной архитектуры
выполняться на оборудовании с другой архитектурой.
7.3. Гипервизоры первого и второго типа
В работе Goldberg (1972) различаются два подхода к виртуализации. Одна разновид-
ность гипервизора, названная гипервизором первого типа (type 1 hypervisor), показана
на рис. 7.1, а. Технически этот гипервизор похож на операционную систему, поскольку
это единственная программа, запущенная в самом привилегированном режиме. Его
работа заключается в поддержке нескольких копий имеющегося оборудования, которое
называется виртуальными машинами, что похоже на выполнение процессов в обычной
операционной системе.
534
Глава 7. Виртуализация и облако
В отличие от этого гипервизор второго типа, показанный на рис. 7.1, б, относится к дру-
гой разновидности программ. Это программа, которая при распределении и планирова-
нии использования ресурсов опирается, скажем, на Windows или Linux и очень похожа
на обычный процесс. Разумеется, гипервизор второго типа к тому же притворяется
полноценным компьютером с центральным процессором и различными устройствами.
Оба типа гипервизоров должны выполнять набор машинных инструкций безопасным
образом. Например, операционная система, запущенная поверх гипервизора, может
изменять и даже портить собственные таблицы страниц, но не те таблицы, которые
принадлежат другим системам.
Операционная система, запущенная поверх гипервизора, в обоих случаях называется
гостевой операционной системой
(guest operating system). В гипервизоре второго типа
операционная система, которая запущена на оборудовании, называется основной опе-
рационной системой
(host operating system) или хост-системой. Первым гипервизором
второго типа на рынке x86 был VMware Workstation (Bugnion et al., 2012). В этом
разделе будет представлен общий замысел, положенный в ее основу, а исследовать
VMware предстоит в разделе 7.12.
Ãèïåðâèçîð ïåðâîãî òèïà
Îáîðóäîâàíèå
(öåíòðàëüíûé ïðîöåññîð, äèñê, ñåòåâîå
îáîðóäîâàíèå, ìåõàíèçì ïðåðûâàíèé è ò. ä.)
Îñíîâíàÿ îïåðàöèîííàÿ
ñèñòåìà (íàïðèìåð, Linux)
Îáëàñòü
óïðàâ-
ëåíèÿ
Linux
Windows
Excel W
ord
Mplayer Emacs
Ãèïåðâèçîð
âòîðîãî òèïà
Ãîñòåâàÿ îïåðàöè-
îííàÿ ñèñòåìà (íà-
ïðèìåð, Windows)
Ïðîöåññ ãîñòåâîé
îïåðàöèîííîé ñèñòåìû
Ïðîöåññ îñíîâíîé
îïåðàöèîííîé ñèñòåìû
(öåíòðàëüíûé ïðîöåññîð, äèñê, ñåòåâîå
îáîðóäîâàíèå, ìåõàíèçì ïðåðûâàíèé è ò. ä.)
Îáîðóäîâàíèå
Рис. 7.1. Расположение гипервизоров: а — первого и б — второго типа
Многие функциональные возможности гипервизоров второго типа, которые иногда
называют гипервизорами, интегрированными с хост-системой (hosted hypervisors),
зависят от основной операционной системы, например от Windows, Linux или OS X.
При первом запуске они ведут себя как только что загруженный компьютер и рассчи-
тывают найти DVD, USB-накопитель или компакт-диск, содержащий операционную
систему. Но в данном случае приводом может быть виртуальное устройство. Например,
образ может быть сохранен как ISO-файл на жестком диске хост-системы, и гипервизор
притворится, что чтение идет с надлежащего DVD-привода. Затем он устанавливает
операционную систему на свой виртуальный диск (который в реальности опять являет-
ся файлом Windows, Linux или OS X) путем запуска программы установки, найденной
на DVD. После установки гостевой операционной системы на виртуальный диск ее
можно будет загрузить и запустить.
Различные категории виртуализации для гипервизоров как первого, так и второго типа,
о которых уже говорилось, сведены в табл. 7.1. Для каждой комбинации гипервизора
и разновидности виртуализации приведены примеры.
7.4. Технологии эффективной виртуализации
535
Таблица 7.1. Примеры гипервизоров. Гипервизоры первого типа работают непо-
средственно на оборудовании, а гипервизоры второго типа используют службы
существующей основной операционной системы
Метод виртуализации
Гипервизор
первого типа
второго типа
Виртуализация без поддерж-
ки оборудования
ESX Server 1.0
VMware Workstation 1
Паравиртуализация
Xen 1.0
—
Виртуализация с поддержкой
оборудования
vSphere, Xen, Hyper-V
VMware Fusion, KVM, Parallels
Виртуализация на уровне
процесса
—
Wine
7.4. Технологии эффективной виртуализации
Способность к виртуализации и производительность являются весьма важными во-
просами, поэтому давайте их исследуем более подробно. Предположим, что в данный
момент у нас есть гипервизор первого типа, поддерживающий одну виртуальную
машину (рис. 7.2). Как и все другие гипервизоры первого типа, он работает непо-
средственно на оборудовании. Виртуальная машина запущена как пользовательский
процесс в пользовательском режиме, и как таковой ей нельзя выполнять служебные
инструкции (в толковании Попека — Голдберга). Но на виртуальной машине работа-
ет гостевая операционная система, которая считает, что она запущена в режиме ядра
(хотя, разумеется, это не так). Мы назовем это виртуальным режимом ядра (virtual
kernel mode). На виртуальной машине также запущены пользовательские процессы,
которые считают, что они выполняются в пользовательском режиме (и действительно
находятся в этом режиме).
Ãèïåðâèçîð ïåðâîãî òèïà
Âèðòóàëüíàÿ
ìàøèíà
Ãîñòåâàÿ îïåðàöèîííàÿ
ñèñòåìà
Ðåæèì âèðòóàëüíîãî
ÿäðà
Âèðòóàëüíûé
ïîëüçîâàòåëüñêèé
ïðîöåññ
Îáîðóäîâàíèå
Ïåðåäà÷à óïðàâëåíèÿ
íà ïðèâèëåãèðîâàííîé
èíñòðóêöèè
Ïîëüçîâàòåëüñêèé ïðîöåññ
Ðåæèì
ÿäðà
Ïîëüçîâà-
òåëüñêèé
ðåæèì
Рис. 7.2. Когда операционная система в виртуальной машине выполняет инструкцию, предна-
значенную только для режима ядра, при наличии технологии виртуализации она подвергается
системному прерыванию и передает управление гипервизору
Что произойдет, когда гостевая операционная система (которая считает, что выполня-
ется в режиме ядра) выполняет инструкцию, разрешенную, лишь когда центральный
процессор реально работает в режиме ядра? Обычно на центральных процессорах без