Материал из Linuxformat.

Текущая версия

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

Прорыв в виртуальность

Аппаратная виртуализация позволяет запускать различные операционные системы на Linux одновременно, с высокой скоростью и бесплатно. Говорят об этом все; Пол Хадсон покажет вам, как сделать это.

Linux — это выбор: вы можете выбрать рабочий стол, выбрать браузер и даже выбрать логотип, который будет появляться при загрузке. Но основной выбор, без сомнения, самый сложный: какой дистрибутив лучше всех? Если вы похожи на нас, то, вероятно, скачете между дистрибутивами так же быстро, как Майк успевает выкладывать их на диск Linux Format; но настает время в вашей жизни, когда вам надоест делать переформатирование и вы начнете искать более разумный способ экспериментировать с новыми ОС. Этот способ – виртуализация: запустите множество ОС на одном компьютере и переключайтесь между ними с той же легкостью, как между программами.

Идея виртуализации не нова: VMware существует с 1999 года, и мы опубликовали две большие статьи про Xen за последние два года (LXF67 и LXF77). Теперь, впрочем, производители процессоров создали виртуализацию на кристалле (on-chip). Работа ОС в виртуальной машине (ВМ) будет явно медленнее, чем на чистом компьютере, так что если вы сможете заставить процессор выполнять эту работу, весь процесс ускорится – по крайней мере, теоретически. Конкурирующие решения от Intel (VT или Virtualisation Tethnology, технология виртуализации) и AMD (SVM, илиSecure Virtual Machines, безопасные виртуальные машины) начали поставляться с их процессорами, и наконец-то предприятия, любители новшеств и экспериментаторы среди вас могут попробовать виртуализацию, поскольку для этого она и предназначалась.

Прорыв

Аппаратная виртуализация может, наконец, решить простую, но неприятную проблему: процессоры x86 не умеют выполнять виртуализацию хорошо. От выпуска 386-го до последнего, основанного на Core 2, чипа Intel изменилось немногое – набор базовых инструкций тот же, то есть код, скомпилированный для 386, также будет работать на новейшем оборудовании от Intel и AMD. На самом деле новые функции, например, MMX, SSE, двойные ядра и 64-битная обработка, просто были «прикручены» к существующей архитектуре x86, чтобы не обесценивать вложения пользователей и предприятий.

Но это также означает, что сохранились старые недостатки. До VT и SVM все чипы x86 использовали четыре уровня (кольца) привилегий для исполнения. На уровне 0 работали наиболее привилегированные процессы (обычно ОС), а на уровне 3 – наименее привилегированные (обычно приложения пользователя). Это способствовало безопасному разделению привилегий на аппаратном уровне: только приложения уровня 0 (нулевого кольца) могут напрямую управлять оборудованием, что теоретически не позволяет приложению выполнить что-то фатальное для машины. Но на практике приложениям часто нужен доступ к оборудованию, так что они нуждаются в вызовах ОС и запрашивают ресурсы, например, побольше памяти или отрисовку трехмерной графики.

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

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

Аппаратная виртуализация устраняет эту проблему раз и навсегда, за счет создания нового набора уровней привилегий, которые размещаются позади традиционных уровней. Новые уровни (известные как VMX Root) становятся реальными привилегированными уровнями, в то время как старые уровни (известные как VMX Nonroot) виртуализируются чипом и используются там, где работают гостевые ОС. Когда гостевая ОС спрашивает «на каком уровне я нахожусь?», чип может честно ответить «уровень 0», потому что он действительно работает на уровне 0 – только это нулевое кольцо виртуальное. Таким образом, все гостевые системы могут работать, не прибегая к двоичной трансляции, поскольку они не замечают разницы между уровнем 0 реальной машины и уровнем 0 внутри VMX Nonroot.

Поскольку это передовая технология, аппаратная виртуализация поддерживается не всеми чипами. В случае с Intel все новые чипы, основанные на Core 2, поддерживают аппаратную виртуализацию VT. Некоторые чипы постарше также работают, но подавляющее большинство чипов Pentium 4 не совместимы с VT. Что касается AMD, то только новейшие чипы, основанные на AM2, поддерживают технологию Secure Virtual Machines. Линейка Opteron должна обновиться вконце этого года, но сейчас SVM поддерживают только новые Athlon64 и Turion 64.

Интересно заметить, что хотя VT и SVM решают одну и ту же проблему, они работают совершенно по-разному: чипы AMD64 имеютинтегрированный контроллер памяти, а Intel держит его на северном мосту. На практике это означает, что чипы Intel должны виртуализовать контроллер памяти программно, тогда как AMD может делатьэто аппаратно, обеспечивая еще больший потенциал для повышенияскорости виртуализации.

Да, Xen все еще нужен

Размещение поддержки виртуализации на процессоре не отменяет потребности в программном обеспечении типа VMware или Xen, потому что все, что находится за пределами процессора (и контроллера памяти, в случае с AMD), по-прежнему нужно виртуализовать. Видеокарта, звуковая карта, жесткие диски и т.д. нуждаются в программной обработке, и здесь системы виртуализации все еще при деле. Наряду с VMware и Xen вы можете также использовать Qemu и Parallels Workstation, но хотя вся четверка предоставляет полную эмуляцию оборудования, кроме процессора, Qemu не имеет никакой поддержки технологий виртуализации Intel и AMD, и его производительность страдает.

Зачем виртуализировать?

• Для домашних пользователей: Сыты по горло переустановкой дистрибутивов? Запустите один маленький дистрибутив как Domain-0, затем виртуализуйте поверх него любые другие дистрибутивы.

• Для программистов: Нужно протестировать вашу программу на различных дистрибутивах, операционных системах и настройках? Легко: создайте столько виртуальных машин, сколько у вас платформ, затем разработайте набор тестов для запуска по ночам.

• Для администраторов серверов: Застряли на 25%-ной загрузке сервера? Используйте виртуальную инфраструктуру для снижения времени простоя, увеличения гибкости и моментального предоставления ресурсов для всех ваших задач.

Xen против VMware

Наиболее явное отличие между Xen и VMware в том, что Xen устанавливает себя как основную ОС компьютера и загружается, когда включается компьютер. Когда ОС Xen запустится, она создаст свою первую виртуальную машину с операционной системой, известную как Domain-0. Она имеет особые привилегии доступа к оборудованию и имеет полное управление над любыми гостевыми системами, вызываемыми после нее.

В VMware ваша первоначальная ОС остается неизменной – VMware запускается как приложение поверх исходной ОС, переключая ее в режим хоста. Новые виртуальные машины создаются поверх хост-ОС как гостевые, и запускаются внутри приложения VMware.

Какая из этих двух идей лучше – вопрос спорный; но мы склоняемся в сторону подхода Xen, поскольку если в хост-ОС на VMware обнаружатся проблемы (или она рухнет), все виртуальные машины «завалятся» вместе с ней.

Между прочим, профессиональная версия VMware – VMware ESX Server – работает во многом подобно Xen, так что, возможно, люди VMware тоже считают это лучшим подходом!

Попробуйте сами

Это будет серьезной технологией 2007 года – испытайте ее сегодня и приплюсуйте к своему счетчику крутизны солидную добавку.

Есть чип, поддерживающий VT/SVM? Отлично! Вы в нескольких минутах от запуска Windows в Linux при помощи аппаратной виртуализации. Это можно сделать двумя способами: через Vmware — тогда виртуализация получится мгновенно, но это закрытая программа, не позволяющая модифицировать аппаратную часть во время работы; или через Xen, который полностью открыт, поставляется включенным в ряд основных дистрибутивов, но потребует некоторых усилий, чтобы заставить его работать. Хотя мы пытались заставить Parallels Workstation работать с VT, это почти всегда заканчивалось зависанием — приглашаем вас попробовать самим, и если вы заставите его работать, сообщите нам.

Нашими тестовыми машинами с Xen были двухпроцессорный Intel Xeon 5160 (итого четыре ядра), с 8 ГБ памяти, и AMD Athlon 64 X2 5000+ с 1 ГБ памяти. На момент написания статьи новый чип Xeon 5160 на базе Woodcrest/Core 2 был старшим серверным чипом от Intel, а машина AMD ориентировалась на домашних пользователей – все результаты тестирования, которые здесь напечатаны, лучше использовать для сравнения одной машины, работающей под «чистой» ОС, с той же машиной под управлением виртуализованной ОС, а не сравнивать Intel и AMD.

Наша тестовая платформа

Мы установили SUSE 10.1 на обе машины, используя 32-разрядные хосты и 32-разрядные гостевые ОС. SUSE 10.1 – превосходный выбор для испытания Xen, поскольку она поставляется с пакетами ядра Xen, устанавливаемыми через Yast. Также здесь есть специальный графический интерфейс для установки и настройки виртуальных машин, но на момент написания статьи он не работал – так что мы делали все вручную.

Шаг за шагом: запускаем VT- или SVM-виртуализацию с помощью Xen

• Установите пакеты Xen

Из Yast, поищите «kernel-xen», и вы увидите два пакета: kernel-xen и kernel-xenp-ae (см. ниже «Обратите внимание»). Вам также понадобятся cloop-kmp-xen, xen, xen-libs, xen-tools и xen-tools-ioemu, и любые дополнительные драйверы, какие пожелаете.

• Перезагрузитесь

Перезагрузите свой компьютер и выберите Xen – SUSE LINUX 10.1, когда появится загрузочное меню Grub. Пролетит кое-какой текст, и ваш компьютер загрузится как обычно. Не беспокойтесь, если исчезнет графическая заставка вашей SUSE: это не является дурным знаком.

• Проверьте установку

Поздравляем – вы загрузились в Xen! Вы можете проверить это, открыв консоль и запустив команду uname -a. Ваша версия ядра должна теперь походить на 2.6.16.13-4-xen.

• Настройте работу с ОЗУ

Запустите xm list для получения информации о Domain-0. Вы можете использовать xm mem-set Domain-0 500, чтобы назначить ему 500 М памяти. Можете также использовать xm vcpu-set Domain-0 1, чтобы задать ему один процессор. Изменения вступят в силу немедленно, так что вы сразу увидите, если памяти не хватает!

• Откройте файл конфигурации

Из командной строки скопируйте /etc/xen/examples/xmexample.hvm в /etc/xen/winxp.hvm, затем откройте winxp.hvm в своем любимом редакторе от имени root. Мы должны сконфигурировать его, чтобы запустить Windows.

• Настройте XP

Установите «memory» в значение в МБ для этой ВМ, а «name» – в уникальное значение, хотя бы «WinXP». Отредактируйте строку «disk» так, чтобы он указывал на winxp.img. Установите «cdrom» в значение /dev/cdrom, «boot» в d, «sdl» в 1, «vnc» в 0 и «vncviewer» в 0. Удалите любые символы # из начала этих строк.

• Создайте виртуальный жесткий диск

Отведите вашей системе XP пространство на диске, переключившись в каталог /etc/xen/images и выполнив команду dd if=/dev/zero of=winxp.img bs=1k seek=4096k count=1. Она создаст виртуальный диск размером 4 ГБ, который можно будет смонтировать как loopback-устройство внутри Xen.

• Финал: Windows на Linux!

Теперь выполните команду xm create winxp.hvm из каталога /etc/xen, и – если все будет нормально – появится окно с запущенным инсталлятором Windows. Будьте осторожны: этот шаг самый рискованный из всех; рекомендуем сперва выполнить команду sync и убедиться, что буфер вашей файловой системы очищен [также подразумевается, что установочный диск Windows XP вставлен в CD-ROM, – прим. ред.].

Выявление неисправностей

Xen на VT/SVM сейчас довольно сложен – мы обнаружили многочисленные зависания, падения и ошибки, пока писали эту статью. Обычно это ошибка пользователя, но Xen любезно умалчивает об этом. Вот решение некоторых из общих проблем:

Обратите внимание

Windows XP на Xen работает, только если ваш процессор входит в следующий список:

Intel:

• Core Duo
• Core 2 Duo
• Pentium Extreme Edition 955/965
• Pentium D 920/930/940/950/960
• Xeon 5030/5050/5060/5063/5080/5160/7020/7030/7040/7041

AMD:

• AM2-based Athlon 64s
• AM2-based Athlon 64 X2s
• Athlon 64 FX-62

Имеете ОЗУ больше 4 ГБ?

Если ваша машина имеет более 4 ГБ памяти, вы, вероятно, уже используете Linux-ядро с PAE (Physical Address Extension). Некоторые дистрибутивы именуют такие ядра по типу linux-kernel-pae или kernel-bigsmp. Устанавливая свое ядро Xen, используйте также и ядро PAE Xen, иначе ваши гостевые системы в Xen не смогут получить доступ более чем к 4 ГБ ОЗУ.

Насколько быстра аппаратная виртуализация?

Легко утверждать, что «это» быстрее, чем «то» – но вот холодные, неоспоримые факты.

Получить графики испытаний аппаратной виртуализации – задача не простая: фактически, потребовалось две недели на установку, настройку, переустановку, копирование и тестирование на обеих наших машинах, чтобы получить то, что мы считаем окончательными результатами. Кроме того, не забывайте, что реально мы можем сравнивать только Intel с Intel, а AMD — с AMD, поскольку эквивалента AMD64 для поддерживающего VT чипа Xeon пока нету. Более того, большинство этих тестов автоматически получают преимущества от дополнительных ядер там, где они доступны, так что баллы Intel будут с учетом четырех ядер по сравнению с двумя ядрами Athlon 64.

Мы провели в общей сложности восемь тестов, используя шесть сценариев и две машины. Каждый тест на каждой машине запускался на «родной» ОС, в гостевом домене Xen (xenU) и внутри виртуальной машины VMware. Поскольку нас особенно интересовала аппаратная виртуализация для этих функций, большинство тестов использовало Windows XP в качестве гостевой ОС, за исключением теста кодирования Ogg: тут использовалась SUSE 10.1.

Помимо установки монитора виртуальной машины и гостевой ОС, выполнялась небольшая дальнейшая настройка системы. Как для VMware, так и для Xen выделялся одинаковые объем ОЗУ и место на диске для работы, и от обоих требовалось предоставить виртуальную сетевую карту; обоим дана свобода управлять процессорами как они сочтут нужным. Одно небольшое исключение было сделано для Xen, запускаемого на машине Intel, поскольку Intel VT, похоже, имеет проблемы с чипсетом Cirrus Logic, эмулируемым Xen (см. врезку «Заставь работать VT-графику»).

Интерпретация результатов

Сравнивать «чистый» Intel с «чистым» AMD несправедливо: чип Intel имеет в два раза больше ядер и в восемь раз больше ОЗУ. Но мы можем рассмотреть различие в скорости между чипами Intel и AMD, когда они работают виртуально. Средняя скорость чипа Intel, управляемого гостевой ОС через Xen, составила 43,7% от «чистого», по сравнению с 45,5% на VMware. На AMD результаты поднялись до 63,6% для Xen и 73% для VMware.

Это отчасти объясняется интегрированным в AMD контроллером памяти: тогда нужно программно реализовывать одним устройством меньше. Но другой фактор, заслуживающий внимания – тот, что тесты используют конфигурацию «из коробки», и оба приложения управляют ресурсами гостевых ОС в свободном полете. В случае с Xen вы можете, например, отдать виртуальной гостевой ОС весь процессор, и многопоточным тестам будет куда вольготнее.

Тесты

Вердикт Это одна из областей, где Xen должен быть на коне: была бы производительность процессора высока, а Xen просто работает как тонкая прослойка между гостевой ОС и хостом.

Вердикт Неудача постигла VT от Intel, разница в скорости по сравнению с «чистым» оборудованием – почти вдвое. На AMD разница минимальна. Только VMware хорошо держит темп на обеих платформах.

Вердикт Xen на Intel дает менее 33% от скорости чистого оборудования Intel, в основном из-за слабой эмуляции графики. AMD справился с тестом лучше, благодаря виртуализованному контроллеру памяти.

Вердикт Запускаясь в первый раз, ОpenOffice.org 2.0 буквально истязает жесткий диск, но VMware и здесь умудряется вывернуться с очень приличным результатом.

Вердикт Чистый Intel властвует в этойкатегории, но при виртуализации заметно резкое падение. Для сравнения, AMD при виртуализации замедляется не более чем на 50%.

Вердикт Чип Intel превосходен при работе с «чистой» ОС, но отстает на виртуальных машинах. Результаты AMD близки к его результатам Dhrystone, лишь с небольшим отставанием.

Вердикт Новое серверное ядро Woodcrest от Intel вызывающе быстро, но плохо уживается с виртуализацией. У AMD падение куда менее драматичное. Самые лучшие показатели здесь у VMware.

Вердикт AMD не намного обошел Intel в «чистом» режиме, но «сокрушил» его как под Xen, так и под VMware. Опять-таки, аппаратная виртуализация контроллера памяти – существенное отличие.

Лучше не бывает?

Следите за этой областью: впереди еще долгий путь, и аппаратная виртуализация будет становиться лучше и лучше.

Увлекательные сами по себе, наши диаграммы показывают, что неоптимизированная аппаратная виртуализация в ряде тестов отстает от ОС, запущенных в «чистом» виде. Конечно, теперь можно запустить любую ОС поверх другой ОС, но для первой попытки, производительность здесь еще недостаточная. Можно достичь хорошей скорости, вручную подстроив виртуальные машины и отведя им процессорные ядра, но это довольно утомительно — особенно сейчас, когда многоядерные архитектуры скорее стандарт, чем исключение. Вдобавок ручная оптимизация лишает виртуальную инфраструктуру свойственной ей гибкости. Поскольку Xen и VMware расширили свою поддержку для VT и SVM, в частности, для лучшей обработки многоядерных сценариев, мы надеемся, что наши цифры немного поднимутся, но в конечном итоге для достижения полноскоростной виртуализации нужно реформировать оборудование.

Как мы видели, виртуализуемый контроллер памяти – огромное подспорье для AMD, поскольку программно требуется эмулировать на одну вещь меньше. Виртуализация высокоскоростных устройств - ключ к снижению общей латентности системы, и неудивительно, что Intel уже работает над следующей версией VT, где появится штука, называемая Directed IO и разработанная, чтобы поддержать аппаратную виртуализацию мириадов наших обычных устройств ввода-вывода – клавиатуры, мыши и устройств USB.

При наличии поддержки аппаратной виртуализации ввода-вывода останется решить только одну проблему: нужна виртуальная графическая система, способная обеспечить гостевым машинам приличное ускорение графики. Сейчас большинство гостевых ОС привязаны к эмуляции графического уровня Cirrus Logic, которая ощутимо тормозила наши тесты по части графики. При такой слабой 2D-графике безнадежно запускать на гостевой ОС графически богатые приложения, так что трехмерное моделирование, игры и даже окружение рабочего стола уровня 2.5D/3D, например, Xgl и Windows Vista, не поддерживаются.

Пока Intel работает над следующим поколением VT, инновации происходят и в программном обеспечении, которое обеспечивает прогресс виртуализации. Xen 3.0 принес с собой огромные улучшения, включая поддержку VT и SVM, что позволило нам написать эту статью. Он также ввел приличную поддержку SMP, большую производительность памяти и порт для Itanium. Но есть кое-какие интересные вещи, все еще находящиеся на стадии разработки, которые могут увидеть свет в следующем крупном релизе Xen.

Большие скачки ПО

Список интересных новых функций возглавляет виртуализованная графическая подсистема, использующая ПО, а не оборудование. Чтобы обеспечить базовое ускорение графики, используются разделяемые буферы кадров, и есть шансы, что мы увидим даже виртуализованный OpenGL, доступный современным трехмерным графическим интерфейсам. Другая область, где, похоже, разра ботки ведутся интенсивно – качество обслуживания: разработчики Xen хотят, чтобы виртуальные машины сами балансировали себя на доступных процессорах, а также эффективнее использовали ОЗУ.

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

Следующий шаг

Возможно, самые значительные новые разработки имеют место в ядре Linux, а не в самом Xen. Xen очень близко подошел к слиянию с основным ядром, которое сделало бы Xen доступным в каждом дистрибутиве как стандарт. Сейчас дистрибутивы, поставляющие Xen – например, Red Hat и SUSE – должны включать его в свои ядра. Но планируется создание независимого от поставщиков интерфейса к виртуализации ядра, тогда Xen, VMware и вообще любой разработчик виртуализации смогут включить свою систему в ядро Linux. Чтобы это сработало, потребуется некоторая степень согласования между Xen и VMware, и обе команды близки к этому. Их конечные цели совпадают, как во многом совпадают и их коды, но потребуется некоторая работа, чтобы завершить объединение оставшихся 25% или около того, пока не будет готово совместное решение.

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

Xen уже включен как стандарт в SUSE 10.1 и Fedora Core 5, и, вероятно, сейчас будет включаться и в другие дистрибутивы: Xen 3.0 достаточно стабилен, чтобы считаться свободным от ошибок. Марк Шаттлворт сказал, что он хочет видеть ряд захватывающих функций в следующем релизе Ubuntu, и мы думаем, что можно держать пари – Xen будет одной из них. Вдобавок и SUSE, и Red Hat обдумывают идею сделать Xen доступным по умолчанию в своих дистрибутивах, это даст возможность за пять минут устанавливать новые гостевые домены, поскольку машина уже будет виртуализована. Поскольку основной домен Xen (известный как Xen0) имеет больше привилегий по управлению оборудованием, расплачиваться за это скоростью практически не придется – и это действительно очень заманчивая перспектива.

Как только аппаратная виртуализация сумеет превысить 90% производительности по сравнению с «чистым железом» без ручной подстройки файлов конфигурации, уклоняться от виртуализации станет практически незачем. Установка ВМ для базы данных и ВМ для web-сервера на одном и том же оборудовании и передача динамического назначения требуемых процессоров и памяти на откуп Xen или VMware будет способствовать значительной экономии – и в серверном зале, и дома. Вам больше не понадобится машина для Linux, машина для OS X и машина для Windows, и использование сервера на 25% не будет больше считаться средним значением. Вместо этого мы сможем разместить все наши операционные системы на одном центральном компьютере дома и получать доступ к нашему рабочему столу в любом месте, где есть сетевое подключение. Обещания VT и SVM станут реальностью – в смысле, виртуальной реальностью. LXF

Как добиться максимальной производительности

Как мы видим, и Xen, и VMware борются за достижение максимальной производительности, когда работают на нескольких ядрах, но если вы готовы пожертвовать некоторой гибкостью, вы можете достичь максимума, вручную настроив ваши ВМ. Самое простое, что можно сделать – найти настройку vcpus в файле конфигурации Xen и изменить ее так, чтобы она соответствовала общему числу ядер на вашей системе. Если у вас машина с поддержкой HyperThreading, вам, возможно, захочется ради эксперимента удвоить число vcpus и выяснить, поможет тут HT или нет.

Итак, на одноядерном Athlon 64 установите vcpus в 1, а на двухядерном, двухпроцессорном поддерживающем HyperThreading Xeon начните с четырех vcups и затем попробуйте перейти на восемь, чтобы посмотреть, будет ли заметно повышение производительности. Заметьте, что HyperThreading обновилась с SSE3 («Новые инструкции Prescott»). Раньше некоторые приложения шли с HT быстрее, а некоторые – медленнее, но после обновления набора команд скорость в худшем случае просто не изменится.

А как же Qemu?

Qemu – превосходная и давно известная программа эмуляции, которая позволяет запускать Windows (или любую другую ОС) внутри виртуальной машины. Несколько лет она являлась приложением с открытым кодом, но поскольку она только эмулирует операционные системы (т.е. транслирует их программно), а не виртуализует их (т.е. запускает их на самом чипе), она всегда работала довольно медленно. Однако ее создатель реализовал модуль виртуализации, позволивший Qemu работать гораздо быстрее – с оговоркой, что это модуль закрытый.

Если вас не волнует моральное падение по отношению к свободному ПО, Qemu с бесплатным акселератором работает гораздо быстрее. Мы хотели было включить Qemu в наше тестирование, но уж очень странные вышли результаты (невозможные или маловероятные цифры). Тем не менее Qemu работает, причем неплохо. Например, Xen вовсю использует Qemu в режиме аппаратной виртуализации, потому что эмуляция устройств определенно реализована в нем лучше, чем где-либо.