 |
|
|
|
Виртуализация на платформе x86
Виртуализация на платформе x86 Одновременным запуском Windows и Linux на одной машине уже никого не удивишь. Разберемся, как работают эти технологии, ставшие такими привычными Сегодня вряд ли можно найти человека, относящегося к миру ИТ, но не знающего про виртуализацию – возможность запускать несколько ОС на одной физической машине так, что они не подозревают о существовании друг друга. Большинство пользователей ПК познакомились с этой технологией в конце 90-х годов прошлого века, когда компания VMware представила свои продукты для создания виртуальных машин в ОС Windows. С тех пор в сфере виртуализации для платформы x86 произошли фундаментальные изменения, и сегодня эта технология является основой облачных сервисов. Но как же устроены виртуальные машины? Знакомися с теорией и историей вопроса. Предыстория Начнем с того, что идея использовать одну физическую машину для параллельной работы нескольких ОС возникла гораздо раньше не только Windows, но и вообще персональных компьютеров. Первые промышленные реализации виртуальных машин были представлены в 60-х годах прошлого века инженерами IBM для платформ System/360 и 370. Эти реализации основывались на аппаратном разграничении привилегий: каждый процесс, выполняемый на машине, работает на определенном уровне, в зависимости от которого ему разрешается либо запрещается выполнение тех или иных инструкций. При попытке выполнить недопустимую для данного уровня инструкцию генерируется аппаратное исключение, которое может быть перехвачено и обработано программами с более высоким уровнем привилегий. В предложенной инженерами IBM классической схеме виртуализации, получившей название «Trap and Emulate» («лови и эмулируй»), виртуализируемые ОС (следуя современной терминологии, будем называть их «гостевыми») запускаются на одном из непривилегированных уровней, а на уровень снаивысшими привилегиями помещается специальная программа – монитор виртуальных машин (ВМ) или гипервизор. Если гостевая ОС вызывает непривилегированную инструкцию, никаких препятствий не возникает, и эта инструкция обрабатывается непосредственно аппаратурой. Попытка же выполнить привилегированную инструкцию приводит каппаратному исключению. Это исключение перехватывается гипервизором, который эмулирует выполнение инструкции для конкретной ВМ. Фактически гипервизор выполняет для гостевых ОС ту же роль, что сами ОС выполняют для работающих внутри них процессов. В частности, ему необходимо обеспечивать взаимодействие с различными устройствами, ведь нескольким гостевым системам нужно как-то разделять физические устройства (клавиатуру, монитор, принтер и так далее), и диспетчером в тут и выступает гипервизор. В зависимости от реализации виртуальным машинам может предоставляться либо эмуляция устройств, либо доступ к реальному «железу». Набор инструкций для эмуляции определяется аппаратной архитектурой платформы. В случае мейнфреймов IBM доля инструкций, которые необходимо эмулировать при реальной работе, была мала, поэтому производительность гипервизоров достаточно высока. Как результат, еще в 70-х годах прошлого века на основе этих мейнфреймов строились структуры, архитектурно очень похожие на нынешние облачные сервисы. На одном мейнфрейме можно было принеобходимости запускать несколько полностью независимых виртуальных машин для решения прикладных задач. У классической схемы виртуализации есть одна тонкость – чтобы ее можно было реализовать на конкретной аппаратуре, все инструкции процессора, которые могут изменить состояние ресурсов машины, должны быть привилегированными. Также не должно быть инструкций, которые ведут себя по-разному в зависимости от состояния этих ресурсов (например, различных системных регистров). В частности, не должно быть инструкций, которые работают по-разному на разных уровнях привилегий, не вызывая аппаратных исключений. В более формальном виде требования к платформе, необходимые для создания на ней эффективного гипервизора, были впервые сформулированы разработчиками систем виртуализации IBM и по их именам получили название критерия Попека – Голдберга. Эти требования достаточно очевидны, однако для многих реальных процессоров они не выполняются, особенно если разработчики последних не предполагают, что их изделия будут использоваться для развертывания виртуальных сред. Вчисло таких процессоров попали Intel 8086 и все его потомки, выпущенные в течение почти 27 лет после его появления – до реализации аппаратной поддержки виртуализации. Более того, со временем создание виртуальных машин дляархитектуры Intel x86 только затруднялось, в частности, после внедрения режима DMA, позволяющего работать с устройствами в обход процессора. Долгое время процессоры архитектуры x86 действительно использовались только в персональных компьютерах, но Intel все активнее проявлял себя на рынке серверов, где виртуализация очень даже востребована. Создать классический гипервизор на платформе x86 было невозможно, но ведь не обязательно следовать уже известной модели. Не дожидаясь помощи от производителей процессоров, сторонние разработчики предложили альтернативные варианты запуска ВМ, обходящие ограничения аппаратуры. Далее мы расскажем о наиболее популярных походах, а также о том, какую помощь разработчики виртуализированных сред получили в конце концов от производителей процессоров. Но прежде – более подробная информация о том, чем плоха изначальная архитектура x86 с точки зрения виртуализации. Статью целиком читайте в журнале «Системный администратор», №10 за 2013 г. на страницах 80-84. |
ДЕНИС СИЛАКОВ, к. ф.-м. н., член рабочей группы LSB, старший архитектор ЗАО «РОСА», занимается автоматизацией разработки ОС «РОСА»Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
