Требования к процессору для включения Hyper-V в Windows 8
В клиентской операционной системе Windows 8 появился компонент Hyper-V, до этого присутствовавший только в качестве роли в серверных ОС. Технология неплоха, однако тем, кто собирается ее использовать, стоит иметь в виду, что для функционирования Hyper-V в Windows 8 требуется не просто аппаратная поддержка виртуализации, но и поддержка процессором преобразования адресов второго уровня (Second Level Address Translation, SLAT).
SLAT позволяет виртуализовать страницы памяти и отдать их под прямой контроль гостевой системы, не затрагивая гипервизор. У Intel эта технология называется Еxtended Page Tables (EPT) и поддерживается десктопными процессорами, начиная с архитектуры Nehalem (Core i7 и более поздние). AMD также назвала эту технологию по своему — Rapid Virtualization Indexing (RVI) и добавила ее поддержку в процессоры с ядром Agena (Phenom X4). Соответственно владельцы процессоров предыдущего поколения (Intel Core 2 Duo, Core 2 Quad, AMD Athlon и более ранние) лишены возможности использовать Hyper-V в Windows 8.
При отсутствии поддержки процессором технологии SLAT соответствующий пункт в компонентах Windows будет неактивен, а всплывающая подсказка сообщит об отсутствии у процессора возможности преобразования адресов второго уровня.
Информацию о поддержке процессором технологий виртуализации можно посмотреть на сайте производителя, вот здесь для Intel, здесь для AMD.
Также определить, поддерживает ли ваш процессор технологию SLAT, можно с помощью утилиты Coreinfo от Sysinternals:
Утилита выдаст отчет о поддерживаемых процессором технологиях виртуализации. Нас интересует параметр EPT, если напротив него будет «*», то процессор поддерживает данную технологию, если же «-» — то нет. Для владельцев AMD вместо EPT будет параметр NPT (Nested Page Tables) или RVI (Rapid Virtualization Indexing). Точнее не скажу, т.к. нет под рукой AMD.
Информация для размышления
В Windows Server R2 с выходом SP1 появился функционал RemoteFX, который позволяет виртуализировать серверный видеоадаптер, делая его доступным для виртуальных рабочих столов. RemoteFX требует поддержки SLAT. В Windows 8 RemoteFX является неотъемлемой частью Hyper-V, поэтому требуется для активации роли. В серверной же ОС роль Hyper-V и компонент RemoteFX устанавливаются отдельно, поэтому установка серверной роли Hyper-V возможна на компьютерах без поддержки SLAT.
Так что вполне возможно повторение истории с XP Mode в Windows 7, когда сначала для этого режима требовался процессор с поддержкой виртуализации, а потом был выпущен патч, исправляющий ситуацию. А пока, если нет планов делать апгрейд, вполне можно обойтись и VirtualBox-ом.
Знакомство с Hyper-V в Windows 10
Вы разработчик программного обеспечения, ИТ-специалист или просто увлекаетесь технологиями? Тогда вам наверняка приходится работать с несколькими операционными системами. Hyper-V позволяет запускать несколько операционных систем в виде виртуальных машин в Windows.
В частности, Hyper-V предоставляет возможность выполнять виртуализацию оборудования. Это означает, что каждая виртуальная машина работает на виртуальном оборудовании. Hyper-V позволяет создавать виртуальные жесткие диски, виртуальные коммутаторы и ряд других виртуальных устройств, каждое из которых можно добавить в виртуальную машину.
Причины использовать виртуализацию
Виртуализация позволяет выполнять следующие операции.
Запуск программного обеспечения, для которого требуются более старые версии Windows или операционные системы, отличные от Windows.
Эксперименты с другими операционными системами. Hyper-V существенно упрощает создание и удаление различных операционных систем.
Тестирование программного обеспечения в нескольких операционных системах с помощью нескольких виртуальных машин. Благодаря Hyper-V их можно запускать на настольном компьютере или ноутбуке. Эти виртуальные машины можно экспортировать, а затем импортировать в любую другую систему Hyper-V, включая Azure.
Требования к системе
Hyper-V доступен в 64-разрядных версиях Windows 10 Профессиональная, Корпоративная и для образовательных учреждений. Он недоступен в версии Домашняя.
Выполните обновление с выпуска Windows 10 Домашняя до выпуска Windows 10 Профессиональная, открыв раздел Параметры Обновление и безопасность Активация. Здесь вы можете посетить Магазин Windows и приобрести обновление.
Большинство компьютеров работают под управлением Hyper-V, однако каждая виртуальная машина работает под управлением полностью отдельной операционной системы. Как правило, на компьютере с 4 ГБ ОЗУ можно запустить одну или несколько виртуальных машин, однако для запуска дополнительных виртуальных машин либо установки и запуска ресурсоемкого ПО, такого как игры, видеоредакторы или программы для технического проектирования, потребуются дополнительные ресурсы.
Дополнительные сведения о требованиях Hyper-V к системе и о том, как проверить, будет ли Hyper-V работать на конкретном компьютере, см. в статье Справочник по требования к системе для Hyper-V.
Операционные системы, которые можно запустить на виртуальной машине
Hyper-V в Windows поддерживает много операционных систем на виртуальных машинах, в том числе различные выпуски Linux, FreeBSD и Windows.
Напоминаем, что необходимо иметь действующую лицензию на все операционные системы, используемые на виртуальной машине.
Дополнительные сведения об операционных системах, которые поддерживаются как гостевые в Hyper-V в Windows, см. в статьях Гостевые операционные системы, поддерживаемые в Windows и Гостевые операционные системы, поддерживаемые в Linux.
Различия между Hyper-V в Windows и Windows Server
Некоторые функции работают по-разному в Hyper-V для Windows и Windows Server.
Компоненты Hyper-V, доступные только в Windows Server:
Компоненты Hyper-V, доступные только в Windows 10:
Модель управления памятью отличается в Hyper-V в Windows. При управлении памятью Hyper-V на сервере предполагается, что на нем запущены только виртуальные машины. В Hyper-V для Windows при управлении памятью учитывается тот факт, что кроме виртуальных машин на большинстве клиентских компьютеров работает локальное программное обеспечение.
Ограничения
Программы, которые зависят от наличия определенного оборудования, не будут нормально работать на виртуальной машине. Например, это игры или приложения, которым нужны графические процессоры. С приложениями, использующими таймеры длительностью менее 10 мс, например приложениями для микширования музыки в режиме реального времени или приложениями, чувствительными к задержкам, также возможны проблемы.
Кроме того, если включен Hyper-V, проблемы могут возникать и с чувствительными к задержкам высокоточными приложениями, работающими в операционной системе сервера виртуальных машин. Это связано с тем, что при включенной виртуализации ОС сервера виртуальных машин тоже работает поверх уровня виртуализации Hyper-V, как и гостевые операционные системы. Однако отличие операционной системы сервера виртуальных машин от гостевых ОС заключается в том, что она имеет прямой доступ к оборудованию, что обеспечивает правильную работу приложений с особыми требованиями к оборудованию.
Архитектура Hyper-V: Глубокое погружение
Что же такое – Hyper-V?
Hyper-V – это одна из технологий виртуализации серверов, позволяющая запускать на одном физическом сервере множество виртуальных ОС. Эти ОС именуются «гостевыми», а ОС, установленная на физическом сервере – «хостовой». Каждая гостевая операционная система запускается в своем изолированном окружении, и «думает», что работает на отдельном компьютере. О существовании других гостевых ОС и хостовой ОС они «не знают».
Эти изолированные окружения именуются «виртуальными машинами» (или сокращенно — ВМ). Виртуальные машины реализуются программно, и предоставляют гостевой ОС и приложениям доступ к аппаратным ресурсам сервера посредством гипервизора и виртуальных устройств. Как уже было сказано, гостевая ОС ведет себя так, как будто полностью контролирует физический сервер, и не имеет представления о существовании других виртуальных машин. Так же эти виртуальные окружения могут именоваться «партициями» (не путать с разделами на жестких дисках).
Впервые появившись в составе Windows Server 2008, ныне Hyper-V существует в виде самостоятельного продукта Hyper-V Server (де-факто являющегося сильно урезанной Windows Server 2008), и в новой версии – R2 – вышедшего на рынок систем виртуализации Enterprise-класса. Версия R2 поддерживает некоторые новые функции, и речь в статье пойдет именно об этой версии.
Гипервизор
Термин «гипервизор» уходит корнями в 1972 год, когда компания IBM реализовала виртуализацию в своих мэйнфреймах System/370. Это стало прорывом в ИТ, поскольку позволило обойти архитектурные ограничения и высокую цену использования мэйнфреймов.
Гипервизор – это платформа виртуализации, позволяющая запускать на одном физическом компьютере несколько операционных систем. Именно гипервизор предоставляет изолированное окружение для каждой виртуальной машины, и именно он предоставляет гостевым ОС доступ к аппаратному обеспечению компьютера.
Гипервизоры можно разделить на два типа по способу запуска (на «голом железе» или внутри ОС) и на два типа по архитектуре (монолитная и микроядерная).
Гипервизор 1 рода
Гипервизор 1 типа запускается непосредственно на физическом «железе» и управляет им самостоятельно. Гостевые ОС, запущенные внутри виртуальных машин, располагаются уровнем выше, как показано на рис.1.
Рис.1 Гипервизор 1 рода запускается на «голом железе».
Гипервизор 2 рода
В отличие от 1 рода, гипервизор 2 рода запускается внутри хостовой ОС (см. рис.2).
Рис.2 Гипервизор 2 рода запускается внутри гостевых ОС
Виртуальные машины при этом запускаются в пользовательском пространстве хостовой ОС, что не самым лучшим образом сказывается на производительности.
Примерами гипервизоров 2 рода служат MS Virtual Server и VMware Server, а так же продукты десктопной виртуализации – MS VirtualPC и VMware Workstation.
Монолитный гипервизор
Гипервизоры монолитной архитектуры включают драйверы аппаратных устройств в свой код (см. рис. 3).
Рис. 3. Монолитная архитектура
Микроядерная архитектура
При микроядерной архитектуре драйверы устройств работают внутри хостовой ОС.
Хостовая ОС в этом случае запускается в таком же виртуальном окружении, как и все ВМ, и именуется «родительской партицией». Все остальные окружения, соответственно – «дочерние». Единственная разница между родительской и дочерними партициями состоит в том, что только родительская партиция имеет непосредственный доступ к оборудованию сервера. Выделением памяти же и планировкой процессорного времени занимается сам гипервизор.
Рис. 4. Микроядерная архитектура
Архитектура Hyper-V
На рис.5 показаны основные элементы архитектуры Hyper-V.
Рис.5 Архитектура Hyper-V
Как видно из рисунка, гипервизор работает на следующем уровне после железа – что характерно для гипервизоров 1 рода. Уровнем выше гипервизора работают родительская и дочерние партиции. Партиции в данном случае – это области изоляции, внутри которых работают операционные системы. Не нужно путать их, к примеру, с разделами на жестком диске. В родительской партиции запускается хостовая ОС (Windows Server 2008 R2) и стек виртуализации. Так же именно из родительской партиции происходит управление внешними устройствами, а так же дочерними партициями. Дочерние же партиции, как легко догадаться – создаются из родительской партиции и предназначены для запуска гостевых ОС. Все партиции связаны с гипервизором через интерфейс гипервызовов, предоставляющий операционным системам специальный API. Если кого-то из разработчиков интересуют подробности API гипервызовов — информация имеется в MSDN.
Родительская партиция
Рис.6 Компоненты родительской партиции Hyper-V
Стек виртуализации
Рабочий процесс виртуальной машины (VMWP)
Для управления виртуальной машиной из родительской партиции запускается особый процесс – рабочий процесс виртуальной машины (VMWP). Процесс этот работает на уровне пользователя. Для каждой запущенной виртуальной машины служба VMMS запускает отдельный рабочий процесс. Это позволяет изолировать виртуальные машины друг от друга. Для повышения безопасности, рабочие процессы запускаются под встроенным пользовательским аккаунтом Network Service.
Процесс VMWP используется для управления соответствующей виртуальной машиной. В его задачи входит:
Создание, конфигурация и запуск виртуальной машины
Пауза и продолжение работы (Pause/Resume)
Сохранение и восстановление состояния (Save/Restore State)
Создание моментальных снимков (снапшотов)
Кроме того, именно рабочий процесс эмулирует виртуальную материнскую плату (VMB), которая используется для предоставления памяти гостевой ОС, управления прерываниями и виртуальными устройствами.
Виртуальные устройства
Драйвер виртуальной инфраструктуры (VID)
Драйвер виртуальной инфраструктуры (vid.sys) работает на уровне ядра и осуществляет управление партициями, виртуальными процессорами и памятью. Так же этот драйвер является промежуточным звеном между гипервизором и компонентами стека виртуализации уровня пользователя.
Библиотека интерфейса гипервизора
Библиотека интерфейса гипервизора (WinHv.sys) – это DLL уровня ядра, которая загружается как в хостовой, так и в гостевых ОС, при условии установки компонент интеграции. Эта библиотека предоставляет интерфейс гипервызовов, использующийся для взаимодействия ОС и гипервизора.
Провайдеры служб виртуализации (VSP)
Провайдеры служб виртуализации работают в родительской партиции и предоставляют гостевым ОС доступ к аппаратным устройствам через клиент служб виртуализации (VSC). Связь между VSP и VSC осуществляется через виртуальную шину VMBus.
Шина виртуальных машин (VMBus)
Назначение VMBus состоит в предоставлении высокоскоростного доступа между родительской и дочерними партициями, в то время как остальные способы доступа значительно медленнее из-за высоких накладных расходах при эмуляции устройств.
Если гостевая ОС не поддерживает работу интеграционных компонент – приходится использовать эмуляцию устройств. Это означает, что гипервизору приходится перехватывать вызовы гостевых ОС и перенаправлять их к эмулируемым устройствам, которые, напоминаю, эмулируются рабочим процессом виртуальной машины. Поскольку рабочий процесс запускается в пространстве пользователя, использование эмулируемых устройств приводит к значительному снижению производительности по сравнению с использованием VMBus. Именно поэтому рекомендуется устанавливать компоненты интеграции сразу же после установки гостевой ОС.
Как уже было сказано, при использовании VMBus взаимодействие между хостовой и гостевой ОС происходит по клиент-серверной модели. В родительской партиции запущены провайдеры служб виртуализации (VSP), которые являются серверной частью, а в дочерних партициях – клиентская часть – VSC. VSC перенаправляет запросы гостевой ОС через VMBus к VSP в родительской партиции, а сам VSP переадресовывает запрос драйверу устройства. Этот процесс взаимодействия абсолютно прозрачен для гостевой ОС.
Дочерние партиции
Вернемся к нашему рисунку с архитектурой Hyper-V, только немного сократим его, поскольку нас интересуют лишь дочерние партиции.
Рис. 7 Дочерние партиции
ОС Windows с установленными компонентами интеграции
ОС не из семейства Windows, но поддерживающая компоненты интеграции
Существуют так же ОС, не относящиеся к семейству Windows, но поддерживающие компоненты интеграции.На данный момент – это только SUSE Linux Enterprise Server и Red Hat Enterprise Linux. Такие ОС при установке компонент интеграции используют VSC сторонних разработчиков для взаимодействия с VSC по VMBus и доступа к оборудованию. Компоненты интеграции для Linux разработаны компанией Microsoft совместно с Citrix и доступны для загрузки в Microsoft Download Center. Поскольку компоненты интеграции для Linux были выпущены под лицензией GPL v2, ведутся работы по интеграции их в ядро Linux через Linux Driver Project, что позволит значительно расширить список поддерживаемых гостевых ОС.
Вместо заключения
На этом я, пожалуй, закончу свою вторую статью, посвященную архитектуре Hyper-V. Предыдущая статья вызвала у некоторых читателей вопросы, и надеюсь, что теперь я на них ответил.
Надеюсь, что чтение не было слишком скучным. Я достаточно часто использовал «академический язык», но это было необходимо, поскольку тематика статьи предполагает очень большой объем теории и практически нуль целых нуль десятых практики.
Выражаю огромную благодарность Mitch Tulloch и Microsoft Virtualization Team. На основе их книги Understanding Microsoft Virtualization Solutions и была подготовлена статья.
Требования к системе для Hyper-V в Windows 10
Технология Hyper-V доступна в 64-разрядных версиях Windows 10 Pro, Корпоративная и для образовательных учреждений. Для Hyper-V требуется функция преобразования адресов второго уровня (SLAT). Она есть в текущем поколении 64-разрядных процессоров Intel и AMD.
На узле, имеющем 4 ГБ оперативной памяти, можно запустить три-четыре базовые виртуальные машины, однако для большего числа виртуальных машин потребуется больше ресурсов. Кроме того, можно создать мощные виртуальные машины с 32 процессорами и 512 ГБ ОЗУ в зависимости от оборудования.
Требования к операционной системе
Роль Hyper-V можно включить в таких версиях Windows 10:
Роль Hyper-V невозможно установить в следующих версиях:
ОС Windows 10 Домашняя можно обновить до версии Windows 10 Pro. Для этого перейдите в раздел Параметры Обновление и безопасность Активация. Здесь вы можете посетить Магазин Windows и приобрести обновление.
Требования к оборудованию
Хотя в этом документе не приводится полный список оборудования, совместимого с Hyper-V, укажем следующие обязательные требования:
В BIOS системы необходимо включить следующие компоненты.
Проверка совместимости оборудования
После проверки требований к операционной системе и оборудованию, описанных выше, проверьте совместимость оборудования в Windows, открыв сеанс PowerShell или окно командной строки (cmd.exe). Для этого введите systeminfo, а затем просмотрите раздел требований к Hyper-V. Если все указанные требования Hyper-V имеют значение Yes, ваша система поддерживает роль Hyper-V. Если хотя бы один элемент имеет значение No, проверьте указанные выше требования и внесите необходимые изменения.
Окончательная проверка
Если все требования к ОС, оборудованию и совместимости соблюдены, сведения о Hyper-V отобразятся на панели управления в окне «Включение или отключение компонентов Windows». Будет доступно два варианта.
[!ПРИМЕЧАНИЕ] Если вы видите Платформа низкоуровневой оболочки Windows, а не Hyper-V в окне «Включение или отключение компонентов Windows» в панели управления возможно, ваша система несовместима с Hyper-V. В таком случае выполните перекрестную проверку указанных выше требований.
Если команда systeminfo запускается на существующем узле Hyper-V, в разделе Hyper-V Requirements отображается следующее сообщение:
Системные требования для включения Hyper-V в Windows 10
В данной статье рассмотрены требования к оборудованию компьютера и к операционной системе Windows 10 для включения технологии виртуализации Hyper-V.
В операционной системе Windows 10 имеется встроенная технология виртуализации Hyper-V, которая позволяет запускать несколько операционных систем в виде виртуальных машин в Windows.
В качестве операционной системы для Hyper-V можно использовать только 64-битные версии Windows 10 Pro, Корпоративная и для образовательных учреждений.
Для функционирования Hyper-V, процессор должен поддерживать технологии виртуализации (Intel VT-x или AMD-V) и требуется функция преобразования адресов второго уровня (SLAT).
Также для работы Hyper-V необходимо минимум 4ГБ оперативной памяти. На этом объеме ОЗУ можно стартовать основную систему и запустить одну-две нетребовательных к памяти виртуальных машин. Для комфортной работы необходимо минимум 8ГБ ОЗУ.
Требования к операционной системе
Компонент Hyper-V можно включить в следующих версиях Windows 10:
Компонент Hyper-V невозможно установить в следующих версиях:
Требования к оборудованию
Ниже приведены обязательные требования для работы Hyper-V
В BIOS UEFI системы необходимо включить следующие компоненты:
Как проверить совместимость оборудования
Чтобы проверить совместимость, откройте консоль Windows PowerShell или командную строку (cmd.exe) и выполните команду systeminfo.
