Паравиртуальные драйверы Xen
Материал из Xgu.ru
- Автор: Игорь Чубин
- Короткий URL: xen/pvdrivers
Паравиртуальные драйверы Xen — специальный вид драйверов устройств,
которые используются в гостевой системе в домене Xen (в общем случае
паравиртуальным драйвером может называться и та часть паравиртуального
интерфейса ввода/вывода, которая находится в домене 0)
и осуществляют операции ввода/вывода не через эмулируемые устройства,
как это делают обычные драйверы, а при помощи специального интерфейса,
предоставляемого системой виртуализации и хост-системой.
Одна из главных причин разработки и использования паравиртуальных драйверов — возможность существенного повышения производительности работы гостевых систем,
работающих в режиме полной виртуализации.
Содержание |
[править] Что это такое и зачем это нужно?
[править] Возможность запуска операционных систем, не перенесённых на Xen
Система виртуализации и паравиртуализации Xen, начиная с версии 3.0, позволяет запускать в гостевых доменах не только паравиртуальные гостевые системы, но и немодифицированные гостевые системы в так называемом HVM-режиме (hardware virtualization mode). Начиная с версии 3.1.0 появилась возможность живой миграции доменов, что имеет принципиальное значение для крупномасштабных систем виртуализации и дает возможность полноценного использования HVM-доменов наряду с паравиртуальными.
Основное требование, которое должно выполняться, для того чтобы немодифицированную систему можно было выполнять в гостевом домене Xen, необходима поддержка так называемой аппаратной виртуализации. Фактически, это сводится к тому, что:
- центральный процессор должен иметь специальные архитектурные расширения (Intel Vanderpool или AMD Pacifica);
- BIOS материнской платы не должен возражать против использования этих расширений.
(Подробнее: «Аппаратные требования Xen»).
[править] Рост популярности систем с поддержкой аппаратной виртуализации
Раньше особые требования к аппаратному обеспечению компьютера были существенной преградой на пути к использованию Xen как полноценной системы виртуализации.
В последнее время эта проблема имеет всё меньшее значение:
- большая часть продающихся в настоящее время систем уже имеет возможность аппаратной виртуализации;
- коммерческий хостинг доменов Xen уже возможен с поддержкой аппаратной виртуализации (см. «Хостинг доменов Xen»).
Так, например, по данным ITC в сентябре 2007 года на рынке Киева присутствовали центральные процессоры в таком соотношении [1]
Большинство из этих процессоров имеют архитектурные расширения аппаратной виртyализации. Если быть более точным, распределение таково:
- без аппаратной виртуализации — 37%;
- аппаратная виртуализация Intel — 27%;
- аппаратная виртуализация AMD — 36%.
Таким образом, более 60% представленных на рынке сейчас способны выполнять аппаратную виртуализацию. Вероятно, тенденция будет только усиливаться и в скором времени таких процессоров будет подавляющее большинство.
|
|
Следует обратить внимание на то, что это, во-первых, данные по предложениям, а не по покупкам и, во-вторых, это данные для локального рынка. Их можно воспринимать только как грубую оценочную информацию для получения общего представления о популярности аппаратной виртуализации на сегодняшний день. |
[править] Аппаратная виртуализация и ввод/вывод
При аппаратной виртуализации гостевая операционная система получает вычислительные ресурсы практически без потерь. Величина потерь в этом случае соизмерима с потерями при паравиртуализации. Они меньше, чем в случае чистой программной виртуализацией.
Тем не менее, при аппаратной виртуализации операционная система, запущенная в гостевом домене Xen работает медленно. В этом легко убедиться — достаточно посмотреть как работает, например, Windows в домене Xen (это относится не только к Windows, а ко всем системам, работающим в режиме аппаратной виртуализации).
Чем обусловлено такое замедление работы системы?
Аппаратная виртуализация берёт на себя основные трудности по переключению контекстов гостевых операционных систем и хост-системы, но она ничего (пока что) не делает для ускорения ввода/вывода. Как только задача требует ввода/вывода любая система виртуализации (но не паравиртуализации!) существенно замедляет свою работу.
Например, результаты известного сравнения производительности систем паравиртуализации и виртуализации [2] произведённого ещё несколько лет назад в сетевой лаборатории Кембриджского университета (рисунок справа) хорошо демонстрируют тот факт, что системы виртуализации и паравиртуализации работают на максимальной скорости при выполнении чисто вычислительных задач, но как только работа требует ввода/вывода, виртуализация начинает существенно отставать.
Существует три основных способа обеспечения ввода/вывода (и, фактически, доступа к оборудованию) для гостевой операционной системы:
- Эмуляция устройств со стороны домена 0 и использование традиционных драйверов в гостевой системе;
- Монопольное выделение устройств гостевой системе;
- Использование паравиртуальных драйверов.
[править] Эмуляция устройств для HVM-домена
В настоящий момент наиболее распространённым является первый способ, т.е. эмуляция устройств.
Xen использует для эмуляции, так называемый QEMU Device Model (qemu-dm). Это специальный процесс, работающий в пространстве пользователя (userlevel) в домене 0 и предоставляющий виртуальные устройства гостевому домену.
Эмулируются такие устройства:
- Видеокарта Cirrus CLGD 5446 PCI VGA card или простая VGA-карта с поддержкой расширений VESA;
- IDE-интерфейс с поддержкой CD-ROM'а
- Сетевые карты NE2000 и RTL8139
- Звуковые карты Creative SoundBlaster 16 или ENSONIQ AudioPCI ES1370 sound card
- Виртуальный PCI UHCI USB-контроллер и виртуальный USB-хаб.
В гостевой системе используются обычные драйверы для соответствующих устройств. Гостевая операционная система не догадывается о том, что устройства не настоящие, а эмулируемые.
Естественно, что вся нагрузка по эмуляции ложится на домен 0. При активном вводе-выводе внутри гостевой системы (например, копировании файла) соответствующий процесс qemu-dm, работающий в домене 0, потребляет огромное количество вычислительных ресурсов (вплоть до 100%, но, как правило, это число находится в районе 30-40%).
При этом основная энергия тратится на то, чтобы, грубо говоря, предельно чётко изобразить эмулируемое устройство, так чтобы гостевая операционная система не заметила подмены.
[править] Монопольное выделение устройств HVM-домену
- Основная страница: Использование VT-d в Xen
Полной противоположностью этому подходу является второй подход — монопольное выделение устройства гостевой системе. В этом случае никаких затрат на эмуляцию не требуется. Гостевой домен работает с устройством напрямую, без всякого посредничества домена 0. Он видит устройство "как есть", и использует стандартные драйверы от этого устройства. Работа с устройством осуществляется на полной скорости.
В настоящий момент такой способ работает с паравиртуальными доменами — им можно выделять устройства в монопольное использование без всяких проблем. Что касается HVM-доменов (доменов, использующих аппаратную виртуализацию), это:
- Требует аппаратной поддержки;
- В настоящий момент реализовано только в экспериментальном виде в Xen-unstable.
Полноценная поддержка монопольного выделения устройства HVM доменам появится в версии 3.2.0, выход которой запланирован на начало 2008 года.
Что касается аппаратной поддержки, она есть, но пока что достаточно редка.
Сейчас есть как минимум две платы производства Intel (DQ35MP и DQ35JO), которые поддерживают собственную реализацию аппаратной виртуализации ввода/вывода известную как Intel VT-d (не путать с Intel VT!).
В AMD тоже ведётся работа над собственной реализацией аппаратной виртуализацией ввода/вывода, IOMMU.
Резюмирую вышесказанное, фактически, пока что нет возможности монопольного выделения устройств HVM-доменам.
[править] Паравиртуализация ввода/вывода для HVM-домена
Третий подход, использование паравиртуальных драйверов, можно выразить словами: если нельзя сделать паравиртуальной всю систему, то, может быть, можно хотя бы какую-нибудь её часть?
Системы с закрытым кодом, в частности Windows, нельзя паравиртуализировать (фактически, портировать на Xen) без желания их автора и/или владельца кода. Однако, никто не мешает (на самом деле это спорный и юридически скользкий вопрос) разработать какую-то свою собственную часть этой системы, которая будет работать по паравиртуальному принципу. То есть, не будет стараться не замечать то, что работает в системе особой архитектуры, а наоборот, будет стараться с ней сотрудничать. Этой частью являются паравиртуальные драйверы.
Грубо говоря, для обеспечения доступа, скажем, к сети, не нужно будет эмулировать сетевую карту чтобы драйвер гостевой системы понял как с ним работать — достаточно предоставить доступ к стандартному backend'у соответствующей подсистемы Xen.
Это позволяет сэкономить большое количество вычислительных ресурсов, которые обычно должны расходоваться на эмуляцию.
Например, тестирование, результаты которого представлены в [3], показало, что использование паравиртуальных драйверов позволяет значительно повысить производительность системы.
На рисунке (справа) показан результат тестирования в трёх режимах работы:
- FV — полная виртуализация;
- FV+NPT — полная виртуализация + nested paging;
- FV+NPT+PV — полная виртуализация + nested paging + паравиртуальные драйверы.
Если сравнить второй и третий результаты тестирования, можно заметить существенный прирост производительности, наблюдающийся при использовании паравиртуальных драйверов.
[править] См. также
 |
|
|---|
