Паравиртуальные драйверы 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]

September-2007-Kiev-CPU-market.png

Большинство из этих процессоров имеют архитектурные расширения аппаратной виртyализации. Если быть более точным, распределение таково:

  • без аппаратной виртуализации — 37%;
  • аппаратная виртуализация Intel — 27%;
  • аппаратная виртуализация AMD — 36%.

September-2007-Kiev-CPU-HVM.png

Таким образом, более 60% представленных на рынке сейчас способны выполнять аппаратную виртуализацию. Вероятно, тенденция будет только усиливаться и в скором времени таких процессоров будет подавляющее большинство.

Note-icon.gif

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

[править] Аппаратная виртуализация и ввод/вывод

Сравнение производительности Xen и других систем. Linux (L), Xen/Linux (X), VMware Workstation 3.2 (V) и User Mode Linux (U)

При аппаратной виртуализации гостевая операционная система получает вычислительные ресурсы практически без потерь. Величина потерь в этом случае соизмерима с потерями при паравиртуализации. Они меньше, чем в случае чистой программной виртуализацией.

Тем не менее, при аппаратной виртуализации операционная система, запущенная в гостевом домене Xen работает медленно. В этом легко убедиться — достаточно посмотреть как работает, например, Windows в домене Xen (это относится не только к Windows, а ко всем системам, работающим в режиме аппаратной виртуализации).

Чем обусловлено такое замедление работы системы?

Аппаратная виртуализация берёт на себя основные трудности по переключению контекстов гостевых операционных систем и хост-системы, но она ничего (пока что) не делает для ускорения ввода/вывода. Как только задача требует ввода/вывода любая система виртуализации (но не паравиртуализации!) существенно замедляет свою работу.

Например, результаты известного сравнения производительности систем паравиртуализации и виртуализации [2] произведённого ещё несколько лет назад в сетевой лаборатории Кембриджского университета (рисунок справа) хорошо демонстрируют тот факт, что системы виртуализации и паравиртуализации работают на максимальной скорости при выполнении чисто вычислительных задач, но как только работа требует ввода/вывода, виртуализация начинает существенно отставать.

Существует три основных способа обеспечения ввода/вывода (и, фактически, доступа к оборудованию) для гостевой операционной системы:

  1. Эмуляция устройств со стороны домена 0 и использование традиционных драйверов в гостевой системе;
  2. Монопольное выделение устройств гостевой системе;
  3. Использование паравиртуальных драйверов.

[править] Эмуляция устройств для 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-доменов (доменов, использующих аппаратную виртуализацию), это:

  1. Требует аппаратной поддержки;
  2. В настоящий момент реализовано только в экспериментальном виде в Xen-unstable.

Полноценная поддержка монопольного выделения устройства HVM доменам появится в версии 3.2.0, выход которой запланирован на начало 2008 года.

Что касается аппаратной поддержки, она есть, но пока что достаточно редка.

Сейчас есть как минимум две платы производства Intel (DQ35MP и DQ35JO), которые поддерживают собственную реализацию аппаратной виртуализации ввода/вывода известную как Intel VT-d (не путать с Intel VT!).

В AMD тоже ведётся работа над собственной реализацией аппаратной виртуализацией ввода/вывода, IOMMU.

Резюмирую вышесказанное, фактически, пока что нет возможности монопольного выделения устройств HVM-доменам.

[править] Паравиртуализация ввода/вывода для HVM-домена

Сравнение производительности Oracle в трёх режимах работы

Третий подход, использование паравиртуальных драйверов, можно выразить словами: если нельзя сделать паравиртуальной всю систему, то, может быть, можно хотя бы какую-нибудь её часть?

Системы с закрытым кодом, в частности Windows, нельзя паравиртуализировать (фактически, портировать на Xen) без желания их автора и/или владельца кода. Однако, никто не мешает (на самом деле это спорный и юридически скользкий вопрос) разработать какую-то свою собственную часть этой системы, которая будет работать по паравиртуальному принципу. То есть, не будет стараться не замечать то, что работает в системе особой архитектуры, а наоборот, будет стараться с ней сотрудничать. Этой частью являются паравиртуальные драйверы.

Грубо говоря, для обеспечения доступа, скажем, к сети, не нужно будет эмулировать сетевую карту чтобы драйвер гостевой системы понял как с ним работать — достаточно предоставить доступ к стандартному backend'у соответствующей подсистемы Xen.

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

Например, тестирование, результаты которого представлены в [3], показало, что использование паравиртуальных драйверов позволяет значительно повысить производительность системы.

На рисунке (справа) показан результат тестирования в трёх режимах работы:

  1. FV — полная виртуализация;
  2. FV+NPT — полная виртуализация + nested paging;
  3. FV+NPT+PV — полная виртуализация + nested paging + паравиртуальные драйверы.

Если сравнить второй и третий результаты тестирования, можно заметить существенный прирост производительности, наблюдающийся при использовании паравиртуальных драйверов.

[править] См. также

Xen
Xen

Виртуализация и паравиртуализация
Эмуляция | Виртуализация | Паравиртуализация | Рекурсивная виртуализация
Паравиртуальные драйверы | Виртуализация ввода/вывода

Общие вопросы по Xen
Аппаратные требования Xen | Поддержка Xen операционными системами | Поддерживаемые аппаратные архитектуры |
Примеры использования Xen | Сравнение виртуальных машин |
Хостинг на Xen
Альтернативы Xen

свободные: KVM | LXC | OpenVZ | VServer | QEMU | VirtualBox
проприетарные: Hyper-V | VMware ESX Server

Технические вопросы
Инсталляция Xen | Конфигурационный файл домена
ОС в Xen: Linux small icon.png Linux | Solaris small icon.png OpenSolaris | Freebsd small icon.png FreeBSD | Openbsd small icon.png OpenBSD | Netbsd small icon.png NetBSD | Windows xp small icon.png Windows XP | Windows vista small icon.png Windows Vista
Устройства: Блочные | USB | SCSI | Сеть | PV-драйверы для Linux | PV-драйверы для Windows | Консоль

Распределение ресурсов между доменами | Перенос системы внутрь Xen | HVM -> PV

Управление и кластеризация | Enomalism | Xen+DRBD | Ganeti | Convirt 2.0 | SkyCover Infrastructure