Не удается запустить виртуальную машину. Ошибка Hyper-V «Не удаётся запустить виртуальную машину, поскольку не выполняется низкоуровневая оболочка. При использовании подключения к виртуальной машине указатель мыши принимает вид точки или «застревает» в ок

В этой статье я опишу только те ошибки, с которыми я лично столкнулся в процессе установки и настройки Hyper-V Server 2012. О других ошибках и путях их решения можно почитать на сайте Microsoft-a (например, или , к сожалению, только по-английски).

Ошибки в процессе установки.

В.: На завершающей стадии установки Hyper-V Server 2012, а точнее после последней перезагрузки, система не загружается - чёрный экран, отсутствие реакции на нажатие клавиш, помогает только hard reset, возможна загрузка в Safe mode.
П.: ОС не поддерживает или не совместима с драйверами USB 3.0.
Р.: Отключите в BIOS USB 3.0 Controller и все связанные устройства.

В.: На завершающей стадии установки Hyper-V Server 2012, а точнее после последней перезагрузки, система не загружается - чёрный экран, отсутствие реакции на нажатие клавиш, помогает только hard reset, загрузка в Safe mode невозможна.
П.:
Р.: Попробуйте решение, предложенное автором этой статьи (англ.) .

Ошибки в процессе настройки и использования.

В.: Не отображается сетевой адаптер в Hyper-V Server Configuration console (п.8).
П.: 1) В сетевой адаптер не вставлен кабель;
2) Неполадки с активным (коммутатор, маршрутизатор и др.) или пассивным (кабели, розетки, патч-панель и др.) сетевым оборудованием.
Р.: 1) Вставьте кабель;
2) Проверьте работоспособность сетевого оборудования.

В.: При попытке выполнить в консоли команду вида netsh advfirewall firewall set rule group=“” new enable=yes появляется сообщение об ошибке "Group cannot be specified with other identification conditions" (Группа не может быть задана вместе с другими условиями идентификации).
П.: Команды вставлялись в консоль методом copy-paste.
Р.: Введите команды от руки или просто сотрите и заново напишите кавычки.

В.: В диспетчере Hyper-V отображается сообщение об ошибке «Access denied. Unable to establish communication between And » (Отказано в доступе. Не удается установить соединение между и).
П.: Пользователю не предоставлены права на удаленный запуск (remote launch and activation) в DCOM.
Р.: Все манипуляции производятся на клиентском компьютере:
1) Запустите оснастку «Component Services» (Службы компонентов) с полными правами администратора. Для этого можно, например, выполнить программу %SystemRoot%\System32\dcomcnfg.exe.
2) В дереве консоли последовательно разверните узлы «Component Services» (Службы компонентов) и «Computers» (Компьютеры).
3) В контекстном меню объекта «My Computer» (Мой компьютер) выберите «Properties» (Свойства).
4) В окне «My Computer Properties» (Свойства моего компьютера) выберите вкладку «COM Security» (Безопасность COM).
5) В разделе «Access Permissons» (Права доступа) нажмите кнопку «Edit Limits» (Редактировать ограничения).
6) В диалоговом окне «Access Permissions» (Права доступа) выберите строку НANONYMOUS LOGON» (Анонимный вход) из списка «Group or user names» (Имена пользователей и групп).
В графе «Allow» (Разрешить) раздела «Permissions for User» (Разрешения для пользователя) выберите «Remote Access» (Удалённый доступ).
7) Закройте все диалоговые окна кнопкой ОК.

В.: В диспетчере Hyper-V отображается сообщение об ошибке "Не удается подключиться к службе RPC на удаленном компьютере "xxx.xxx.xxx.xxx". Убедитесь, что служба RPC запущена.".

П.: 1)В фаерволе не созданы необходимые правила.
2) В файле hosts не установлено однозначное соответствие между IP компьютера и его сетевым именем.

Р.: 1) Возможны 2 пути решения проблемы:

а) Отключить фаервол на клиенте и на сервере (нежелательно).
б) Создать в фаерволе на клиенте и сервере правила, введя следующие команды:
Для удаленного управления дисками:
Netsh advfirewall firewall set rule group=“Remote Volume Management” new enable=yes
Для удаленного запуска оснастки по управлению фаерволом:
Netsh advfirewall firewall set rule group=“Windows Firewall Remote Management” new enable=yes
2)Для однозначной привязки имени сервера и IP-адреса нужно внести изменения в файл hosts. Например:192.168.1.100 HVserver

В.: В диспетчере Hyper-V отображается сообщение об ошибке "The virtual machine could not be started because the hypervisor is not running." (Не удается запустить виртуальную машину, поскольку не выполняется низкоуровневая оболочка.).

П.: Возможны разные причины возникновения данной ошибки.

С появлением поддержки виртуализации в новых ОС от Microsoft, причем даже клиенских Windows 7, 8 и 10, фирменная служба Hyper-V перестала быть уделом системных администраторов в компаниях средней руки. Hyper-V вполне может заменить то же популярный VirtualBox от Oracle на ниве виртуализации начального (клиентского уровня). Однако перед установкой данного сервиса требуется проверить соотвествие системных требований, иначе можно получить следующее сообщение: "Не удается запустить виртуальную машину, поскольку низкоуровневая оболочка не запущена". На что стоит обратить внимание при выборе оборудования для виртуализации. Возможно ли как-то спасти ситуации, если железо уже приобретено? Рассмотрим это в данной заметке.
Итак, у Вас развернута Hyper-V на сервере Windows 2008 Server и при попытке запустить виртуальную машину, получаете окно

Не стоит отчаиваться, возможно ситуацию еще удасться спасти. Следует отметить, что ОС должна быть 64-х розрядной, ну конечно же на x32 Вы бы не смогли вообще развернуть Hyper-V. Первое, что нужно проделать - проверить включение соответствующих пунктов в BIOS - включаем VT и AMD-V. Далее необходимо убедиться, что ваш процессор поддерживает виртуализацию, средства проверки для платформ Intel и AMD описаны одним из них является . (на рисунке ниже).

Также может помочь в определении утилитка от Марка Руссиновича.

Еще одной распростаненной проблемой является невозможность запуска вирутальных машин из Windows 2008 R2 на процессорах с поддержкой технологии Advanced Vector Extensions (AVX). Эта ОС изначально не поддерживает AVX, однако, в этой ситуации Вам может помочь исправление

Hyper-V , родная для систем Windows – в её серверных выпусках, а также в некоторых десктопных версиях и редакциях – среда для работы с виртуальными машинами и их гостевыми ОС не всегда работает без проблем. Одной из таких проблем может быть выскакивающее при запуске виртуальной машины уведомление, что, мол, Hyper-V не удаётся её запустить, поскольку не выполняется некая низкоуровневая оболочка.

Что это за ошибка, и как её исправить.

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

Системные требования

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

Для работы Hyper-V необходимо:

Не менее 4 Гб RAM;
64-битный процессор с поддержкой SLAT и технологии виртуализации.

Хранилище BCD

Рассматриваемая ошибка может говорить о неверной конфигурации данных хранилища BCD . Компонент Hyper-V глубоко интегрирован в Windows и стартует до запуска ядра системы. Если в хранилище BCD вносились изменения для модификации запуска гипервизора, они могут быть неверными. Либо же запуск Hyper-V и вовсе был ранее намеренно отключён с целью временной оптимизации использования ресурсов компьютера. В таком случае конфигурацию BCD в части запуска гипервизора необходимо либо подкорректировать, либо вернуть дефолтное значение путём установки автозапуска Hyper-V . Для установки автозапуска открываем CMD от имени администратора (обязательно) , вводим:

bcdedit /set hypervisorlaunchtype auto

После этого осуществляем перезагрузку.

AMD Bulldozer

Hyper-V не работает с процессорами компании AMD с архитектурой Bulldozer .

Технологии виртуализации

Для обеспечения жизнедеятельности среды виртуализации посредством любого гипервизора процессор должен быть обустроен технологией, обеспечивающей виртуализацию – Intel Virtualization , либо же AMD-V . О поддержке этих технологий можно узнать на страничке спецификаций процессора на сайтах, соответственно, Intel и AMD . И технология виртуализация, естественно, должна быть включена в BIOS .

Ещё один важный нюанс: для процессоров Intel в BIOS должны быть отключены специфические технологии Intel VT-d и Trusted Execution . С ними встроенный в Windows гипервизор не дружит. Вот примерно так должны выглядеть настройки BIOS для работы с Hyper-V : технология виртуализации включена, а специфические технологии – выключены.

Предыстория

Я собрал года 4 назад домашний комп, который подходил всем моим запросам. На процессоре решил сэкономить - взял amd. К компу вопросов нет.

Потом занялся разработкой под Android и тут меня ждал сюрприз! Эмулятор запускался только на процессоре intel. Его можно было запустить без аппаратной виртуализации конечно, используя вот этот совет www.youtube.com/watch?v=QTbjdBPKnnw&t=127s , но кто пользовался знает, что эмулятор может запускаться очень долго. У меня с 12ГБ доходило до 10 мин. Это может конечно из-за встроенной видеокарты.

Основное рабочее место у меня было в офисе, поэтому особо переживал и тестировал дома на реальных устройствах. Но пару месяцев назад стал нужен именно эмулятор. Первой мыслью было конечно купить intel-овский процессор. Но нужно было покупать ещё материнскую плату и видеокарту. Скорее всего я бы так и поступил, если бы не наткнулся на обновлённые требования к системе . В требованиях написано, что эмулятор всё таки можно запустить на Windows 10 (с обновлениями после апреля 2018) с помощью технологии WHPX.

Теперь основная часть истории, как это сделать. Всё оказалось не так тривиально. Заранее прошу прощения за упущения, потому что не могу назвать себя знатоком ни в “железе”, ни в Windows.

Инструкция

После всех обновлений эмулятор естественно не запустился. AndroidStudio пыталась запустить эмулятор с помощью HAXM и выбрасывала ошибку “Emulator: emulator: ERROR: x86 emulation currently requires hardware acceleration!”.

Должен поддерживать для работы с аппаратной виртуализацией.

3. Удаляем HAXM:

4. Включаем в bios режим виртуализации. Он там может называеться IOMMU, а не VT.

5. Качаем обновления для bios с официального сайта. Для моего asus, например, они были .

Версия Bios должна стать что-то около 3001:

7. Заходим на сайт microsoft и изучаем инструкцию для включения компонента.

8. Нужно проверить требования Hyper-V. Для этого в командной строке набираем systeminfo. Проверяем, чтобы отображались эти значения:

У меня же вместо это было сообщение:

На официальном сайте написано, что пока не будет стоять Yes-Yes-Yes-Yes система WHPX не будет работать. У меня же эмулятор запускается, при включенной низкоуровневой оболочке.

В русском переводе наименования несколько отличаются:

Кстати, после отключения компонента “Платформа низкоуровневой оболочки Windows”, “Требования hyper-v” становятся Yes-Yes-Yes-Yes. Не понял этот момент. Если кто разбирается, напишите в комментариях.

10. Определяем, нужно ли нам всё это? Или легче было купить intel)

После этих настроек всё должно заработать:

Хочу отметить, используя технологию WHPX и процессор amd, запуск эмулятора занимает примерно столько же времени, сколько на процессоре intel. Учитывая, что остальное «железо» сравнимо по своим параметрам.

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

Общие сведения о виртуальных машинах

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

• Интерфейсы управления
  Виртуализация сервера требует наличия интерфейсов управления, которые позволяют администраторам создавать, настраивать и контролировать виртуальные машины, запущенные на компьютере. Эти интерфейсы также должны поддерживать программное администрирование и работать по сети, обеспечивая удаленное управление виртуальными машинами.
• Управление памятью
  Виртуализация сервера требует наличия диспетчера памяти, который позволяет убедиться в том, что все виртуальные машины получают выделенные и изолированные ресурсы памяти.
• Средство планирования
  Виртуализация сервера требует наличия средства планирования для управления доступом виртуальных машин к физическим ресурсам. Средство планирования должно настраиваться администратором и иметь возможность присвоения различных уровней приоритета оборудованию.
• Конечный автомат
  Для виртуализации сервера необходимый конечный автомат, отслеживающий сведения о текущем состоянии всех виртуальных машин на компьютере. Сведения о состояниях виртуальной машины включают в себя сведения о ЦП, памяти, устройствах и состоянии виртуальной машины (запущена или остановлена). Конечный автомат также должен поддерживать управление переходами между различными состояниями
• Хранение и работа с сетью
  Виртуализация сервера требует возможности выделения ресурсов хранения и сетевых ресурсов на компьютере, что позволяет предоставить каждой виртуальной машине отдельный доступ к жестким дискам и сетевым интерфейсам. Кроме того, при виртуализации компьютеров также необходима возможность одновременного доступа нескольких машин к физическим устройствам с сохранением непротиворечивости, изолированности и безопасности.
• Виртуализованные устройства
  Для виртуализации сервера необходимы виртуализованные устройства, которые предоставляют запущенным на виртуальных машинах операционным системам логические представления устройств, не отличающиеся по поведению от их физических аналогов. Другими словами, при доступе ОС с виртуальной машины к физическому устройству компьютера выполняется доступ к соответствующему виртуализованному устройству, идентичный процессу доступа к физическому устройству.
• Драйверы виртуальных устройств
  Для виртуализации сервера необходимо установить драйверы виртуальных устройств в операционных системах, запущенных на виртуальных машинах. Драйверы виртуальных устройств предоставляют приложениям доступ к виртуальным представлениям оборудования и подключений ввода-вывода точно так же, как и к физическому оборудованию.

Ниже мы увидим, что решение виртуализации серверов Hyper-V, разработанное корпорацией Майкрософт, соответствует всем приведенным требованиям, но вначале рассмотрим основной программный компонент, обеспечивающий виртуализацию сервера - низкоуровневую оболочку.

Общие сведения о низкоуровневой оболочке

Низкоуровневая оболочка - это платформа виртуализации, которая позволяет запускать несколько операционных систем на одном физическом компьютере - главном компьютере. Основная функция низкоуровневой оболочки заключается в создании изолированных сред выполнения для всех виртуальных машин, а также в управлении взаимодействием между гостевой операционной системой на виртуальной машине и базовыми аппаратными ресурсами физического компьютера. Термин «низкоуровневая оболочка» (гипервизор) был создан в 1972 году, когда компания IBM обновила программу управления вычислительной платформы System/370 для поддержки виртуализации. Создание низкоуровневой оболочки было новой вехой в эволюции вычислительной техники, так как это позволяло преодолевать архитектурные ограничения и снижало затраты на использование мэйнфреймов. Низкоуровневые оболочки бывают разными. Например, они различаются по типу - т.е. по тому, работают ли он на физическом оборудовании или размещены в среде операционной системы. Оболочки также можно разделить по конструкции: монолитные или микроядерные.

Низкоуровневая оболочка типа 1

Низкоуровневые оболочки типа 1 выполняются прямо на базовом физическом оборудовании главных компьютеров и выполняют роль управляющих программ. Другими словами, они выполняются «на железе». В этом случае гостевые операционные системы выполняются на нескольких виртуальных машинах, размещенных над слоем низкоуровневой оболочки (см. Рисунок 1).

Так как низкоуровневые оболочки типа 1 выполняются прямо на оборудовании, а не в среде ОС, они обычно обеспечивают оптимальную производительность, доступность и безопасность по сравнению с другими типами. Низкоуровневые оболочки типа 1 в том числе реализуются в следующих продуктах виртуализации сервера:

• Microsoft Hyper-V
• Citrix XenServer
• VMware ESX Server

Низкоуровневая оболочка типа 2

Низкоуровневые оболочки типа 2 выполняются в среде ОС, запущенной на главном компьютере. В этом случае гостевые операционные системы выполняются на виртуальных машинах над низкоуровневой оболочкой (см. Рисунок 2). Виртуализация такого типа обычно называется размещенной виртуализацией. Сравнение рисунка 2 и рисунка 1 позволяет понять, что гостевые операционные системы, запущенные в виртуальных машинах платформ низкоуровневой оболочки типа 2, отделены от базового оборудования еще одним уровнем. Наличие дополнительного уровня между виртуальными машинами и оборудованием вызывает снижение производительности на платформах оболочки типа 2 и ограничивает количество виртуальных машин, которые можно запускать на практике. Низкоуровневые оболочки типа 2 в том числе реализуются в следующих продуктах виртуализации сервера:

• Microsoft Virtual Server
• VMware Server

В продукте виртуализации настольных систем Microsoft Virtual PC также используется архитектура низкоуровневой оболочки типа 2.

Монолитные низкоуровневые оболочки

Монолитная архитектура низкоуровневой оболочки предполагает наличие драйверов устройств, которые поддерживают оболочку, размещены в ней и управляются ей (см. Рисунок 3).

Монолитная архитектура имеет как преимущества, так и некоторые недостатки. Например, монолитные низкоуровневые оболочки не требуют управляющей (родительской) операционной системы, так как все гостевые системы взаимодействуют напрямую с базовым оборудованием компьютера с помощью драйверов устройств. Это одно из преимуществ монолитной архитектуры. С другой стороны тот факт, что драйверы должны быть разработаны специально для низкоуровневой оболочки, представляет существенные трудности, так как на рынке распространены различные типы материнских плат, контроллеров хранения, сетевых адаптеров и другого оборудования. В результате производителям монолитных платформ низкоуровневых оболочек необходимо тесно работать с производителями оборудования, чтобы убедиться в том, что драйверы для этих устройств поддерживают низкоуровневую оболочку. Кроме того, это делает производителей оболочек зависимыми от производителей оборудования, которые поставляют необходимые драйверы для своих продуктов. Таким образом, круг устройств, которые могут использоваться в виртуализованных операционных системах на монолитных платформах низкоуровневой оболочки значительно уже по сравнению с ситуацией запуска тех же операционных систем на физических компьютерах. Важной особенностью этой архитектуры является то, что она игнорирует один из наиболее важных принципов безопасности - необходимость эшелонированной защиты. При эшелонированной защите создается несколько рубежей обороны. В этой модели эшелонированная защита отсутствует, так как все выполняется в наиболее привилегированной части системы. Примером продукта для виртуализации сервера, который использует монолитную архитектуру низкоуровневой оболочки, является VMware ESX Server.

Микроядерные низкоуровневые оболочки

Микроядерные низкоуровневые оболочки не требуют специальных драйверов, так как в роли основного (родительского) раздела выступает операционная система. Такой раздел предоставляет среду выполнения, необходимую для доступа драйверов устройства к базовому физическому оборудованию главного компьютера. Разделы будут рассмотрены далее, а сейчас представьте, что термин «раздел» эквивалентен виртуальной машине. На платформах микроядерной низкоуровневой оболочки установка драйверов устройств требуется только для физических устройств, работающих в родительском разделе. Установка этих драйверов в гостевых операционных системах не требуется, так как для доступа к физическому оборудованию главного компьютера гостевым операционным системам необходимо всего лишь обратиться к родительскому разделу. Другими словами, микроядерная архитектура не предполагает прямого доступа гостевых операционных систем к базовому оборудованию. Доступ к физическим устройствам осуществляется только путем взаимодействия с родительским разделом. На рисунке 4 микроядерная архитектура низкоуровневой оболочки показана более подробно.

Микроядерная архитектура имеет несколько преимуществ по сравнению с монолитной. Во-первых, отсутствие необходимости в специальных драйверах позволяет использовать широкий спектр существующих драйверов, предоставленных производителем. Во-вторых, драйверы устройств не входят в оболочку, поэтому она создает меньше нагрузки, имеет меньший размер и большую устойчивость. В-третьих, что наиболее важно, площадь потенциальной атаки сведена к минимуму, так как в оболочку не загружается посторонний код (драйверы устройств создаются сторонними компаниями, поэтому считаются посторонним кодом с точки зрения разработчика оболочки). Согласитесь, что проникновение вредоносного программного обеспечения в оболочку и установление контроля над всеми виртуальными ОС компьютера - это последнее, что вам хотелось бы испытать. Единственным недостатком микроядерной конструкции является необходимость особого, родительского раздела. Это повышает нагрузку на систему (хотя обычно она минимальна), так как доступ дочерних разделов к оборудованию требует их взаимодействия с родительским разделом. Существенным преимуществом микроядерной архитектуры Hyper-V является обеспечение эшелонированной защиты.Технология Hyper-V позволяет свести выполнение кода в низкоуровневой оболочке к минимуму и передавать большее количество функций вверх по стеку (например, интерфейсы конечного автомата и управления, которые в пользовательском режиме выполняются выше по стеку). Что же можно привести в качестве примера платформы виртуализации сервера с микроядерной архитектурой? Несомненно, это Microsoft Hyper-V, в родительском разделе которого выполняется Windows Server 2008 или более поздние версии.

Основные особенности Hyper-V

Ниже представлены некоторые основные особенности исходной версии платформы Microsoft Hyper-V:

• Поддержка различных ОС
  Hyper-V поддерживает одновременное выполнение различных типов ОС, в т. ч. 32-разрядных и 64-разрядных ОС на различных серверных платформах (например, Windows, Linux и др.).
• Расширяемость
  Технология Hyper-V имеет стандартные интерфейсы инструментария управления Windows (WMI) и программные интерфейсы API, которые позволяют независимым поставщикам ПО и разработчикам быстро создавать настраиваемые средства и расширения для платформы виртуализации.
• Балансировка сетевой нагрузки
  Hyper-V предоставляет возможности виртуального переключения, которые обеспечивают использование службы балансировки сетевой нагрузки Windows для балансировки нагрузки на виртуальных машинах с различных серверов.
• Микроядерная архитектура
  Hyper-V имеет 64-разрядную микроядерную архитектуру низкоуровневой оболочки, которая позволяет платформе предоставлять различные методы поддержки устройств, дополнительную производительность и безопасность.
• Аппаратная виртуализация
  Для работы Hyper-V необходимо использование технологий аппаратной виртуализации Intel-VT или AMD-V.
• Архитектура совместного использования оборудования
  Hyper-V использует архитектуру поставщиков (VSP) и клиентов служб виртуализации (VSC), что обеспечивает расширенный доступ и использование аппаратных ресурсов (например, дисков, сети и видео).
• Быстрая миграция
  Hyper-V позволяет перенести запущенную виртуальную машину с одного физического главного компьютера на другой с минимальными задержками. Это осуществляется при помощи высокодоступных средств управления Windows Server 2008 и System Center.
• Масштабируемость
  Hyper-V поддерживает несколько процессоров и ядер на уровне главного компьютера, а также расширенный доступ к памяти на уровне виртуальных машин. Эта поддержка обеспечивает масштабируемость сред виртуализации для размещения большого количества виртуальных машин на одном узле. При этом возможности быстрой миграции также позволяют выполнять масштабирование на нескольких узлах.
• Поддержка симметричной мультипроцессорной архитектуры (SMP)
  Hyper-V поддерживает до четырех процессоров в среде виртуальных машин для использования многопотоковых приложений на виртуальной машине.
• 
  Hyper-V обеспечивает возможность создания моментальных снимков работающих виртуальных машин для быстрого возврата к предыдущему состоянию, что оптимизирует решения по резервному копированию и восстановлению.

Все эти функции подробно рассматриваются в этом обзоре, но наиболее интересными представляются функции, добавленные в Hyper-V в версии R2. Эти функции описаны ниже.

Новые возможности Hyper-V R2

В версии Windows Server 2008 R2 в роль Hyper-V добавлены новые функции. Они повышают гибкость, производительность и масштабируемость Hyper-V. Рассмотрим их более подробно.

Повышенная гибкость

Hyper-V R2 содержит следующие новые функции, которые повышают гибкость развертывания и обслуживания инфраструктуры виртуализации сервера:

• Динамическая миграция
  Hyper-V R2 содержит функцию динамической миграции, которая позволяет перемещать виртуальную машину с одного сервера Hyper-V на другой без прерывания сетевого подключения, без простоев в работе пользователя и без прекращения обслуживания. Перемещение сопровождается всего лишь уменьшением производительности в течение нескольких секунд. Динамическая миграция позволяет обеспечить высокую доступность серверов и приложений, запущенных на кластеризованных серверах Hyper-V в среде виртуализованного центра обработки данных. Динамическая миграция также упрощает процесс обновления и обслуживания оборудования главного компьютера, а также предоставляет новые возможности, например возможность балансировки сетевой нагрузки для максимально эффективного энергопотребления или оптимального использования процессора. Динамическая миграция подробно описывается ниже в разделе «Работа с динамической миграцией».
• Общие тома кластера
  Общие тома кластера - это новая функция системы отказоустойчивых кластеров Windows Server 2008 R2. Она предоставляет единое и непротиворечивое пространство имен файлов, которая позволяет всем узлам кластера обращаться к одному и тому же устройству хранения. Использование общих томов кластера настоятельно рекомендуется при динамической миграции и описывается ниже в разделе «Работа с динамической миграцией».
• Поддержка «горячего» добавления и удаления средств хранения
  Версия R2 Hyper-V позволяет добавлять или удалять виртуальные жесткие диски и транзитные диски на работающей виртуальной машине без завершения ее работы и перезапуска. Это позволяет без простоев настроить все пространство хранения, используемое виртуальной машиной, в соответствии с изменением рабочей нагрузки. Кроме того, это предоставляет новые возможности резервного копирования в Microsoft SQL Server, Microsoft Exchange Server и в центрах обработки данных. Для использования этой функции виртуальные и транзитные диски должны быть подключены к виртуальной машине с помощью виртуального контроллера SCSI. Дополнительные сведения о добавлении контроллеров SCSI в виртуальные машины см. ниже в разделе «Управление виртуальными машинами».
• Режим совместимости процессора
  Новый режим совместимости процессора, доступный в версии Hyper-V R2, позволяет переносить виртуальную машину с одного главного компьютера на другой при совпадении архитектуры их процессоров (AMD или Intel). Это облегчает обновление инфраструктуры главного компьютера Hyper-V путем упрощения миграции виртуальных машин с компьютеров со старым оборудованием на компьютеры с более новым оборудованием. Кроме того, это также обеспечивает гибкость миграции виртуальных машин между узлами кластера. Например, режим совместимости процессора можно использовать для миграции виртуальных машин с узла Intel Core 2 на узел Intel Pentium 4 или с узла AMD Opteron на узел AMD Athlon. Обратите внимание на то, что режим совместимости процессоров позволяет выполнять миграцию виртуальных машин только при совпадении архитектуры процессоров узлов. Другими словами, поддерживается миграция AMD-AMD и Intel-Intel. Перенос виртуальных машин с главного компьютера одной архитектуры на главный компьютер другой архитектуры не поддерживается. Другими словами, миграция AMD-Intel и Intel-AMD не поддерживается. Дополнительные сведения о режиме совместимости процессоров и его настройке см. во врезке «Принцип работы. режим совместимости процессора».

Повышенная производительность

Hyper-V R2 содержит следующие новые функции, которые могут повысить производительность инфраструктуры виртуализации сервера:

1. Поддержка до 384 одновременно запущенных виртуальных машин и до 512 виртуальных процессоров на каждом сервере
   При наличии соответствующего оборудования сервера Hyper-V R2 можно использовать для выхода на недостижимые ранее уровни консолидации серверов. Например, на одном главном компьютере Hyper-V можно разместить:
   • 384 виртуальных машин с одним процессором (существенно меньше ограничения в 512 виртуальных процессоров)
   • 256 виртуальных машин с двумя процессорами (всего 512 виртуальных процессоров)
   • 128 виртуальных машин с четырьмя процессорами (всего 512 виртуальных процессоров)

   Также можно работать с любыми сочетаниями одноядерных, двухъядерных и четырехъядерных процессоров, если общее количество виртуальных машин не превышает 384, а общее количество виртуальных процессоров, выделенных виртуальным машинам, не превышает 512. Такие возможности позволяют Hyper-V R2 обеспечивать максимально возможные на рынке значения плотности виртуальных машин на данный момент. Для сравнения: предыдущая версия Hyper-V в Windows Server 2008 SP2 поддерживала всего до 24 логических процессоров и до 192 виртуальных машин. Обратите внимание на то, что при использовании отказоустойчивых кластеров Hyper-V R2 поддерживает до 64 виртуальных машин на узел кластера.

2. Поддержка преобразования адресов второго уровня (SLAT)
   В версии Hyper-V R2 процессор обрабатывает преобразования адресов на виртуальных машинах, а не в коде Hyper-V, который программным образом выполняет сопоставления таблиц. Таким образом, технология SLAT создает второй уровень страниц под таблицами страниц архитектуры x86/x64 процессоров x86/x64 за счет слоя косвенного обращения от доступа к памяти виртуальной машины до доступа к физической памяти.

При применении соответствующих процессоров (например, процессоров Intel с расширенными таблицами страниц EPT начиная с поколения i7 или последних моделей процессоров AMD с вложенными таблицами страниц NPT) Hyper-V R2 существенно увеличивает производительность системы во многих случаях. Повышение производительности вызвано улучшением технологии управления памятью и снижением количества копий памяти, необходимых для использования этих функций процессора. Производительность повышается в особенности при работе с крупными наборами данных (например, с Microsoft SQL Server). Использование памяти для низкоуровневой оболочки Microsoft Hypervisor может сократиться с 5 процентов до 1 процента от общей физической памяти. Таким образом, дочерним разделам будет доступно больше памяти, что позволяет добиться высокой степени консолидации.

3. VM Chimney
   Эта функция позволяет передавать трафик TCP/IP для виртуальной машины на физический адаптер сети главного компьютера. Для этого физический сетевой адаптер и ОС должны поддерживать функцию разгрузки TCP Chimney, что позволит повысить производительность виртуальной машины за счет снижения нагрузки ЦП для логических процессоров. Поддержка разгрузки TCP Chimney в Microsoft Windows появилась в версиях

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

4. Поддержка очереди виртуальных машин (VMQ)
   Hyper-V R2 предоставляет поддержку очередей устройства виртуальных машин (VMDq) - технологии Intel Virtualization Technology For Connectivity. VMQ передает задачу по сортировке трафика данных виртуальных машин из диспетчера Virtual Machine Manager в сетевой контроллер. Это позволяет одному физическому сетевому адаптеру отображаться в гостевой системе в виде нескольких сетевых адаптеров (очередей), что оптимизирует использование ЦП и позволяет повысить пропускную способность сети, а также обеспечивает улучшенные возможности управления трафиком виртуальной машины. После этого главный компьютер не сохраняет данные прямого доступа к памяти (DMA) со стороны устройств в собственном буфере, так как сетевой адаптер может воспользоваться таким доступом для направления пакетов в память виртуальной машины. Сокращение пути ввода-вывода обеспечивает повышение производительности. Дополнительные сведения об очереди VMDq см. на веб-сайте Intel по адресу http://www.intel.com/network/connectivity/vtc_vmdq.htm .
5. · Поддержка кадров крупного размера
   Кадры крупного размера - это кадры Ethernet, содержащие более 1500 байт полезной нагрузки. Кадры крупного размера ранее были доступны в невиртуальных средах. Hyper-V R2 предоставляет возможность работы с ними в виртуальных машинах и поддерживает кадры размером до 9014 байт (если это поддерживается базовой физической сетью).

В результате это позволяет повысить пропускную способность сети и сократить интенсивность использования ЦП при переносе крупных файлов.

Повышенная масштабируемость

Hyper-V R2 содержит следующие новые функции, которые повышают масштабируемость инфраструктуры виртуализации сервера:

• Поддержка до 64 логических процессоров в главном пуле процессоров
  Количество логических процессоров, поддерживаемое в этой версии Hyper-V, увеличено в четыре раза по сравнению со старой версией Hyper-V. Это позволяет предприятиям использовать последние модели крупных и масштабируемых серверных систем для максимизации преимуществ от консолидации существующих рабочих нагрузок. Кроме того, использование подобных серверных систем облегчает предоставление нескольких процессоров для каждой виртуальной машины. Hyper-V поддерживает до четырех логических виртуальных процессоров на виртуальную машину.
• Поддержка парковки ядер
  Функция парковки ядер позволяет Windows и Hyper-V консолидировать обработку данных на минимальном количестве ядер процессора. Для этого неактивные ядра процессора приостанавливаются путем перевода их в состояние C (состояние «парковки»). Это позволяет запланировать работу виртуальных машин на одном узле, а не распределять их на несколько узлов. Преимущество этого состоит в приближении к модели экологических вычислений за счет снижения количества энергии, необходимой ЦП узлов центра обработки данных.

Сравнение Hyper-V и Virtual Server

Широкие возможности Hyper-V уже привели к тому, что эта технология заменяет Microsoft Virtual Server во многих организациях, ранее использовавших Virtual Server для консолидации серверов, обеспечения непрерывности работы, тестирования и разработки. При этом Virtual Server до сих пор может найти применение в корпоративной инфраструктуре виртуализации. В таблице 1 приводится сравнение некоторых функций и технических данных Hyper-V и Virtual Server.

Таблица 1. Сравнение компонентов и технических характеристик Virtual Server 2005 R2 SP1 и Hyper-V R2

Компонент или технические данные	Virtual Server 2005 R2 SP1
Архитектура
Тип виртуализации	Размещенные системы	На основе низкоуровневой оболочки
Производительность и масштабируемость
32-разрядные виртуальные машины
64-разрядные виртуальные машины
32-разрядные узлы
64-разрядные узлы
Виртуальные машины с несколькими процессорами
Максимальный объем гостевой оперативной памяти на каждую виртуальную машину
Максимальное количество гостевых ЦП на каждую виртуальную машину
Максимальная оперативная память узла
Максимальное количество запущенных виртуальных машин
Управление ресурсами
Доступность
Переключение гостевых систем при отказе
Переключение главных компьютеров при отказе
Миграция узлов
Моментальные снимки виртуальных машин
Управление
Возможность расширения и управления через скрипты
Пользовательский интерфейс	Веб-интерфейс	Интерфейс MMC 3 0
Интеграция SCVMM

Дополнительные сведения Для получения дополнительных сведений о возможностях Virtual Server и его загрузки перейдите на страницу http://www.microsoft.com/windowsserversystem/virtualserver/downloads.aspx . Для получения сведений о миграции виртуальных машин с Virtual Server на Hyper-V обратитесь к разделу «Virtual Machine Migration Guide: How To Migrate from Virtual Server to Hyper-V» в библиотеке TechNet по адресу http://technet.microsoft.com/en-us/library/dd296684.aspx .