Гипервизор — Википедия

Материал из Википедии — свободной энциклопедии

Текущая версия страницы пока не проверялась опытными участниками и может значительно отличаться от версии, проверенной 3 декабря 2015; проверки требуют 17 правок. Текущая версия страницы пока не проверялась опытными участниками и может значительно отличаться от версии, проверенной 3 декабря 2015; проверки требуют 17 правок.

Гиперви́зор (англ. Hypervisor; от др.-греч. ὑπέρ «над, выше, сверх» + лат. vīsio «зрение; видение») или монито́р виртуа́льных маши́н (в компьютерах) — программа или аппаратная схема, обеспечивающая или позволяющая одновременное, параллельное выполнение нескольких операционных систем на одном и том же хост-компьютере. Гипервизор также обеспечивает изоляцию операционных систем друг от друга, защиту и безопасность, разделение ресурсов между различными запущенными ОС и управление ресурсами.

Гипервизор также обязан предоставлять работающим под его управлением на одном хост-компьютере ОС средства связи и взаимодействия между собой (например, через обмен файлами или сетевые соединения) так, как если бы эти ОС выполнялись на разных физических компьютерах.

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

Автономный гипервизор (Тип 1, X)[править | править код]

Имеет свои встроенные драйверы устройств, модели драйверов и планировщик и поэтому не зависит от базовой ОС. Так как автономный гипервизор работает непосредственно в окружении усечённого ядра, то он более производителен, но проигрывает в производительности виртуализации на уровне ОС и паравиртуализации. Например, кроссплатформенный гипервизор Xen может запускать виртуальные машины в паравиртуальном режиме (зависит от ОС).

Примеры: VMware ESX, Citrix XenServer.

На основе базовой ОС (Тип 2, V)[править | править код]

Это компонент, работающий в одном кольце с ядром основной ОС (кольцо 0). Гостевой код может выполняться прямо на физическом процессоре, но доступ к устройствам ввода-вывода компьютера из гостевой ОС осуществляется через второй компонент, обычный процесс основной ОС — монитор уровня пользователя.

Примеры: Microsoft Virtual PC, VMware Workstation, QEMU, Parallels, VirtualBox.

Гибридный (Тип 1+)[править | править код]

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

Примеры: Microsoft Virtual Server, Sun Logical Domains, Xen, Citrix XenServer, Microsoft Hyper-V, VMware Workstation.

Самый используемый гипервизор? Xen / Habr

СТОП! Стоп-стоп-стоп. Понимаю ваше возмущение. Я знаю, что вы уже готовы кричать о том, что я некомпетентный идиот, если написал такое в заголовке. Заголовок, действительно, провокационный, но давайте разберемся.

Итак. О чем вы мне хотели сказать? Большинство из вас, вероятно, хотело мне сообщить, что VMware – доминирующая система виртуализации для предприятий. Возможно, кто-то, кто связан с компаниями, вся инфраструктура которых построена на решениях Microsoft, готов убеждать меня в том, что популярность Hyper-V сравнима, или даже в каких-то случаях превосходит VMware. И обязательно найдутся те, кто вспомнит, что в телекоме, хостинге и OpenStack-решениях, как правило, используют KVM.

Другими словами, всё зависит от того, как считать. Если по доле корпоративного рынка (получаемой прибыли), то лидером будет VMware. Если по … назовем это «охватом экосистемы», то Hyper-V, если по темпам роста использования, то KVM. Но я хочу сравнить по количеству виртуальных машин, работающих на гипервизорах. В мировом масштабе, конечно.

Как оценить количество виртуальных машин во всем мире и ИТ-инфраструктуру, в которой они работают? Будем исходить из того, что самое большое число виртуальных машин у поставщиков облачных услуг и обратимся к результатам исследования рынка (2015 год) облачных сервисов от Synergy Research Group:

Крупнейшим облачным провайдером осталась Amazon, записавшая в актив рыночную долю в размере 31%. Идущие следом Microsoft и IBM сильно отстают от лидера, имея 9- и 7-процентные показатели соответственно. В пятерку лучших по итогам 2015 года также вошли Google (4%) и Salesforce (4%).

Обратите внимание, облачный бизнес Amazon больше, чем у Microsoft, IBM, Google и Salesforce.com суммарно(!!!)

. По оценке Gartner 2014 года, Amazon продавал в 5 раз больше вычислительной мощности, чем остальные 14 компаний, попавших в квадрант, вместе взятых. Более того, Amazon продолжает укреплять позиции, наращивая свою долю на рынке, общий объем которого в 2014 году составил более $17 млрд.

Идем дальше. Какие гипервизоры используют ведущие cloud-провайдеры? Посмотрим на картинку (она вот из этого поста):

Из 15 представленных на графике cloud-поставщиков 4 используют Xen, но нас интересует, в первую очередь, Amazon.

Важное замечание: На самом деле Amazon использует не какой-то определенный продукт вроде Citrix XenServer или что-то ещё, а «свой Xen», созданный на базе кода, разрабатываемого сообществом xenproject.org.

Конечно, данные не совсем свежие, да и многие cloud-провайдеры используют сразу несколько гипервизоров в своей ит-инфраструктуре, ну и учтены не всё. Например, кроме Amazon Web Service, крупными «пользователями» виртуализации на базе Xen являются Tencent, Alibaba Cloud, Liquid Web, Verizon Cloud, Linode, SparkNode, OrionVM и Rackspace Cloud. Но в данном случае, не нужны точные цифры.

Даже по грубым оценкам видно, что доля использования гипервизора Xen в облачных вычисления ~50% (главным образом, благодаря AWS), остальную половину рынка делят KVM, Hyper-V и VMware.

Разработчики Xen очень гордятся этим и называют свой проект «Открытый гипервизор, созданный для облачных вычислений»:

Напишу ещё немного про рыночную долю AWS и цифры выручки. На секунду хочу вернуться к одному из моих предыдущих постов, «Почему Citrix не стала «новой Red Hat», процитирую:

Стать «следующей Red Hat», это замечательная цель, но когда вы смотрите на современные ИТ-тренды, то может быть стоит подумать о том, чтобы стать следующей Amazon.

И действительно, Red Hat в свое время помогала Amazon’у создавать инфраструктуру для AWS, а теперь выручка AWS составляет $7,88 млрд (по итогам 2015 года ), в то время как Red Hat заработала всего $2 млрд.

По результатам последнего квартального отчета Amazon (2 кв. 2016 г., закончившийся 30 июня), доход AWS составил 2,9 млрд. долл., что на 58% больше, чем за аналогичный период в прошлом году. Соответственно, можно ожидать, что выручка AWS за год будет больше $10 млрд. При этом, $2,9 млрд. — это всего лишь 9,5% от совокупного дохода Amazon во II кв. 2016 г., составившего 30,4 млрд. долл., (тем не менее это рентабельный сегмент, принесший компании чистую прибыль в размере 718 млн. долл.) Глядя на эти цифры, не удивительно, что глава Amazon, Джефф Безос (Jeff Bezos) занимает второе(!!!) место в рейтинге Forbes богатейших бизнесменов в сфере ИТ (с личным состоянием в $66 млрд.)

И теперь, после того как мы посмотрели на цифры, давайте ответим на вопрос, вынесенный в заголовок: Какой самый используемый гипервизор (для облачных вычислений)?

Компьютеры и Интернет

Основная концепция виртуализации состоит в том, чтобы избежать затрат на покупку нескольких аппаратных средств. Использование одной системы/оборудования/сервера таким образом, чтобы на нём могли работать несколько операционных систем — это то, что называется виртуализацией. И эта техника стала самой известной, особенно во всех средах центров обработки данных, и вы можете использовать эту технику на своём персональном ноутбуке или ПК.

Если виртуализация определяется как предоставление возможности нескольким операционным системам работать на одном хост-компьютере, тогда важным компонентом в стеке виртуализации является гипервизор. Этот гипервизор, также называемый Virtual Machine Monitor (VMM), создаёт виртуальную платформу на главном компьютере, поверх которой выполняется и контролируется несколько гостевых операционных систем. Таким образом, несколько операционных систем, которые являются либо несколькими экземплярами одной и той же операционной системы, либо разными операционными системами, могут совместно использовать аппаратные ресурсы, предлагаемые хостом.

Что такое гипервизор?

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

Машина, на которую мы устанавливаем гипервизор, называется хост-машиной, а не гостевыми виртуальными машинами, которые работают поверх них.

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

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

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

Виртуализация

Виртуализация означает создание более логичных ИТ-ресурсов, называемых виртуальными системами, в одной физической системе. Это называется виртуализация системы. Она чаще всего использует гипервизор для управления ресурсами для каждой виртуальной системы. Гипервизор — это программное обеспечение, которое может виртуализировать аппаратные ресурсы.

Существует два типа гипервизоров:

1. Гипервизор типа 1: гипервизоры работают непосредственно на аппаратном обеспечении системы — встроенный гипервизор «с нуля».
2. Гипервизор типа 2: гипервизоры работают в операционной системе хоста, которая предоставляет услуги виртуализации, такие как поддержка устройств ввода-вывода и управление памятью.

Гипервизоры типа 1:

1. VMware ESX и ESXi
Эти гипервизоры предлагают расширенные функции и масштабируемость, но требуют лицензирования, поэтому затраты выше.

VMware предлагает несколько недорогих комплектов, которые для небольших инфраструктур могут сделать технологию гипервизора более доступной.

VMware является лидером среди гипервизоров типа 1. Их продукт vSphere/ESXi доступен в бесплатной и 5 коммерческих версиях.

2. Microsoft Hyper-V
Гипервизор Microsoft Hyper-V не предлагает многих расширенных функций, которые предоставляют продукты VMware. Тем не менее, с XenServer и vSphere, Hyper-V является одним из топ-3 гипервизоров типа 1.

Впервые он был выпущен с Windows Server, но теперь Hyper-V был значительно улучшен с Windows Server 2012 Hyper-V. Hyper-V доступен как в бесплатной версии (без графического интерфейса и прав на виртуализацию), так и в 4 коммерческих версиях — Foundations (только для OEM), Essentials, Standard и Datacenter. Hyper-V,

3. Citrix XenServer
Этот гипервизор начался как проект с открытым исходным кодом. Технология основного гипервизора бесплатная, но, как и бесплатный ESXi от VMware, она почти не имеет расширенных функций.

Xen — это гипервизор 1-го типа. Так же, как Red Hat Enterprise Virtualization использует KVM, Citrix использует Xen в коммерческом XenServer.

Сегодня проекты и сообщество Xen с открытым исходным кодом находятся на Xen.org. Сегодня XenServer — это коммерческое гипервизорное решение типа 1 от Citrix, предлагаемое в 4 редакциях. Но, смущает то, что Citrix также называет свои собственные проприетарные решения, такие как XenApp и XenDesktop, именем Xen.

4. Oracle VM
Гипервизор Oracle основан на Xen с открытым исходным кодом. Но, если вам нужна поддержка гипервизора и обновления продукта, это будет стоить вам денег. В Oracle VM отсутствуют многие расширенные функции, присутствующие в других гипервизорах виртуализации с нуля.

Гипервизор тип 2

1. VMware Workstation/Fusion/Player
VMware Player — бесплатный гипервизор виртуализации. Он предназначен для запуска только одной виртуальной машины (ВМ) и не позволяет создавать виртуальные машины. VMware Workstation — это более надёжный гипервизор с некоторыми расширенными функциями, такими как запись и воспроизведение и поддержка моментальных снимков виртуальной машины.

VMware Workstation имеет три основных варианта использования:

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

2. VMware Server.

VMware Server —  это бесплатный размещенный гипервизор виртуализации, очень похожий на VMware Workstation. VMware приостановил разработку на сервере с 2009 года.

3. Microsoft Virtual PC.

Это последняя версия Microsoft для этой технологии гипервизора, Windows Virtual PC, которая работает только в Windows 7 и поддерживает только операционные системы Windows, работающие на ней.

4. Oracle VM VirtualBox.

Технология гипервизора VirtualBox обеспечивает разумную производительность и возможности, если вы хотите виртуализировать с ограниченным бюджетом. Несмотря на то, что VirtualBox является бесплатным размещаемым продуктом с очень небольшим пространством, он разделяет многие функции с VMware vSphere и Microsoft Hyper-V.

5. Red Hat Enterprise виртуализация.

Виртуальная машина на базе ядра Red Hat (KVM) обладает качествами как размещенного, так и виртуального гипервизора виртуализации. Это может превратить само ядро ​​Linux в гипервизор, чтобы виртуальные машины имели прямой доступ к физическому оборудованию.

6. KVM.

Это инфраструктура виртуализации для ядра Linux. Он поддерживает встроенную виртуализацию на процессорах с расширениями виртуализации оборудования. KVM с открытым исходным кодом (или виртуальная машина на основе ядра) — это гипервизор типа 1 на основе Linux, который можно добавить в большинство операционных систем Linux, включая Ubuntu, Debian, SUSE и Red Hat Enterprise Linux, а также Solaris и Windows.

Мы используем KVM в частном облаке VapourApps:

• Движок виртуализации — OpenStack на KVM.
• Предопределенные виртуальные серверы на основе Debian.
• Orchestration and management web dashboard, настраиваемая панель мониторинга Horizon.

Владелец клиента или ИТ-администратор может управлять своими виртуальными серверами, пользователями, группами и отслеживать состояние используемого приложения с помощью одной панели мониторинга.

Гипервизор для чайников / Habr

Всем привет! Решил поделиться опытом создания гипервизора на базе Ubuntu server 14.04 LTS и бесплатной виртуальной машине virtualbox 5.2 с вэб-интерфейсом управления как самим сервером (webmin), так и виртуальными машинами (phpvirtualbox). В сети можно найти кривоватую инструкцию по поднятию вышесказанного на ubuntu server 16.04, но эта инструкция морально устарела и предлагает версию virtualbox 5.0-5, не смотря на то, что в 16.04 в официальных репозиториях уже давно прижилась версия 5.2. Тут мы это все исправим. Данная инструкция применима как к ubuntu server 14.04, так и к 16.04. На более свежих версиях не проверял, но подозреваю что так же будет работать. Итак, начнем.

1. Для начала после установки ubuntu следует обновить все пакеты и ядро:

sudo apt-get -y update && sudo apt-get -y dist-upgrade

2. Затем перезагрузимся:

sudo reboot now

3. Теперь пересоздадим sources.list с добавлением необходимых репозиториев (для 14.04, если у вас версия выше — придется ручками править trusty на ваше кодовое имя (кроме webmin, он всегда sarge)). Для удобства зайдите под root:

su
или
sudo -i

4. Затем бекапим sources.list и создаем чистый:

cd /root
mv /etc/apt/sources.list /etc/apt/sources.list.bak
touch /etc/apt/sources.list
nano /etc/apt/sources.list

5. В новый файл sources.list вставляем это:

# 
deb http://ru.archive.ubuntu.com/ubuntu/ trusty main restricted
deb-src http://ru.archive.ubuntu.com/ubuntu/ trusty main restricted
deb http://ru.archive.ubuntu.com/ubuntu/ trusty-updates main restricted
deb-src http://ru.archive.ubuntu.com/ubuntu/ trusty-updates main restricted
deb http://ru.archive.ubuntu.com/ubuntu/ trusty universe
deb-src http://ru.archive.ubuntu.com/ubuntu/ trusty universe
deb http://ru.archive.ubuntu.com/ubuntu/ trusty-updates universe
deb-src http://ru.archive.ubuntu.com/ubuntu/ trusty-updates universe
deb http://ru.archive.ubuntu.com/ubuntu/ trusty multiverse
deb-src http://ru.archive.ubuntu.com/ubuntu/ trusty multiverse
deb http://ru.archive.ubuntu.com/ubuntu/ trusty-updates multiverse
deb-src http://ru.archive.ubuntu.com/ubuntu/ trusty-updates multiverse
deb http://ru.archive.ubuntu.com/ubuntu/ trusty-backports main restricted universe multiverse
deb-src http://ru.archive.ubuntu.com/ubuntu/ trusty-backports main restricted universe multiverse
deb http://security.ubuntu.com/ubuntu trusty-security main restricted
deb-src http://security.ubuntu.com/ubuntu trusty-security main restricted
deb http://security.ubuntu.com/ubuntu trusty-security universe
deb-src http://security.ubuntu.com/ubuntu trusty-security universe
deb http://security.ubuntu.com/ubuntu trusty-security multiverse
deb-src http://security.ubuntu.com/ubuntu trusty-security multiverse
deb http://archive.canonical.com/ubuntu trusty partner
deb-src http://archive.canonical.com/ubuntu trusty partner
## deb http://extras.ubuntu.com/ubuntu trusty main
## deb-src http://extras.ubuntu.com/ubuntu trusty main
deb https://download.webmin.com/download/repository sarge contrib
deb http://download.virtualbox.org/virtualbox/debian trusty contrib

6. Скачиваем и устанавливаем ключи:

wget http://www.webmin.com/jcameron-key.asc
wget https://www.virtualbox.org/download/oracle_vbox_2016.asc
wget https://www.virtualbox.org/download/oracle_vbox.asc
apt-key add jcameron-key.asc
apt-key add oracle_vbox.asc
apt-key add oracle_vbox_2016.asc
apt-get update

7. Устанавливаем необходимые пакеты:

apt-get install mysql-server apache2 php-soap webmin mc unzip traceroute
apt-get install virtualbox-5.2

8. Добавляем пользователя:

usermod -aG vboxusers {имя пользователя}

Важно! Используйте имя пользователя, имеющегося в системе, ибо именно от него будут запускаться виртуальные машины.
9. Далее скачаем и установим Extension Pack:

wget https://download.virtualbox.org/virtualbox/5.2.26/Oracle_VM_VirtualBox_Extension_Pack-5.2.26.vbox-extpack
VBoxManage extpack install Oracle_VM_VirtualBox_Extension_Pack-5.2.26.vbox-extpack

10. Осталось дело за вебмордой, скачиваем и устанавливаем:

wget https://github.com/phpvirtualbox/phpvirtualbox/archive/5.2-1.zip
mv phpvirtualbox-5.2-1 /var/www/html/phpvirtualbox

11. Назначим владельца и права:

chown -R www-data:www-data /var/www/html/phpvirtualbox
chmod -R 755 /var/www/html/phpvirtualbox

12. Теперь скопируем и отредактируем конфиг:

cp /var/www/html/phpvirtualbox/config.php-example /var/www/html/phpvirtualbox/config.php
nano /var/www/html/phpvirtualbox/config.php

13. В открывшемся конфиге нас интересуют только 2 строчки, а именно

var $username = 'user';
var $password = 'password';

сюда вносим реальные имя пользователя и пароль от учетки, указанной в пункте 8.

14. Создаем и редактируем файл /etc/default/virtualbox:

nano /etc/default/virtualbox
и добавляем туда
VBOXWEB_USER={имя пользователя из пункта 8}

15. Перезагружаемся:

reboot now

16. На гостевую ОС требуется установить Guest additions, скачиваем образ и монтируем в привод виртуальной машины:

wget https://download.virtualbox.org/virtualbox/5.2.26/VBoxGuestAdditions_5.2.26.iso 

Для *nix машин устанавливаем необходимые пакеты:

sudo apt-get install -y dkms build-essential linux-headers-generic linux-headers-$(uname -r)

Монтируем привод:

sudo mount /dev/sr0/ /media/cdrom

и стартуем от суперпользователя

cd /media/cdrom
./VBoxLinuxAdditions.run

Для машин на Windows просто выполняем Autorun или Setup.exe

Если все прошло успешно, то после перезагрузки по адресу http://{ip адрес сервера}/phpvirtualbox будет доступен интерфейс управления виртуальными машинами, а по адресу https://{ip адрес сервера}:10000 будет доступен webmin — мощный интерфейс управления сервером. Для входа в интерфейс управления виртуальными машинами используйте стандартный логин и пароль admin:admin (меняется в самом интерфейсе), а для авторизации в webmin используйте учетную запись реального пользователя с правами root (можно и непосредственно root, если вы его разблокировали).

Отличия гипервизора на монолитной и микроядерной архитектуре

Добрый день уважаемые читатели блога и подписчики youtube канала, сегодня я хочу с вами поговорить на тему какие отличия гипервизора на монолитной и микроядерной архитектуре, я думаю не все знают о том, что архитектур две. Мы с вами узнаем, у кого какие плюсы и минусы, так сказать продолжим холивары между Vmware и Microsoft, уверен вам это будет очень интересно и вы сможете, что-то переосмыслить.

Игроки на рынке виртуализации

И так. я вам давно уже рассказывал, что такое виртуализация и рассказывал ее принципы на примере Vmware ESXI. Сегодня я хочу вам рассказать как работает Hyper-V  и чем же отличаются два подхода в плане архитектуры процесса гипервизора. Как вы знаете на рынке сейчас два крупных игрока, первый и лидирующий это Vmware и догоняющий его с каждым годом Microsoft Hyper-V. Напомню, что каждое из данных решений, позволяет вам на одном физическом сервере запускать множество виртуальных машин с любой операционной системой. Такие ос, называются гостевыми, а основная называется хостовой. Все гостевые ОС работают в своем изолированном окружении, и самое забавное, что каждая думает, что она работает на отдельном сервере.

Работать так по хитрому, помогает программная реализация, гипервизор, дающая им доступ к физическим ресурсам сервера. В терминологии Microsoft данные виртуальные машины еще именуются как партиции.

Что такое гипервизор

Я думаю если спросить большинство инженеров по виртуализации, то они не смогут вам сказать происхождение слова гипервизор. Данное понятие, появилось кажется в 1972 году, в компании IBM. В те далекие времена перед IBM стояла задача виртуализации на своих мэйнфреймах System/370. Это стало просто мега открытием, с дало возможность обходить архитектурные ограничения и как следствие хорошую экономию по деньгам, так как мэйнфреймы стояли дорого, а они научились их использовать более рационально и полностью утилизировать их ресурсы.

Гипервизор — это по сути некая платформа для виртуализации, функционал которой дает возможность запускать в рамках одного физического сервера, более одной операционной системы. Благодаря ему гостевые ос и получают изолированность и доступ к аппаратному обеспечению компьютера.

Архитектуры гипервизоров

Существует две различные архитектуры:

• монолитная
• микроядерная

По мимо архитектур, у гипервизоров, еще и два типа

1 Тип гипервизора

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

К данному типу относятся вот такие игроки:

• VMware ESXI
• Hyper-V
• Citrix XenServer

2 Тип гипервизора

Ко второму типу гипервизора относятся продукты которые позволяю виртуализовывать операционные системы, работая как программы на хостовой операционной системе.

Очень простой пример, у вас есть установленная Windows 8.1, внутри нее вы устанавливаете гипервизор второго типа, у нас это будет VMware Workstation или Virtual Box. Как вы можете понять, в данном типе производительность ниже, чем у первого, так как есть излишняя и толстая прослойка в виде хостовой ос.

Монолитный гипервизор

И так с типами гипервизоров мы с вам познакомились, давайте разбираться в архитектурах. Первая на очереди это монолитная. Их главное отличие от других, что гипервизоры монолитной архитектуры включают драйверы аппаратных устройств в свой код.

Достоинства и недостатки монолитной архитектуры

• Более высокая производительность, так как драйвера находятся внутри гипервизора.
• Повышенная надежность, если у вас будет сбой управляющей ОС, например в Vmware ESXI это Service Console, то это никак не повлияет на запущенные виртуальные машины.

Что плохого:

• Логично, что поддерживаются устройства, драйвера, которых у вас установлены в гипервизоре. Если вы попытаетесь например добавить сетевую карту или fc карту в сервер на котором установлена Vmware ESXi версия, то если драйвера не будет, у вас карточка не появится среди доступных. В следствии чего, вендор гипервизора, должен плотно общаться и взаимодействовать с производителями железа, просить у них писать драйвера на их устройства для себя, тестировать это все дело. По той же причине при переходе на новую аппаратную платформу может понадобиться переход на другую версию гипервизора, и наоборот – при переходе на новую версию гипервизора может понадобиться смена аппаратной платформы, поскольку старое оборудование уже не поддерживается.
• Меньшая безопасность, так как приходится в гипервизор добавлять лишний код, это те драйвера, что вы устанавливаете. Так как драйвер работает в пространстве гипервизора, то можно теоретически воспользоваться уязвимостью кода, тем самым попытаться получить контрольный доступ над хостовой ос, а если он получен то и над гостевыми операционными системами.

Самый известный монолитный гипервизор, это конечно VMware ESXI.

Микроядерный гипевизор

Все с монолитной плитой мы разобрались. теперь на очереди понять принцип работы микроядерной архитектуры. Главное отличие в том, что драйвера на устройства устанавливаются внутри родительской ОС (хостовой)

По сути хоставая операционная система (Parent Partition), запускается как виртуальная машины, в том же окружении, где и все виртуалки, все остальные дочерние теперь. Разница между ними лишь в том, что родительская виртуалка, единственная имеет непосредственный доступ к оборудованию сервера. А выделением всевозможных ресурсов, различными планировщиками и оптимизацией мощностей занимается гипервизор.

Достоинства и недостатки микроядерной архитектуры

Что хорошего:

• Как вы уже наверно догадались, не требуются драйвера заточенные под гипервизор, а уж под Windows найти драйвера не проблема. Гипервизор микроядерной архитектуры, имеет совместимость почти с любым оборудованием, и имеет в 99 процентов случаев драйвера для parent partition.
• Если дальше развить мысль, то мы видим, что гипервизор разгрузили по задачам, так как драйвера обрабатывает родительская виртуальная машина, значит у него есть больше времени и ресурсов для более важных задач, например за управлением работы памяти, планировщика и т.д.
• Более безопасен, так как левого кода не крутится в нем.

Ну и и из самых таких крутых представителей это архитектуры, это конечно Microsoft Hyper-V.

Принцип работы windows server hyper-v

Про, то как работает архитектура Vmware ESXi я уже писал и в этом нет нужды, сейчас хочу рассмотреть гипервизор windows server hyper-v, чтобы вы более точно поняли отличия монолитной и микроядерной систем. Ниже я вам привел схему работы Hyper-V, давайте ее более подробно рассмотрим.

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

Родительская партиция Hyper-V

parent partition появляется в момент установки роли Hyper-V. Ниже представлена схема компонентов родительской партиции и для чего она нужна.

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

Принцип работы стека виртуализации

Тут я хочу более подробно рассмотреть, какие именно компоненты, работают в parent partition Hyper-V, все вместе они называются стек, и это не только у Microsoft, это во всех средах так называется некий набор компонентов, простой пример стек TCP/IP, который состоит из тьмы протоколов.

• Служба VMMS (Virtual Machine Management service), отвечает за управление виртуалками
• Служба VMWP, управляет рабочими процессами виртуалок.
• Virtual Device или виртуальные устройства
• Драйвер VID
• Библиотека интерфейсов гипервизора

Забыл сказать, что в архитектуре Hyper-V есть еще два рабочих компонента. Это VSP или провайдер служб виртуализации, а так же VMBus или если угодно шина виртуальных машин.

Компоненты VMMS

И так давайте смотреть, что входит в состав службы управления виртуальными машинами.

• Она обязана управлять состояниями виртуалок, включена или выключена
• С помощью нее вы добавляете или на оборот удаляете виртуальные устройства
• Ну и конечно работа со снапшотами или как их еще называют моментальные снимки.

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

За что отвечает VMMS:

• Запуск (Starting)
• Активность (Active)
• Не активность (Простой) (Not Active)
• Снятие снапшота (Taking Snapshot)
• Применение снапшота (Applying Snapshot)
• Удаление снапшота (Deleting Snapshot)
• Объединение дисков (Merging Disk)

Если вы вспомните про такие команды как пауза (Pause), Сохранить (Save ) или Завершить (Power Off), то ими не управляет VMMS, они то как раз работают в рабочем процессе соответствующей виртуальной машины. VMMS функционирует на двух уровнях, на уровне ядра как системная служба (VMMS.exe) и на уровне пользователя, она так же зависит от служб Remote Procedure Call (RPC) и Windows Management Instrumentation (WMI). Интерфейс для манипулированием виртуалок, ей предоставляет WMI-провайдер, входящий в VMMS как компонент. Из чего следует, что есть возможность работы с машинками из командной строки, а так же с помощью таких вещей как PowerShell или VBScript скрипты. Если вы знакомы с таким комплексом как System Center Virtual Machine Manager, то наверняка знаете. что он для управления виртуальными мишинками, тоже дергает этот интерфейс.

Теперь давайте разбираться в рабочем процессе виртуальной машины VMWP. Чтобы управлять виртуальной машиной за счет parent partition, используется специальный процесс VMWP. Он на пользовательском уровне запускается для каждой виртуальной машины, за счет службы  VMMS. Благодаря этому, достигается изолированность виртуальных машин друг от друга. Работают эти рабочие процессы из под локальной учетной записи Network Service, чтобы сделать весь процесс более безопасным.

Задачи VMWP:

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

Виртуальные устройства Hyper-V

Давайте разбираться, что же такое эти виртуальные девайсы или в терминологии Hyper-V их называют VDevs — все очень просто это программы, с помощью которых реализовывается конфигурация и управление устройствами в виртуалках. Какие именно компоненты входят в VMB, по сути это шина PCI и куча системных устройств, идентичные чипсету Intel 440BX. VMB бывают двух видов:

• Синтетические устройства — это устройства, которых в природе и не существует, у Vmware это могут быть примеры сетевых карточек VMXNET3, которых в жизни не существует. Примерами служат синтетический видеоадаптер, устройства взаимодействия с человеком (HID), сетевой адаптер, SCSI-контроллер, синтетический контроллер прерывания и контроллер памяти. Синтетические устройства могут использоваться только при условии установки компонент интеграции в гостевой ОС. Синтетические устройства обращаются к аппаратным устройствам сервера посредством провайдеров служб виртуализации, работающих в родительской партиции. Обращение идет через виртуальную шину VMBus, что намного быстрее, чем эмуляция физических устройств.

• Эмулируемые устройства – эмулируют настоящие аппаратные устройства, которые можно найти в виде реальных деталей, такие, к примеру, как видеоадаптер VESA. Эмулируемых устройств достаточно много, к примеру: BIOS, DMA, APIC, шины ISA и PCI, контроллеры прерываний, таймеры, управление питанием, контроллеры последовательных портов, системный динамик, контроллер PS/2 клавиатуры и мыши, эмулируемый (Legacy) Ethernet-адаптер (DEC/Intel 21140), FDD, IDE-контроллер и видеоадаптер VESA/VGA. Именно поэтому для загрузки гостевой ОС может использоваться только виртуальный IDE-контроллер, а не SCSI, который является синтетическим устройством.

VSP провайдеры служб виртуализации

VSP это службы, а точнее провайдеры виртуализации, работающие в parent partition и дающие для гостевых операционных систем доступ к аппаратным устройствам, как раз за счет VSC или клиента служб виртуализации. Их связь поддерживает VMBus шина.

Библиотека интерфейса гипервизора

Смысл данной библиотеки WinHv.sys – это DLL на уровне ядра, которая загружается как в хостовой, так и в гостевых ОС, при условии установки компонент интеграции. Эта библиотека предоставляет интерфейс гипервызовов, использующийся для взаимодействия ОС и гипервизора.

VID драйвер виртуальной инфраструктуры

VID драйвер vid.sys функционирует на уровне ядра и выполняет управление партициями, виртуальными процессорами и памятью. Так же этот драйвер является промежуточным звеном между гипервизором и компонентами стека виртуализации уровня пользователя.

VMBus шина виртуальных машин

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

Как уже было сказано, при использовании VMBus взаимодействие между хостовой и гостевой ОС происходит по клиент-серверной модели. В родительской партиции запущены провайдеры служб виртуализации (VSP), которые являются серверной частью, а в дочерних партициях – клиентская часть – VSC. VSC перенаправляет запросы гостевой ОС через VMBus к VSP в родительской партиции, а сам VSP переадресовывает запрос драйверу устройства. Этот процесс взаимодействия абсолютно прозрачен для гостевой ОС.

Что можно поставить в дочерних партициях

• ОС Windows, с установленными компонентами интеграции (в нашем случае – Windows 10)
• ОС не из семейства Windows, но поддерживающая компоненты интеграции (Red Hat Enterprise Linux в нашем случае)
• ОС, не поддерживающие компоненты интеграции (например, FreeBSD).

Во всех трех случаях набор компонент в дочерних партициях будет немного различаться.

Компоненты интеграции для семейства Windows поддерживаются начиная с 2000 версии. Как только вы установите в операционную систему Hyper-V Integration Services, у вас начнут работать вот такие компоненты:

• VSC или клиент служб виртуализации, по сути это синтетические устройства, которые через VMBus > VSP получают доступ к физическим устройствам. VSC работает, только после установки Hyper-V Integration Services и уже после этого синтетические устройства вам доступны, все как и в Vmware. Еще начиная с Windows 7 и Windows Server 2008 R2, они под капотом имеют Hyper-V Integration Services, инсталлировать их дополнительно не нужно. Еще одно из назначение компонентов интеграции, это обеспечить более быструю работу гостевой ОС и гипервизора. Данный код относится к дисковой, графической и сетевой подсистеме, навенро сразу замечали, что как только их поставишь, система сразу в консоли перестает тормозить.

Так же, компоненты интеграции предоставляют следующий функционал:

• Heartbeat (или серцебиения)– помогает определить, отвечает ли дочерняя партиция на запросы из родительской.
• Обмен ключами реестра – позволяет обмениваться ключами реестра между дочерней и родительской партицией.
• Синхронизация времени между хостовой и гостевой ОС, но лучше синхронизироваться, все же с контроллером домена.
• Завершение работы гостевой ОС
• Служба теневого копирования томов (VSS), позволяющая получать консистентные резервные копии.

Какие ос еще поддерживают компоненты интеграции

• SUSE Linux Enterprise Server
• Red Hat Enterprise Linux

У них правда свой VSC от сторонних производителей. Компоненты интеграции для Linux разработаны компанией Microsoft совместно с Citrix и доступны для загрузки в Microsoft Download Center.

Поскольку компоненты интеграции для Linux были выпущены под лицензией GPL v2, ведутся работы по интеграции их в ядро Linux через Linux Driver Project, что позволит значительно расширить список поддерживаемых гостевых ОС. Надеюсь вы теперь поняли разницу между монолитной и микроядерной архитектурой.

Несколько слов о реальной производительности гипервизора / Virtuozzo corporate blog / Habr

Пользователи виртуализированных систем, а особенно – сервис-провайдеры, очень часто задаются вопросом: «как выжать максимум из имеющегося железа?». И в этом контексте нам нередко приходится обсуждать гипервизор KVM и отличия между разными версиями Virtuozzo. В этом посте мы расскажем о ряде тестов последней системы виртуализации вместе с оценками реальной производительности при типовых нагрузках, а также с учетом патчей Meltdown и Spectre.

Что важнее всего для хостинговой компании или для ИТ-отдела, которому необходимо организовать поддержку максимального количества задач на имеющемся оборудовании? Если компания работает по сервисно-ориентированной модели или продает сервисы, то практика показывает, что главное – это показатель прибыли на один сервер. Какие при этом используются технологии и за счет чего достигается плотность размещения, уже не так сильно волнует представителей бизнеса.

Тем не менее, вопрос, почему мы используем KVM в виде гипервизора в Virtuozzo 7, и чем мы в таком случае отличаемся от простой OpenSource-системы виртуализации, задают очень часто. И сегодня хочется дать на него ответ.

В прошлом Virtuozzo работала со своим собственным, проприетарным гипервизором, но несколько лет назад мы поняли, что развивать его дороже и сложнее, чем оптимизировать достаточно удачный и эффективный KVM. Тем не менее, KVM не является эталоном производительности, и как любая OpenSource-платформа требует доработки напильником. Этим и занимается часть нашего отдела разработки. Мы оптимизируем код, интегрируем его с платформой хранения данных и другими компонентами, за счет чего достигается повышение производительности и плотности размещения.

Сравнение с другими гипервизорами

Одним из тестов, которые мы используем для оценки производительности, является DVD Store. Он использует классический набор серверного программного обеспечения: Linux, Apache, MySQL, PHP (LAMP). Внутри каждой виртуальной машины тест эмулирует работу онлайн-магазина по продаже DVD. Результатом теста является количество транзацкий совершенных суммарно во всех виртуальных машинах (ось ординат). Количество виртуальных машин, вовлеченных в тест, увеличивается последовательно от 1 до 100 (ось абсцисс).

LAMP: OpenSource QEMU KVM vs Virtuozzo @ CentOS 7.4 (виртуальные машины)

Как видно на графиках выше, производительность виртуальных машин с CentOS Linux 7.4 работающих на гипервизоре Virtuozzo 7 оказывается до 30% выше, чем при запуске аналогичной нагрузки на стандартном KVM. Наибольшая разница наблюдается в точке CPU-оверкоммита, где суммарное количество ядер процессоров, выделенных всем виртуальным машинам, достигает количества физических ядер CPU сервера. Для данного сервера эта точка соответствует 20 виртуальным машинам. Кроме того, ядро Virtuozzo 7 и адаптивная политика управления памятью обеспечивают стабильную работу виртуальных машин после точки RAM-оверкоммита, где суммарное количество оперативной памяти, выделенное всем виртуальным машинам, превышает размер физической памяти сервера. При такой нагрузке стандартный KVM вовсе не может создать условия для нормальной работы.

Другое сравнение было проведено между гипервизорами Virtuozzo 7 и Microsoft Hyper-V 3.0. Здесь производительность оценивалась с помощью теста vConsolidate, а в качестве гостевой операционной системы виртуальных машин использовалась Windows Server 2012 R2.

vConsolidate: Hyper-V vs Virtuozzo @ Windows 2012 R2 (виртуальные машины)

В отличие от DVD Store, в vConsolidate нагрузка не одинакова для всех виртуальных машин. В этом тесте они разделены на так называемые CSU (Consolidation Stack Units). Каждая CSU – это группа из четырех виртуальных машин, нагрузку в которых создают SPECjbb, WebBench и SysBench (OLTP). Четвертая ВМ в каждой CSU – idle, то есть без нагрузки. Количественным результатом является среднее геометрическое от результатов трех вышеупомянутых тестов, полученных суммарно из всех виртуальных машин (ось ординат). Количество CSU, вовлеченных в тест, увеличивается последовательно от 1 до 24 (ось абсцисс).

Для обоих гипервизоров тест проводился дважды: с установленными патчами для уязвимостей Meltdown и Spectre, а также без них. Аппроксимация результатов показывает, что Virtuozzo 7 в среднем демонстрирует на 15% более высокую производительность, чем «родной» гипервизор Microsoft.

Meltdown и Spectre

Как известно, 4 января 2018 года всё IT-сообщество было взбудоражено обнаружением масштабных концептуальных уязвимостей во всех процессорах Intel, за исключением Itanium и старых Atom (до 2013 года). Использование этих уязвимостей позволяет любому непривилегированному процессу в системе получить доступ к данным ядра (Meltdown) или данным другого процесса (Spectre). Разработчики ПО сосредоточились на выпуске обновлений программно устраняющих эти уязвимости. Однако у пользователей, естественным образом, возникли вопросы о том, как эти обновления сказались на производительности систем.

Мы проверили насколько патчи для Meltdown и Spectre влияют на производительность контейнеров с CentOS Linux 7.4 на примере теста vConsolidate. Затем мы провели еще одно измерение – с ядром скомпилированным модифицированным компилятором с опцией «Retpoline» (такую возможность, например, предлагают GCC и Clang/LLVM).

Производительность с Retpoline: vConsolidate @ CentOS 7.4 (контейнеры)

Как видно на графиках выше, применение патчей против Meltdown и Spectre значительно снижает производительность контейнеров. Причем самым «тяжелым» оказался патч для Spectre-V2. Однако использование компилятора с новой опцией Retpoline позволяет безопасно отказаться от этого патча на системах с процессорами старше Skylake и отыграть целых 25% производительности. Впрочем, около 5% мы всё же потеряли из-за патчей для Meltdown и Spectre-V1.

Производительность с Retpoline: vConsolidate @ CentOS 7.4 (виртуальные машины)

В случае с CentOS Linux 7.4 внутри виртуальных машин ситуация выглядит немного радужнее: патчи для Meltdown и Spectre ухудшают производительность всего на 15%, а разница в производительности непропатченного ядра и ядра скомпилированного с Retpoline составляет всего 1-2%. Таким образом, использование нового компилятора позволило практически полностью скомпенсировать падение производительности. Однако стоит учесть, что все три измерения проводились на одних и тех же виртуальных машинах – с непропатченными ядрами гостевых ОС. Обновление гостевых ОС повлечет дополнительное ухудшение производительности пользовательских приложений.

Производительность с Retpoline: vConsolidate @ Windows 2012 R2 (виртуальные машины)

Последний на сегодня график – аналогичное сравнение, но уже с виртуальными машинами Windows Server 2012 R2. Здесь замедление от патчей было не так велико и составило около 10%, а использование ядра с Retpoline позволило сократить разницу до 2-3% относительно непропатченного ядра.

Заключение

Безусловно, у немодифицированного KVM есть свои плюсы, и основное достоинство — это его бесплатность. Но проведенные тесты доказывают, что частные доработки и модернизация позволяют повысить отдачу от используемой инфраструктуры. То есть, если вам нужно разместить максимум контейнеров и виртуальных машин, обеспечить для них постоянное хранение – всё это на одной платформе и с минимумом шаманских танцев – улучшенный KVM оказывается намного результативнее, особенно если сервисы, работающие на платформе, показывают хорошую маржу и приносят реальные деньги. В этом случае стоимость лицензий и поддержки с лихвой окупается в кратчайшие сроки.

Сильной стороной VZ7 остается поддержка разных типов ВМ и контейнеров на одной платформе, причём с более высокой производительностью для каждой категории виртуальных объектов. Однако и здесь нельзя говорить о панацее. Например, если повышение плотности не принесёт организации дополнительных финансов, а собственный персонал вполне может администрировать и допиливать OpenSource-решения, тогда логика склоняет к использованию открытых инструментов, в том числе CentOS и оригинального KVM.

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

аппаратная виртуализация на практике — «Хакер»

Содержание статьи

Ты, конечно, не раз слышал про такую штуку, как аппаратная виртуализация –
технологию, позволяющую запускать несколько гостевых ОС на одной машине (так
называемом хосте). Исторически первой была программная виртуализация, затем
разработчики процессоров призадумались, что неплохо было бы обеспечить
аппаратную поддержку этого дела. Итак, с 2006-го года в нашем распоряжении
оказались процессоры Intel и AMD с возможностями виртуализации. И
пошло-поехало…

Надо сказать, что обзоров и статей, касающихся темы виртуализации, выходило
за эти годы немало. Например, рекомендую к прочтению статью «Технологии
аппаратной виртуализации», представляющую собой довольно основательный обзор
сабжа.

Однако, ни одной статьи, выходящей за рамки аналитики, я так и не встретил.
Пора закрыть этот пробел и сконцентрироваться, наконец, на деталях реализации
гипервизора. Между тем, уже, наверное, каждому известно про
«Голубую пилюлю» (Blue
Pill) Рутковской, в которой возможности виртуализации успешно применяются,
причем не в самых легитимных целях :). Пока кто-то создает экспериментальные
руткиты на базе виртуализации, кто-то активно разрабатывает анти-руткиты. Так,
Hypersight Rootkit Detector от North Security Labs – считай готовый анти-руткит
для Windows. Для Linux тоже существует подобный проект – HookSafe, который был
представлен на конференции ACM по компьютерной и сетевой безопасности (CCS
2009).

Такой интерес к виртуализации далеко не случаен – ведь для хакера это
уникальная возможность скрытия своего присутствия в системе (наряду с более
сложными, но и не менее красивыми, атаками на SMM и AMT). Конечно, чтобы сделать
руткит (даже на базе виртуализации) на 100% недетектируемым придется напрячься,
но игра стоит свеч! В конце концов, мы получает возможность тотального контроля
над системой. Заинтересовало? Тогда вперед, осваивать такую непростую штуку как
программирование гипервизоров.

Прежде чем зарываться в документацию, нужно обрисовать задачу более подробно.
Вообще, аппаратная виртуализация в процессорах Intel (именуемая Intel VT)
отличается от аналогичной у AMD (AMD-V). Отличается – значит, код гипервизора (aka
VMM – Virtual Machine Monitor) для AMD не будет работать на платформе Intel.
Поэтому мы начнем с AMD и продолжим о Intel в последующих статьях. Чтобы ты мог
уточнить для себя какие-то вещи, тебе потребуется дока от AMD, также можно
почитать краткий обзор
AMD-V
от производителя.

 

Теоретические основы

Перед тем, как приступать к написанию кода, необходимо получить минимальную
теоретическую базу. Для начала определимся с терминами и аббревиатурами, которые
будут использоваться далее по тексту.

• Гостевой режим – по аналогии с защищенным, реальным – режим
  работы процессора, в котором выполняется гостевая система.
• Гость – виртуальная ОС, работающая в гостевом режиме под
  управлением гипервизора.
• VMM (монитор виртуальных машин, гипервизор) – программное
  обеспечение, перехватывающее события в госте. Гипервизор представляет собой
  рычаг управления гостевыми системами.
• Хост (по отношению к гостю) – система, на которой запущен
  гипервизор.
• #VMEXIT – переход из режима гостя в режим хоста.

 

Подробности

Ты — обладатель процессора AMD. Как узнать, есть ли в нем поддержка
аппаратной виртуализации? О том, что мы имеем соответствующий функционал,
рапортует функция 80000001h инструкции CPUID (второй бит от нуля в регистре ecx,
именуемый SVM, должен быть установлен). Функция, возвращающая 0 или 1,если
возможности виртуализации недоступны или доступны, соответственно.

IsSVMAvailableProc proc
xor rax,rax
mov eax,80000001h
cpuid
xor rax,rax
bt ecx,2 ; проверяем бит SVM
jnc if_zero ; прыгаем, если бит равен 0
inc rax
if_zero:
ret
IsSVMAvailableProc endp

Убедившись, что в нашем распоряжении подходящий процессор, можно приступать к
дальнейшему описанию. Забегая вперед, скажу, что включение виртуализации, как и,
в общем-то, весь код нашего гипервизора, будет находиться в драйвере и работать
в ring-0. В процессе освоения кодинга гипервизора от тебя потребуется
представление о программировании драйверов под Windows, знание с/с++ и
64-битного ассемблера на базовом уровне. Хотя я все равно постараюсь объяснить
все максимально подробно.

 

Инструкции управления виртуальными машинами

По своей сути аппаратная виртуализации – это расширение архитектуры ЦП: набор
инструкций + новый режим работы процессора. До того, как говорить о наборе
команд, нужно разобраться с такой штукой, как VMCB. VMCB (Virtual
Machine Control Block) – управляющий блок виртуальной машины. Это основная
структура данных, с которой нам предстоит работать. VMCB описывает виртуальную
машину, которую мы будем запускать. Сразу о технических деталях: VMCB занимает
одну страницу (4 килобайта) в непрерывной физической памяти. VMCB состоит из 2-х
частей – область флагов (control area) и область состояния (state-save area).
Рассмотрим структуру VMCB подробнее. VMM, как уже упоминалось, перехватывает
события, происходящие в госте. Какие это будут события – определяется в области
флагов. Мы можем перехватывать:

1.Чтение/запись контрольных регистров (cr0-cr15). Первые 16 бит структуры
VMCB как раз и отводятся на установку перехвата операции чтения для каждого из
контрольных регистров. Каждый бит отвечает за свой контрольный регистр. Вторые
16 бит VMCB отвечают за операцию записи в контрольные регистры.

2. Чтение/запись отладочных регистров (dr0-15).

3. Инструкции rdmsr/wrmsr для выбранных msr-регистров. Чтобы определить,
какие msr подлежат контролю, используется так называемая MSR Permission Map (в
переводе — карта разрешения msr, сокращенно — MSRPM). На каждый msr в ней
отводится по 2 бита – для контроля операции чтения и записи. Физический адрес
начала MSRPM хранится в VMCB.

Структура карты разрешения MSR (MSRPM). Каждые 2 бита отвечают за отдельный
MSR.

Когда будет произведена запись/чтение в контролируемый msr – произойдет #VMEXIT,
а подробная информация о событии запишется в поле exitinfo1 VMCB (оно будет рано
0 – если выход спровоцировала rdmsr, и 1, если wrmsr).

4. Инструкции работы с портами. Как и в случае с msr-регистрами, за контроль
доступа к портам отвечает карта разрешения ввода-вывода (IOPM, I/O Permission
Map). Там, конечно, все чуток сложнее, чем с msr. После #VMEXIT информация об
исключении будет записана в поле exitinfo1, где будет содержаться информация об
инструкции, которая вызвала исключение.

Формат поля exitinfo1 в VMCB для перехваченных инструкций ввода-вывода

5. Инструкции чтения/записи регистров ldtr,gdtr, tr,idtr.

6. Исключения (0-31 векторы в IDT).

7. Инструкции, отвечающие за аппаратную виртуализацию (VMRUN,VMSAVE,VMLOAD…).
То есть, можно контролировать запуск других гипервизоров (они будут вложенными).
Кстати, с помощью перехвата этих инструкций Hypersight Rootkit Detector и
обнаруживает «Голубую пилюлю».

8. Сигналы SMI, NMI, INIT…

9. Еще много различных инструкций, таких как cpuid, iret, rsm и т.п.

Все вышеперечисленные события – это условия #VMEXIT – возвращения из
гостевого режима в режим хоста. Каждая причина #VMEXIT имеет свой код, который
записывается в поле exitcode области флагов VMCB. Вот некоторые из этих кодов:

62h – физическое SMI
6Eh – произошла инструкция RDTSC
70h – команда PUSHF
71h – POPF
72h – CPUID
7F – гость выключился (Shutdown)
80h – VMRUN
81h — VMMCALL
82h – VMLOAD
83h — VMSAVE
88h – ICEBP (инструкция с опкодом 0xF1)
-1 – неверная VMCB

Полную таблицу #VMEXIT-тов можно посмотреть в Appendix C. SVM Intercept Exit
Codes в уже упоминаемом мной AMD64 Architecture Programmer’s Manual Volume 2.

Часть дефиниции cтруктуры VMCB (из сорцов Xen):

struct vmcb_struct {
// область флагов
// первое слово – перехват чтения cr0-15
// второе слово – перехват записи cr0-15
u32 cr_intercepts; /* offset 0x00 */
// первое слово – перехват чтения dr0-15
// второе слово – перехват записи dr0-15
u32 dr_intercepts; /* offset 0x04 */
// поле установки перехватываемых исключений (векторы 0-31 в IDT)
u32 exception_intercepts; /* offset 0x08 */
// INTR, NMI, SMI....IDTR (запись/чтение), GDTR (запись/чтение), LDTR(запись/чтение)
// TR(запись/чтение), инструкции RDTSC, RDPMC, PUSHF, POPF …
u32 general1_intercepts; /* offset 0x0C */
u32 general2_intercepts; /* offset 0x10 */
…
…
// физический адрес карты разрешения ввода-вывода
u64 iopm_base_pa; /* offset 0x40 */
// физический адрес карты разрешения msr
u64 msrpm_base_pa; /* offset 0x48 */
// это поле нужно для команды rdtsc
u64 tsc_offset; /* offset 0x50 */
// идентификатор адресного пространства гостя, связано со сбросом TLB, пока это
не нужно
u32 guest_asid; /* offset 0x58 */
u8 tlb_control; /* offset 0x5C */
u8 res07[3];
vintr_t vintr; /* offset 0x60 */
u64 interrupt_shadow; /* offset 0x68 */
// после #VMEXIT здесь окажется код причины выхода
u64 exitcode; /* offset 0x70 */
u64 exitinfo1; /* offset 0x78 */
u64 exitinfo2; /* offset 0x80 */
…
eventinj_t eventinj; /* offset 0xA8 */
// используется для вложенного страничного преобразования (nested paging) – об
этом расскажу в
//другой раз
u64 h_cr3; /* offset 0xB0 */
lbrctrl_t lbr_control; /* offset 0xB8 */
// оставшееся место – 832 байта - заполняется нулями – оно зарезервировано для
дальнейшего //расширения
u64 res09[104]; /* offset 0xC0 pad to save area */
…

Все неиспользуемое пространство обязательно должно быть заполнено нулями.
Вторая часть VMCB содержит состояние регистров гостя. Из этой области во время
выполнения инструкции VMRUN (о ней скажу позже) загружается информация о
состоянии гостя, а при выходе из гостевого режима она (информация о состоянии)
сохраняется там же.

// начало области состояния
svm_segment_register_t es; /* offset 1024 */
svm_segment_register_t cs;
svm_segment_register_t ss;
svm_segment_register_t ds;
svm_segment_register_t fs;
svm_segment_register_t gs;
svm_segment_register_t gdtr;
svm_segment_register_t ldtr;
svm_segment_register_t idtr;
svm_segment_register_t tr;
…
…
u64 efer; /* offset 1024 + 0xD0 */
u64 res13[14];
u64 cr4; /* loffset 1024 + 0x148 */
u64 cr3;
u64 cr0;
u64 dr7;
u64 dr6;
u64 rflags;
u64 rip;
u64 res14[11];
u64 rsp;
u64 res15[3];
u64 rax;
u64 star;
u64 lstar;
u64 cstar;
u64 sfmask;
u64 kerngsbase;
u64 sysenter_cs;
u64 sysenter_esp;
u64 sysenter_eip;
u64 cr2;
…
…
// регистры, связанные с трассировкой ветвлений
u64 debugctlmsr;
u64 lastbranchfromip;
u64 lastbranchtoip;
u64 lastintfromip;
u64 lastinttoip;
u64 res16[301]; // далее просто 2408 нулевых байт
}

Структура VMCB

С VMCB кое-как разобрались. Теперь можно переходить к описанию инструкций.

VMRUN (опкод команды — 0Fh, 01h, 0D8h) – инструкция запуска виртуальной
машины. Это основная и самая важная команда в аппаратной виртуализации. VMRUN
принимает в качестве аргумента в регистре rax физический адрес управляющего
блока виртуальной машины (VMCB), который описывает состояние виртуальной машины.
VMRUN доступна только с нулевого кольца (вообще, с третьего кольца из
инструкций, составляющих сабжевое расширение архитектуры процессора, доступна
только VMMCALL).

Гипервизор настраивает структуру VMCB, устанавливает в ней перехватываемые
инструкции, прерывания и т.д. Переход в режим гостя происходит посредством
инструкции VMRUN. Состояние хоста сохраняется в области памяти, на которую
указывает содержимое msr регистра VM_HSAVE_PA (PA – Physical Address, то есть
здесь мы опять имеем дело с физическим адресом этого региона). В этой области
памяти сохраняется минимальная информация, необходимая для возобновления работы
хоста после выхода из гостя (регистры cs,rip, efer, cr0, cr3 …). Теперь, когда
виртуальная машина успешно запущена, мы вернемся в режим хоста только при
возникновении перехваченного гипервизором события (условия #VMEXIT). После #VMEXIT
будет выполнена следующая за VMRUN инструкция в гипервизоре. Специально для тебя
я сделал обобщающую схему вышеописанного (смотри картинку «Схема работы
виртуализации AMD-V»).

Схема работы виртуализации AMD-V

Две инструкции VMSAVE (0Fh, 01h, 0DBh) и VMLOAD (0Fh, 01h, 0DAh) дополняют
VMRUN и служат для сохранения/загрузки части VMCB.

VMMCALL (0Fh, 01h, 0D9h) – инструкция, позволяющая из гостевого режима
перейти в хост. Доступна как на нулевом, так и на третьем кольце. Правда, я
лично не понимаю смысла в этой инструкции. Если она не перехватывается, то
возникает #UD. То есть, безусловного вызова гипервизора не происходит. Можно
было бы, наверное, не вводить дополнительную инструкцию, использовать ту же
CPUID (или другую, которую можно перехватить).

 

Включение возможностей аппаратной виртуализации

Все инструкции работы с аппаратной виртуализацией (за исключением SKINIT, там
особый случай) требуют установки бита SVME (он 12-й) в регистре EFER (иначе мы
получим исключение #UD – неверная инструкция). Что это за регистр – EFER?
Расшифровывается аббревиатура как Extended Feature Enable Register – это msr,
который отвечает за включение дополнительных возможностей проца (что видно из
расшифровки), и он имеет адрес 0C0000080h. Приведенный ниже код включает
возможности аппаратной виртуализации:

sub rcx,rcx
mov ecx, 0C0000080h ; адрес EFER
rdmsr ; читаем EFER
bts eax,12
wrmsr

MSR-регистр EFER. У него полно различных функций помимо включения аппаратной
виртуализации.

Кстати, установка бита SVME может быть заблокирована, поэтому после того, как
мы записали msr, нужно снова прочитать его содержимое и проверить – установился
ли заветный бит.

За блокировку инструкций виртуализации отвечают msr-регистры – VM_CR и
SVM_KEY (опционально). Бит SVMDIS, который четвертый в VM_CR, запрещает
установку EFER.SVME, а LOCK (бит три) в том же регистре запрещает сброс SVMDIS и
LOCK (получается, что LOCK – это защита для защиты). LOCK можно сбросить либо
после перезагрузки, либо указать ключ в машинно-зависимом регистре SVM_KEY (если
этот ключ был установлен перед блокированием виртуализации). Сама возможность
блокировки, к слову, появилась в AMD-V не сразу, а только со второй ревизии
(специально для параноиков:)).

MSR-регистр VM_CR, позволяющий заблокировать установку бита SVME в EFER.

 

Заключение

Первый теоретический рубеж преодолен. Изложение получилось несколько
сумбурным, но, я думаю, это тебе не помешало уловить суть. Осталось реализовать
полученные знания на практике, что мы и сделаем в последующих статьях. Если у
тебя есть какие-то замечания или вопросы – пиши мне на мыло, постараюсь
ответить.

 

WWW

AMD64 Architecture Programmer’s Manual Volume 2: System Programming:

amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf. Теме
виртуализации в этом мануале посвящена глава 15, Secure Virtual Machine.

Hypersight Rootkit Detector (для Windows) – анти-руткит на основе аппаратной
виртуализации. Фраза на главной странице «Blue Pill перестал быть невидимым» –
заставляет познакомиться с сабжем поближе:

northsecuritylabs.com/ru.

Проект Blue Pill Джоанны Рутковской – руткит, использующий аппаратную
виртуализацию (опенсорс):
bluepillproject.org.

В качестве дополнительной литературы можно почитать также ман AMD, целиком и
полностью посвященный CPUID. CPUID Specification

amd.com/us-en/assets/content_type/white_papers_and_tech_docs/25481.pdf.

Проект Xen
xen.org/products/projects.html.

HookSafe – не так давно появившийся анти-руткит на основе гипервизора (для
Linux). Исследователи работают над версией для Windows

discovery.csc.ncsu.edu/pubs/ccs09-HookSafe.pdf.