Обычно пользователи "Линукса", вдоволь наперезагружавшись назад в Windows, начинают думать, какой поставить виртуализатор: VirtualBox, VMWare или что-то ещё? Не торопитесь. Установив "Линукс", а, скорее всего, это Ubuntu, вы, возможно, поставили и виртуальную машину. Всё зависит от "железа" и от... вас!

Мотивация

О том, что такое виртуальная машина (ВМ), имеющая собственную ОС, "Вести" писали неоднократно. Среди пользователей самым большим побуждением для установки ВМ в компьютер является простое любопытство к новым ОС или, наоборот, желание без перезагрузки запускать "виндовые" приложения после установки ОС Линукс. Но это далеко не единственное достоинство ВМ. Лично мне очень нравится "внежелезность" ВМ; ВМ на внешнем носителе - это верх приватности и изолированности. Вынул носитель - и никакой эксперт ничего не нароет.

Однако за всё надо платить: каждая ВМ занимает ресурсы компьютера. И, как будет показано, необходимо, чтобы процессор поддерживал ВМ аппаратно. Но пользователи покупают уже 4-х-ядерные компьютеры, а бОльшая часть уже уходящих в историю 2-х-ядерников и некоторые одноядерники тоже имеют такие процессоры! Поэтому продолжим.

Основы

Все способы организации ВМ базируются на аппаратно-программном дуализме: аппаратные вычисления можно выполнять программно, и наоборот.

Самый универсальный способ создания ВМ - эмуляция аппаратного обеспечения реального "железа" программными средствами. При этом в памяти машины-хозяйки ("хоста" на сленге) воссоздаётся образ реального процессора со всеми его регистрами и прочими атрибутами, а хост отдаёт ВМ часть своей памяти и дискового пространства. Если при этом эмулируются и устройства ввода-вывода, то это - "чистая виртуализация". Работает крайне медленно. Пример - эмулятор QEMU, к которому мы ещё вернёмся.

А почему гостевая ОС не может работать на реальном процессоре и использовать реальные физические устройства (последнее на сленге называется "пробросом" устройств)? Увы, на одном компьютере архитектуры x86 нельзя заставить работать две ОС одновременно. Ввод-вывод изначально спроектирован для монопольного использования лишь одной ОС, и как виртуальному процессору, работающему в третьем кругу привилегий, выполнять инструкции уровня ядра ОС хоста? Выход: надо подселить в нулевой круг нечто, что перехватывало бы исключения, выбрасываемые при попытках выполнения "плохих" инструкций и выполняло их как бы от имени основной ОС. Это "нечто" носит название "гипервизор". Он-то и осуществляет проброс ввода-вывода на физический уровень. Но в коде ядра гостевой ОС есть еще и непривилегированные инструкции, которые по-разному ведут себя в зависимости от контекста выполнения и не поддаются перехвату, так как исключения не генерируются. И опять выручает гипервизор: можно заставить его просматривать гостевой код "на лету" до выполнения и подменять "плохие" инструкции набором "хороших". Этот способ виртуализации получил название "полная виртуализация". Она, как и "чистая", изначально защищённая: код гостьи выполняется в пространстве пользователя и не может повредить ОС хоста. Но и тут ВМ работает медленнее реального прототипа: так как исполняемый код походу правится, то на этом теряется время. Существует два способа избежать правки кода "на лету".

Первый способ: раз гостевая ОС, работая, динамически рекомпилируется, то, исследовав её, можно предварительно поправить её навсегда - заменить содержащиеся в ней "плохие" инструкции набором "хороших". Так возникла "паравиртуализация" (от греческого "пара" - не такой, как все, нарушенный). Пример - XEN до 2006 г. Недостаток очевиден: так как требуется модифицировать гостевую ОС, то сразу возникают труднопреодолимые проблемы с лицензиями от разработчиков проприетарных ОС.

Второй способ более действенный и называется "аппаратная виртуализация". При этом методе работа гипервизора по отслеживанию "плохих инструкций" выполняется аппаратно самим процессором хоста (дуализм!) в особом гостевом режиме. На это способны процессоры, поддерживающие технологии Intel VT или AMD SVM. Скорость работы ВМ мало уступает скорости оригинальной машины. Правда, Intel VT и AMD SVM - не одно и то же. В интеловском подходе в процессор введены 10 новых инструкций для управления гостевым режимом и доступа в VMCS (управляющая структура, находится в памяти), куда предварительно заносятся "правки". У AMD всё реализовано ещё более аппаратно. В обеих системах вылавливание "плохой" инструкции производится путём её аппаратной дешифрации в гостевом режиме (подробнее см. xakep.ru/post/51718/default.asp). Существуют две разновидности аппаратной виртуализации: с поддержкой инструкций ввода-вывода "VT-d плюс VT-x" и без оной - только VT-x. Понятно, что более глубокая поддержка даёт прирост в скорости обмена с ВМ.

Аппаратная виртуализация не может обходиться без гипервизора, так как кто-то же должен настраивать VMCS и извещать процессор, что выполняется гостевая ОС. Но раз гипервизор - это программа, то почему бы не встроить её в ядро ОС хоста? Так и поступили. Вначале это был отдельный модуль-акселератор kqemu, загружаемый в память с помощью консоли. А с 2007 г. гипервизор встраивается в "Линукс". Начиная с ядра 2.6.20, появилась Kernel based Virtual Machine (KVM), которая позволяет запускать под "Линуксом" немодифицированные гостевые ОС на компьютерах с процессорами, поддерживающими VT. KVM представляет собой динамически загружаемый модуль ядра. Будучи активированной, КVМ порождает символьное устройство /dev/kvm. Однако эмулировать что-либо KVM не умеет, и этим занимается работающий на пользовательском уровне эмулятор QEMU. Его рассмотрим чуть позже. Успех KVM даже подвигнул некоторых гуру на портирование KVM в ОС Windows (см. mail-archive.com/kvm@vger.kernel.org/msg33488.html).

Чтобы узнать, поддерживает ли процессор вашего компьютера аппаратную виртуализацию, введите в терминале следующую команду:

egrep -c '(vmx|svm)' /proc/cpuinfo

Если ответом будет не ноль, то вам повезло, читайте статью дальше. Если нет, то сначала проверьте, не отключена ли аппаратная виртуализация на уровне BIOS вашего компьютера. Если отключена - включите. Если всё равно ответом будет ноль, то ставьте с официального сайта бесплатный VirtualBox, как интуитивно понятный и относительно быстрый, или меняйте процессор на "правильный". Впрочем, если вам нужны только MS-офисные приложения и ваш процессор "неправильный", то есть смысл ограничиться CrossOver'ом, заслуживающим отдельной статьи. Списки "правильных" процессоров смотрите на сайтах изготовителей и учитывайте, что один и тот же процессор, в зависимости от степпинга, может либо иметь поддержку аппаратной виртуализации, либо не иметь. Пример: процессор E5400 со степпингом AT80571AG0682M вообще не поддерживает VT, а другие его степпинги поддерживают, но только VT-x.

QEMU

Для работы KVM нужен эмулятор QEMU, но QEMU работает и без KVM. ОС Windows под чистым QEMU на среднем двухядернике работает так, как если бы она работала на каком-нибудь древнем P2-350. Зато список компьютеров, эмулируемых QEMU, очень широк. При запуске KVM+QEMU гостевая ОС ускоряется во много раз, но эмулируются только компьютеры Intel VT и AMD SVN, зато список гостевых ОС всё же шире, чем в других виртуализаторах.

В QEMU можно установить практически любую ОС, которая "видит" эмулируемый процессор, диски, которые на самом деле являются большим файлом в хосте, "видит" эмулируемую сетевую карту и т.д. После выключения ВМ всё это остаётся в хосте как один большой файл, называемый образом гостевой ОС. Его ещё называют виртуальным диском. Файл этот имеет расширение img. QEMU устанавливается из репозиториев тривиальной командой sudo apt-get install qemu. Для чистого QEMU разработано несколько GUI: QtEMU, KQEMU и другие, но они устарели и не работают с KVM. Если удручают терминальные команды, то сразу переходите к следующему разделу статьи, мы же кратко рассмотрим те из команд, которые наиболее важны для понимания идеологии QEMU. Вообще же подробную документацию на английском языке по терминальным командам для QEMU можно посмотреть здесь: wiki.qemu.org/download/qemu-doc.html.

Чтобы в хост установить образ ОС новой ВМ, сначала готовят для гостьи место в виде пустого образа виртуального диска, на котором гостья будет размещена. Для создания образов виртуальных дисков и управления ими QEMU располагает командой qemu-img, которая поддерживает разные форматы виртуальных дисков. Если специально не указывать, какой именно формат надо создать, то по умолчанию QEMU будет работать с файлом в так называемом сыром формате raw. Вот синтаксис терминальной команды qemu-img create, создающей пустой образ виртуального диска:

qemu-img create myimage.img mysize

Здесь myimage.img - это имя образа, а mysize - размер в гигабайтах. Формат raw наиболее экономно расходует поверхность реальных жёстких дисков, однако имеет проблемы с перемещением в другое место, да и работает медленно. Родным ("нативным" на сленге) форматом для QEMU является qcow2 (QEMU copy-on-write улучшенный), который обеспечивает максимальную гибкость и скорость QEMU. О других форматах можно почитать в en.wikibooks.org/wiki/QEMU/Images, мы же остановимся именно на qcow2. Чтобы образ имел этот формат, при создании пустого образа виртуального диска перед именем myimage.img вставляют опцию -f и через пробел добавляют параметр формата qcow2. Вот пример команды создания в домашней директории десятигигабайтного образа виртуального диска в формате qcow2 для последующей установки на него ОС Windows XP:

qemu-img create -f qcow2 winxp.img 10GB

После того, как для гостевой ОС подготовлен пустой образ диска, на него устанавливают эту ОС из ISO-образа, записанного на CD, DVD, флэшке или жёстком диске. Непустой образ *.img машины-гостьи в дальнейшем можно будет использовать многократно, при этом исходный ISO-образ гостевой ОС становится излишним. Установку гостевой ОС можно производить и из Интернета. В Интернете находится множество ISO-образов разных ОС, можно скачать понравившуюся и установить как гостевую, не прожигая CD, взяв образ, например, отсюда: wiki.qemu.org/Download #QEMU_disk_images. Конечно, можно установить ОС и из загрузочного диска, содержащего, например, файл WinXPSP3.iso. Чтобы ускорить установку, из ISO-образа записывают на другой CD содержащиеся в нём файлы. После того, как ISO-образ вставлен в CD-привод и CD автоматически смонтировался, установка Windows может быть начата такой строкой в терминале:

qemu -m 696 -hda winxp.img -cdrom /media/WinXPSP3/WinXPSP3.iso -boot d

Здесь: -m 696 означает, что из ОЗУ хоста для гостьи выделяется 696 Мб памяти. -hda winxp.img означает место, куда будет ставиться гостевая ОС, точнее, она будет ставиться на виртуальный диск C:. -cdrom /media/WinXPSP3/WinXPSP3.iso означает, что гостевая ОС будет ставиться из подмонтированного CD-привода. -boot d означает, что источником установки является виртуальный CD-привод, ассоциирующийся с виртуальным диском D:. Пары аргументов можно переставлять как угодно - парсер разберётся. Вместо адреса /media/WinXPSP3/WinXPSP3.iso можно просто указать /dev/cdrom, если ISO-образ ОC реально находится на CD. Если ISO-образ находится на жёстком диске, то нужно указывать адрес в файловой системе машины-хозяйки, например, ~/WinXPSP3.iso.

Итак, запустилась установка ОС: открылось окно QEMU, пошла разметка пустого образа winxp.img под NTFS, копируются файлы, инициализируется конфигурация будущей Windows, система просит рестарта, но кнопки рестарта виртуальной машины нет, и она висит в ожидании. Теперь надо запустить загрузку гостьи с виртуального диска C: (он создался!), сохранив, однако, доступ к источнику, т.е., к CD-приводу, иначе сервис-пак SP3 окажется невидимым. Поэтому закрываем окно QEMU, меняем в CD-приводе ISO-диск на диск с нормальными установочными файлами и в терминале даём команду:

qemu -m 696 -hda winxp.img -boot c -cdrom /dev/cdrom

На время установки следует запастись терпением: каждая виртуальная минута равна нескольким реальным - эмулятор всё-таки. Если имеется 2 экрана, то целесообразно переместить окно QEMU на другой экран, чтобы приглядывать за установкой гостьи и заниматься своими делами на первом экране. На современном компьютере потребуется час-полтора. Наконец, гостевая ОС встала! Можно перезапустить её внутри "Линукса", что выполняется следующей терминальной строкой:

qemu -m 696 -boot c ~/winxp.img

"По вкусу" в строку запуска через пробелы можно добавлять и другие аргументы, например: -full-screen -localtime -cdrom /dev/cdrom -soundhw sb16. Здесь: -full-screen суть полноэкранный режим гостевой ОС, -localtime - доступ к локальному времени машины-хозяйки, а знакомая пара -cdrom /dev/cdrom означает доступ к её реальному CD-приводу. -soundhw sb16 - это доступ к звуковой карте. Можно добавить доступ к сетевой карте, флоппи-приводу, флэшкам и т.д. - всё это смотрите в терминале командой man qemu или читайте документацию. Если ваш Линукс 64-разрядный, то слово qemu заменяется на слово qemu-system-x86_64.

Небольшие замечания. Учтите, что второй экземпляр QEMU запустить нельзя! Учтите также, что QEMU не поддерживает одновременно аргументы -hdc и -cdrom, так как оба представляют первое устройство на вторичном IDE-канале. Если ваша гостья не имеет сети, то обмен с ней можно организовать путём монтирования реального привода и последующего обмена файлами с ним. И никогда не занимайтесь перемонтировкой виртуального диска во время работы QEMU с ним, иначе рискуете повредить файловую систему в нём.

KVM настраивается точно так же, как и QEMU, но слово qemu заменяется словом kvm. CLI ужасен, не так ли?

AQEMU

К счастью для QEMU и KVM, имеется замечательный GUI, написанный на языке QT4 специалистами из Nokia; называется он AQEMU, лежит в репозиториях, устанавливается тривиально: sudo apt-get install aqemu или же мышкой с помощью Центра приложений Ubuntu. В AQEMU всё, что выше настраивалось терминальными командами, настраивается мышью. Чтобы работать с AQEMU, на вашем компьютере предварительно должны быть установлены библиотека Qt версии не ниже 4.4.2 и эмулятор QEMU версии 0.9.0 или выше. Русская документация находится здесь: sourceforge.net/projects/aqemu/files/AQEMU%20Russian%20Documentation/0.7.3/AQEMU-Documentation-0.7.3.tar.bz2/download. АQEMU в настоящее время также русифицирован. Кроме того, AQEMU имеет мастер первого запуска, который позволяет отыскать все установленные на вашем компьютере эмуляторы: "Файл > Мастер первого запуска > Далее > Далее > Поиск".

Если вы прочитали предыдущий раздел, то без труда разберётесь с настройками. Если нет - читайте документацию, там всё подробно изложено и нет смысла дублировать рекомендации в статье. Чтобы включить KVM, на вкладке "Основные" в выпадающем списке "Тип эмулятора" следует выбрать KVM, затем там же следует выбрать версию эмулятора. Возможно, модуль KVM отсутствует в памяти, и настроенная ВМ не запустится, тогда надо принудительно загрузить этот модуль командой sudo modprobe kvm-intel, если у вас интеловский компьютер, или командой sudo modprobe kvm-amd, если у вас компьютер с процессором AMD.

Недостатки у KVM, конечно, есть. Первый подводный камень: обновив ядро машины-хозяйки, вы неожиданно обнаруживаете, что гостья под KVM отказывается работать. Так и должно быть: гостья использует старое ядро, которого уже нет. Поэтому после обновления ядра хозяйки приходится или создавать образ гостьи снова, или, пользуясь загрузочным меню хозяйки, загружать хозяйку с прежним ядром. Впрочем, этот недостаток присущ и полным эмуляторам. Второй подводный камень: не пытайтесь запустить другой виртуализатор, скажем, VirtualBox, если в памяти находится работающий модуль KVM. Его сначала надо выгрузить из памяти командами sudo rmmod kvm и sudo rmmod kvm-intel (или sudo rmmod kvm-amd, если компьютер с процессором AMD). Наконец, KVM вкупе с QEMU допускает "нечестную" эмуляцию, при которой ВМ требует ресурсов больше, чем имеет ваш компьютер, например, процессор ВМ содержит больше ядер. При этом вместо ускорения вы получаете резкое замедление.

А фишка где?

Результаты сравнения тестирования KVM vs VirtualBox можно посмотреть в phoronix.com/scan.php?page=article&item=linux_kvm_virtualbox4&num=1. При этом VirtualBox также использовал аппаратную виртуализацию. В синтетических тестах KVM явно превосходит VirtualBox. В то же время результаты голосования "какая ВМ лучше" говорят об обратном, эти результаты приведены здесь: ubuntuforums.org/showthread.php?t=1145462. Победил VirtualBox. Парадокс? Нет. Дело в том, что голосование больше отражает уровень продвинутости конкретных убунтоидов, чем реальные достоинства той или иной ВМ. Но это голосование ценно тем, что позиции участников хоть как-то аргументированы, при этом пользователи нередко признавались: "KVM не пробовал...". Так пробуйте же!

Михаил ГУРЧИК,
gor-mike@tut.by