Гипервизор hyper v не настроен на включение элементов управления ресурсами процессоров

Обновлено: 07.07.2024

Виртуализация является полезной функцией, но иногда могут возникнуть проблемы с ней. Говоря о проблемах виртуализации, вот некоторые распространенные проблемы, о которых сообщили пользователи:

Убедитесь, что в BIOS включена виртуализация
Обновите свой BIOS
Обновите драйверы до последней версии
Переустановите функцию HyperV
Удалить проблемные обновления
Используйте команду bcdedit
Используйте команду DISM
Проверьте, поддерживает ли ваш процессор виртуализацию
Используйте сторонние приложения

Решение 1. Убедитесь, что в BIOS включена виртуализация

Чтобы проверить, включена ли виртуализация, просто войдите в BIOS и найдите эту функцию. Чтобы узнать, как правильно получить доступ к BIOS и найти эту функцию, мы советуем вам ознакомиться с руководством по материнской плате для получения дополнительной информации. Как только вы включите эту функцию, вернитесь в Windows и проверьте, сохраняется ли проблема.

ЧИТАЙТЕ ТАКЖЕ: 5 лучших программ для резервного копирования, которые Hyper-V сможет использовать в 2019 году

Решение 2. Обновите свой BIOS

Несколько пользователей сообщили, что они исправили эту проблему, обновив их BIOS до последней версии. Это сложный процесс, и если вы его не выполните должным образом, вы можете нанести непоправимый вред вашему ПК, поэтому мы советуем вам быть особенно осторожными.

Мы уже написали краткое руководство о том, как прошить BIOS, но если вы знаете, как правильно обновить BIOS на материнской плате, рекомендуем вам ознакомиться с руководством по материнской плате для получения подробной информации.

Решение 3. Обновите драйверы до последней версии.

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

Если вы хотите обновить все драйверы на вашем компьютере, возможно, лучше использовать стороннее решение, такое как TweakBit Driver Updater . Используя этот инструмент, вы можете автоматически обновить все ваши драйверы всего за пару кликов, поэтому обязательно попробуйте.

Загрузите программу обновления драйверов Tweakbit

Отказ от ответственности: некоторые функции этого инструмента не бесплатны

В строке поиска введите функции Windows . Теперь выберите Включить или выключить функции Windows в списке результатов.
Найдите функцию HyperV и снимите ее. Теперь нажмите ОК , чтобы сохранить изменения. Если вас попросили перезагрузить компьютер, обязательно сделайте это.
После перезагрузки компьютера вернитесь в окно Функции Windows и включите функцию Hyper-V . Вас могут попросить перезагрузить компьютер еще раз, поэтому обязательно сделайте это.

Как только ваша система перезагрузится, проблема с Hyper-V должна быть решена, и все снова начнет работать.

ЧИТАЙТЕ ТАКЖЕ: исправлено: не удается установить Hyper-V в Windows 10

Для решения проблемы рекомендуется найти проблемное обновление и удалить его. Для этого выполните следующие действия:

Откройте приложение Настройки и перейдите в раздел Обновление и безопасность . Чтобы сделать это быстро, вы можете просто использовать ярлык Windows Key + I .
Выберите Просмотреть историю обновлений .
Теперь вы должны увидеть список последних обновлений. Обратите внимание на последние обновления и запомните их или запишите. Теперь нажмите Удалить обновления .
Список последних обновлений появится в новом окне. Чтобы удалить обновление, дважды щелкните его и следуйте инструкциям на экране.

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

Windows имеет тенденцию устанавливать отсутствующие обновления автоматически, поэтому, чтобы предотвратить повторное появление этой проблемы, мы советуем вам заблокировать автоматическую установку этого обновления.

Решение 6. Используйте команду bcdedit

Если у вас есть проблемы с виртуализацией, возможно, вы можете решить эту проблему, просто запустив одну команду в командной строке. Для этого выполните следующие действия:

Нажмите Windows Key + X , чтобы открыть меню Win + X. Выберите в меню Командная строка (Администратор) или PowerShell (Администратор) .
Когда откроется Командная строка , введите следующую команду:
- bcdedit/store c: BootBCD/установить гипервизор запуска типа Авто

После выполнения команды проверьте, решена ли проблема с виртуализацией. Кроме того, вы также можете использовать команду bcdedit/set hypervisorlaunchtype auto .

Решение 7. Используйте команду DISM

Запустите Командную строку от имени администратора.
При запуске Командная строка выполните эту команду:
- dism/online/enable-feature/namename: Microsoft-Hyper-V -Все

После выполнения команды необходимо включить функцию Hyper-V и устранить проблему с виртуализацией.

Решение 8. Проверьте, поддерживает ли ваш процессор виртуализацию

Чтобы использовать встроенную виртуализацию в Windows 10, необходимо, чтобы ваш процессор поддерживал определенные функции. Если у него нет этих функций, вы не сможете использовать встроенную виртуализацию.

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

Многие пользователи сообщили, что виртуализация не будет работать на их ПК, так как процессор не поддерживает функцию SLAT. Если ваш процессор не поддерживает необходимые функции, вам, возможно, придется изменить его, чтобы использовать встроенную виртуализацию.

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

Загрузите VMware Workstation 15 Player с официальной страницы .

элементы управления ресурсами цп узла Hyper-v, появившиеся в Windows Server 2016 или более поздней версии, позволяют администраторам hyper-v лучше управлять и распределять ресурсы цп хост-сервера между "корневым", базовым и гостевым виртуальными машинами. С помощью этих элементов управления администраторы могут выделить подмножество процессоров хост-системы в корневом разделе. Это позволяет отделить работу, выполненную на узле Hyper-V, от рабочих нагрузок, работающих на гостевых виртуальных машинах, запустив их на отдельных подмножествах системных процессоров.

дополнительные сведения об оборудовании для узлов hyper-v см. в статье Windows 10 требования к системе hyper-v.

История

Перед настройкой элементов управления для ресурсов ЦП узла Hyper-V полезно ознакомиться с основами архитектуры Hyper-V. Общую сводку можно найти в разделе об архитектуре Hyper-V . Ниже приведены важные понятия, связанные с этой статьей.

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

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

Каждый виртуальный процессор (вице-президент) корневого раздела сопоставляется с 1:1 базовым логическим процессором (LP). Вице-президент узла всегда будет выполняться на том же самом базовом LP — миграция ВПС корневого раздела отсутствует.

По умолчанию LPs, на котором размещен ВПС, может также запускать гостевой ВПС.

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

Минимальная корневая папка или Конфигурация "Минрут"

В ранних версиях Hyper-V был установлен максимальный архитектурный лимит в 64 ВПС на секцию. Это применяется как к корневым, так и к гостевым секциям. Так как системы с более чем 64 логическими процессорами появлялись на серверах высокого уровня, Hyper-V также расширил ограничения масштабирования узлов для поддержки этих крупных систем, в то же время достигая узла до 320 LPs. Тем не менее, при достижении предельного количества килограммов 64 на секцию в это время представлены несколько проблем и появились сложности, которые делают поддержку более 64 ВПС на секцию. Чтобы решить эту эту технологию, Hyper-V ограничивает количество ВПС, присвоенное корневому разделу, равным 64, даже если на базовом компьютере доступно гораздо больше логических процессоров. Гипервизор будет по прежнему использовать все доступные LPs для запуска гостевых ВПС, но искусственно ограниченный корневой раздел 64. Эта конфигурация называлась "минимальной корневой конфигурацией" или "минрут". Тестирование производительности подтвердило, что даже в крупномасштабных системах с более чем 64 LPs, корневому каталогу не требуется более 64 корневого ВПС, чтобы обеспечить достаточную поддержку для большого количества гостевых виртуальных машин и гостевой ВПС. на самом деле, гораздо меньше 64 корневых ВПС, в зависимости от количества и размера гостевых виртуальных машин. выполнение конкретных рабочих нагрузок и т. д.

Эта концепция "минрут" будет продолжать использоваться сегодня. на самом деле, даже в том случае, если Windows Server 2016 Hyper-V увеличила максимальное ограничение поддержки архитектуры для узла LPs до 512 LPs, корневой раздел по-прежнему будет ограничен 320 LPs.

Использование Минрут для ограничения и изоляции ресурсов вычислений узла

при высоком пороговом значении по умолчанию 320 LPs в Windows Server 2016 Hyper-V конфигурация минрут будет использоваться только в самых крупных серверных системах. Однако эту возможность можно настроить на более низкое пороговое значение для администратора узла Hyper-V и, таким же, использовать для значительного ограничения объема ресурсов ЦП узла, доступных корневому разделу. Необходимо тщательно выбрать определенное количество используемых корневых LPs, чтобы обеспечить максимальную нагрузку на виртуальные машины и рабочие нагрузки, выделенные узлу. Однако разумные значения для числа узлов LPs можно определить с помощью тщательной оценки и мониторинга рабочих нагрузок, а также проверки в нерабочих средах перед широким развертыванием.

Включение и настройка Минрут

Конфигурация минрут контролируется с помощью записей BCD гипервизора. Чтобы включить минрут, в командной строке с правами администратора выполните следующую команду:

Где n — число корневых ВПС.

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

При наличии нескольких узлов NUMA каждый узел будет получать n/NumaNodeCount процессоры.

Обратите внимание, что с несколькими узлами NUMA необходимо убедиться в том, что топология виртуальной машины имеет достаточно свободного LPs (т. е. LPs без корневого ВПС) на каждом узле NUMA для запуска узла NUMA соответствующей виртуальной машины.

Проверка конфигурации Минрут

Конфигурацию минрут узла можно проверить с помощью диспетчера задач, как показано ниже.

Когда Минрут активен, диспетчер задач отображает количество логических процессоров, выделенных в данный момент узлу, а также общее число логических процессоров в системе.

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

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

На случай нехватки ресурсов есть дополнительные настройки, объединенные под общим названием Resource control. О них стоит рассказать поподробнее.

Virtual Machine Reserve

Этот параметр задает процент ресурсов, который будет зарезервирован за виртуальной машиной. Этот параметр играет роль в ситуации нехватки ресурсов, то есть когда физические процессоры используются на все 100%. В этом случае те из виртуальных машин, у которых задан этот параметр, должны гарантированно получить то, что за ними зарезервировано. По умолчанию Virtual Machine Reserve не задан и имеет значение 0%.

Работает этот параметр следующим образом. Возьмем виртуальную машину, выделим ей 2 виртуальных процессора и установим Virtual Machine Reserve равным 100. Это значит, что от физически имеющихся ресурсов этой виртуальной машине зарезервировано 100 % от 2 ядер, или 8% от общей процессорной мощности. Это значение отображается в поле «Percent of total system resources».

Регулировать резерв можно как через Virtual Machine Reserve, так и изменяя количество виртуальных ядер. Например, те же 8% можно получить при 8 ядрах по 25% каждое.

Резервирование не накладывает жестких ограничений на потребляемые ресурсы. Если одной из виртуальных машин потребуется больше ресурсов – они будут ей предоставлены, даже если все 100% зарезервированы. В Hyper-V свободный процессорный ресурс может легко выделяться виртуальным машинам, и так же легко у них забираться.

Параметр Virtual Machine Reserve вступает в дело только в ситуации нехватки системных ресурсов. Основное его назначение – гарантировать бесперебойную работу особо критичных виртуальных машин.

Virtual Machine Limit

Лимит применяется отдельно к каждому виртуальному процессору. К примеру, если виртуальная машина сконфигурирована с 4 процессорами и установлен лимит 50% — то она получит четыре виртуальных процессора, каждый из которых ограничивается 50%.

Обратите внимание, что в отличие от резервирования лимит задается жестко. Если Virtual Machine Limit равен 50% — виртуальная машина никогда не сможет использовать больше, даже если на сервере больше ничего не запущено.

Relative Weight

Третий параметр, Relative Weight, представляет из себя безразмерную величину и может варьироваться в пределах от 0 до 10000. По умолчанию равен 100.

Таким образом Relative Weight позволяет разделять виртуальные машины на более и менее критичные, при этом не боясь, что какая-то из них откажется запускаться из за отсутствия ресурсов.

Важный момент. Relative Weight не дает гарантий, что виртуальная машина в нужный момент получит необходимое ей количество процессорных ресурсов. Если какие-то из виртуальных машин являются особо критичными – лучше использовать Virtual Machine Reserve, который гарантирует выделение ресурсов.

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

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

Для примера будем рассматривать некий абстрактный сервер с четырьмя процессорными ядрами. Так же, все виртуальные машины по умолчанию конфигурируются с четырьмя виртуальными процессорами.

Вот они, эти настройки:

Virtual Machine Reserve

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

Работает этот параметр следующим образом. Возьмем наш 4-ядерный сервер и 5 виртуальных машин, по 4 виртуальных процессора на каждой. Если установить Virtual Machine Reserve, равный 20%, то от физически имеющихся ресурсов для каждой виртуальной машины будет зарезервировано 0,2 * 4 / 4 = 20%. Это значение отобразиться в поле «Percent of total system resources». Если у сервера будет 8 ядер, то это значение будет уже другое: 0,2 * 4 / 8 = 10%.

Но вернемся к нашим баранам. Если мы запустим все 5 наших виртуальных машин, то все процессорные ресурсы будут заняты, и запустить 6ю виртуальную машину будет можно только в том случае, если Virtual Machine Reserve установлен равным 0%:

А вот теперь более интересный пример. На той же самой 4-ядерной системе создадим две виртуальных машины. Одной из них назначим 4 виртуальных процессора, и установим Virtual Machine Reserve 50%. Это значит, что наша виртуальная машина получает половину от каждого из имеющихся ядер, половину от всех системных ресурсов сервера. Запустим ее. Второй виртуальной машине дадим два виртуальных процессора и Virtual Machine Reserve 80%. Это – 40% от всех системных ресурсов. Казалось бы, 50% + 40% = 90%. То есть вторая виртуальная машина тоже должна запуститься, но на самом деле она не запустится. А все потому, что система попытается найти два ядра, от которых можно «отщипнуть» в резерв 80%, а все 4 ядра зарезервированы на 50% каждое:

Об этом ограничении нужно всегда помнить, и не «играться» с параметром Virtual Machine Reserve без насущной необходимости. Особое внимание нужно уделять при использовании кластерных решений: при сбое одного узла возможна ситуация, что часть виртуальных машин не сможет перезапуститься на доступном узле из-за недостатка ресурсов для резервирования.

Тем не менее, резервирование здесь не совсем «жесткое». Допустим, в примере с 5ю виртуальными машинами и 20% Virtual Machine Reserve все 5 виртуальных машин простаивают. Если вдруг одной из виртуальных машин потребуется больше, чем 20% доступных ресурсов – эти ресурсы будут ей предоставлены, не смотря на то, что все 100% вроде бы как зарезервированы. Дело в том, что процессорный ресурс может легко выделяться виртуальным машинам, и так же легко у них забираться. Так что, если возникнет необходимость – резервы для всех гарантируются.

Для чего можно использовать этот параметр? Главное его назначение – гарантировать ресурсы для бизнес-критичных виртуальных машин, имеющих жесткое SLA. Кроме этого, его можно использовать для искусственного ограничения на количество одновременно запущенных виртуальных машин, хотя по моему мнению – это не самое красивое решение.

Virtual Machine Limit

Этот параметр, как и предыдущий (Virtual Machine Reserve), задается в процентах от доступных виртуальной машине ресурсов. Точно так же, как и предыдущий параметр – есть поле «Percent of total system resources» — все точно так же. По умолчанию равен 0, что означает, что никаких ограничений нет, и виртуальная машина может забирать себе столько процессорных ресурсов, сколько ей необходимо и сколько доступно физически. Ненулевое значение параметра Virtual Machine Limit означает, что виртуальная машина ни при каких условиях не сможет использовать больше процессорных ресурсов, чем разрешено. Единственное применение этого параметра – ограничить «аппетит» виртуальной машины, если используются приложения, которые слишком сильно нагружают процессор.

Так же, как и Virtual Machine Reserve, лимит применяется отдельно к каждому виртуальному процессору. К примеру, если виртуальная машина сконфигурирована с 2 процессорами и установлен лимит 50% — то она получит два виртуальных процессора, каждый из которых ограничивается 50%.

Но есть одно небольшое отличие: лимит задается жестко. Если Virtual Machine Limit равен 50% — виртуальная машина никогда не сможет использовать больше, даже если на сервере больше ничего не запущено. Кроме этого, лимит применяется отдельно к каждому виртуальному процессору. К примеру, если виртуальная машина сконфигурирована с 2 процессорами и установлен лимит 50% — то она получит два виртуальных процессора, каждый из которых лимитирован 50%.

Relative Weight

Третий параметр, о котором я хотел бы рассказать – Relative Weight. В отличие от предыдущих этот параметр – безразмерная величина, и может изменяться от 0 до 10000. По умолчанию равен 100.

До тех пор, пока у сервера имеются свободные системные ресурсы – параметр Relative Weight не проявляет себя абсолютно никак. Будь значение веса хоть 100, хоть 200, хоть 10000 – на работе виртуальных машин это не отразится. Но как только виртуальные машины начинают запрашивать больше процессорных ресурсов, чем сервер готов предоставить физически – тут-то и начинается самое интересное. Если у всех виртуальных машин значение этого параметра одинаково (к примеру, у всех 100) – то каждая из них получит равную долю процессорного ресура. А вот если у одной или нескольких виртуальных машин Relative Weight выше – это значит, что они «равнее, чем другие», и они получат больше процессорного ресурса, чем остальные. А если есть виртуальные машины с еще более высокими значениями этого параметра – то они получат еще больше. Этот параметр хорош тем, что позволяет выделять более критичные виртуальные машины, при этом не боясь, что какая-то из виртуальных машин откажется запускаться, и придется менять настройки еще и для нее. Но есть один небольшой нюанс: Relative Weight вовсе не дает гарантий, что виртуальная машина в трудную минуту получит ровно столько процессорных ресурсов, сколько ей нужно. Если какие-то из виртуальных машин являются особо критичными, и на них распространяются жесткие SLA – лучше использовать Virtual Machine Reserve, который гарантирует выделение ресурсов.

Если систему обслуживают несколько администраторов – то необходимо договориться о единой шкале для параметра Relative Weight. В частности, если один будет ставить для некритичныхвиртуальных машин значение 100, для критичных 200, а другой будет ставить 500 для некритичных и 1000 для критичных – система может повести себя немного непредсказуемо. Но это уже вопрос стандартизации, и в более-менее сложных системах, которые управляются более чем одним администратором – такие договоренности должны быть a priori.

В тройке лидеров на рынке софта для виртуализации операционных систем – VMware, VirtualBox и Hyper-V – последний гипервизор занимает особое место. Такое особое место обусловлено тем, что Hyper-V является штатным компонентом серверных систем Windows и некоторых версий Windows для настольных ПК. Уступая VMware Workstation и VirtualBox в функциональности, кроссплатформенности и отчасти в удобстве пользования, Hyper-V, тем не менее, не лишен своих преимуществ. И главное из них – более высокая производительность гостевых ОС.

Ниже речь пойдет об активации Hyper-V в системе Windows 10 и создании средствами этого гипервизора виртуальной машины.

1. Hyper-V - штатный гипервизор от Microsoft

Штатный компонент Hyper-V система Windows 10 унаследовала от версий Windows 8 и 8.1, а в них гипервизор перекочевал из Windows Server. И Windows 8.1, и Windows 10 опционально предусматривают компонент Hyper-V в редакциях Pro и Enterprise. Работа гипервизора возможна только в 64-битных системах.

Длительное время Hyper-V не поддерживал никаких иных гостевых ОС, кроме как Windows. Однако относительно недавно компания Microsoft позаботилась о поддержке гипервизором гостевой ОС Linux. И сегодня с помощью Hyper-V можно тестировать некоторые дистрибутивы Linux, в частности, популярный Ubuntu.

2. Требования для работы Hyper-V

Минимальный объем оперативной памяти физического компьютера для работы Hyper-V – 4 Гб.

Процессор компьютера должен поддерживать технологию SLAT (Intel EPT или AMD RVI). Практически все современные процессоры соответствуют этому требованию.

Другое требование к процессору, также предусматриваемое многими современными моделями – поддержка технологии аппаратной виртуализации и, соответственно, ее активное состояние в BIOS. В BIOS материнских плат для процессоров Intel такая технология (в зависимости от версии) может называться по-разному – Intel-VT, Intel Virtualization Technology, Intel VT-x, Vanderpool или Virtualization Extensions. У AMD технология аппаратной виртуализации называется AMD-V или SVM (Secure Virtual Machines). Например, в AMI BIOS версии 17.9 функцию аппаратной виртуализации процессора AMD можно найти по пути Cell Menu – CPU Feature – SVM Support.

У процессоров AMD функция аппаратной виртуализации, как правило, включена по умолчанию. Поддерживает ли конкретная модель процессора аппаратную виртуализацию, этот момент можно выяснить на сайтах компаний Intel и AMD.

3. Активация и запуск Hyper-V

Hyper-V в комплекте Windows 10 Pro и Enterprise поставляется опционально. Изначально штатный гипервизор отключен. Включается он в разделе панели управления «Программы и компоненты». Самый быстрый способ попасть туда – внутрисистемный поиск.

Запускаем «Включение и отключение системных компонентов».

В появившемся небольшом окошке галочкой отмечаем все подпункты пункта Hyper-V. Жмем «Ок».

Система пару секунд будет применять изменения и попросит перезагрузку. После перезагрузки ищем ярлык запуска диспетчера Hyper-V. Ярлык диспетчера Hyper-V можно сразу закрепить на начальном экране Windows 10, найдя его в средствах администрирования меню «Пуск».

Доступ к ярлыку диспетчера Hyper-V также можно получить с помощью внутрисистемного поиска.

Запускаем диспетчер Hyper-V.

4. Настройка доступа к сети

В диспетчере Hyper-V сеть настраивается отдельным этапом, и сначала нужно создать виртуальный коммутатор – параметр, обеспечивающий доступ к сети. Делаем клик на названии физического компьютера, а в правой части окна выбираем «Диспетчер виртуальных коммутаторов…».

Запустится мастер создания виртуального коммутатора, где первым делом нужно выбрать тип сети. Их три:

Внешняя – этот тип использует сетевую карту или адаптер Wi-Fi физического компьютера и подключает виртуальную машину к той же сети, в которой находится физический компьютер. Соответственно, это тип сети, предусматривающий доступ виртуальной машины к Интернету;
Внутренняя – этот тип обеспечивает сеть между физическим компьютером и виртуальными машинами Hyper-V, но не предусматривает их доступ к Интернету;
Частная – этот тип позволяет создать сеть между виртуальными машинами Hyper-V, но в этой сети не будет физического компьютера, равно как и не будет выхода в Интернет.

В нашем случае доступ виртуальной машины к Интернету необходим, потому выберем первый тип - внешнюю сеть. Жмем «Создать виртуальный коммутатор».

В окне свойств виртуального коммутатора задаем ему имя, это может быть какое угодно имя, например, «Сетевая карта 1». При необходимости виртуальному коммутатору можно добавить примечание. Если физический компьютер имеет на борту и сетевую карту, и адаптер Wi-Fi, конкретное устройство, посредством которого виртуальная машина будет подключаться к сети, можно выбрать из выпадающего списка в графе «Тип подключения». После проделанных настроек жмем «Применить» внизу окна.

5. Создание виртуальной машины

Теперь можно приступить непосредственно к созданию виртуальной машины. Слева в окне Hyper-V выбор по-прежнему должен быть на названии физического компьютера. В правом углу вверху жмем «Создать», затем – соответственно, «Виртуальная машина».

В приветственном окне запустившегося мастера жмем «Далее».

Задаем виртуальной машине имя; также можно сменить ее месторасположение на диске физического компьютера, указав нужный раздел диска и нужную папку с помощью кнопки обзора. Жмем «Далее».

Одна из относительно новых возможностей Hyper-V – выбор поколения виртуальной машины. В нашем случае выбрано поколение 2.

Что это значит? Поколение 1 – это виртуальные машины, поддерживающие 32- и 64-битные системы Windows. Поколение 1 совместимо с прежними версиями Hyper-V.

Поколение 2 – виртуальные машины нового формата со встроенным программным обеспечением на базе UEFI. Такие виртуальные машины поддерживают ряд новых возможностей и способны обеспечить небольшой прирост производительности. На виртуальные машины поколения 2 в качестве гостевых ОС устанавливаются только 64-битные версии Windows 8.1 и 10, а также серверные Windows Server 2012, Server 2012 R2 и Server 2016.

Вам может быть интересно: Как убрать надпись пробная версия

Платформа UEFI обуславливает еще одно требование для использования виртуальных машин поколения 2 – загрузочный носитель UEFI. Этот момент необходимо уточнять, скачивая ISO-образ с дистрибутивом Windows со сторонних источников в Интернете. Но лучше все же скачивать дистрибутивы Windows с официальных источников компании Microsoft. Так, утилита Media Creation Tool, скачивающая с сайта Microsoft дистрибутивы Windows 8.1 и 10 , на выходе создает загрузочный ISO-образ, поддерживающий среду UEFI.

В случае установки в качестве гостевой ОС Windows 10 именно такой способ получения ISO-образа системы и рекомендуется. Windows 10 предусматривает процесс установки с возможностью отложенного ввода ключа продукта. В нашем случае в качестве гостевой ОС будет установлена Windows 8.1, а ее официальный дистрибутив, получаемый с помощью утилиты Media Creation Tool, в процессе установки требует ввод ключа продукта. Обеспечить поддержку среды UEFI и воспользоваться бесплатной возможностью протестировать систему Windows 8.1 поможет сайт Центра пробного ПО TechNet. На этом сайте можно скачать англоязычную редакцию 64-битной Windows 8.1 Корпоративная и бесплатно тестировать систему целых 3 месяца. Проблему с отсутствием поддержки русского языка после установки системы можно решить отдельно, установив языковой пакет и настроив русский основным языком системы.

Возвращаемся к мастеру создания виртуальной машины. В окне выделения памяти оставляем предустановленные параметры, если физический компьютер имеет не более 4 Гб оперативной памяти. Если ее больше 4 Гб, можно увеличить показатель, выделяемый при запуске виртуальной машины. Для гостевой Windows ХР показатель оперативной памяти можно, наоборот, уменьшить до 512 Мб. Жмем «Далее».

В окне настроек сети из выпадающего списка выбираем ранее созданный виртуальный коммутатор. Жмем «Далее».

В окне подключения виртуального жесткого диска задаем виртуальной машине имя, указываем расположение на диске физического компьютера, указываем размер. Это параметры создания нового жесткого диска. Второй пункт этого шага мастера используется, когда на компьютере уже имеется виртуальный жесткий диск, в частности, с установленной гостевой ОС. При выборе виртуальной машины поколения 2 файл такого виртуального жесткого диска должен иметь формат VHDX (а не VHD), а гостевая ОС должна поддерживать среду загрузки UEFI. Жмем «Далее».

Если в предыдущем шаге мастера выбран пункт создания нового виртуального жесткого диска, следующим шагом будет указание пути к дистрибутиву Windows. Виртуальные машины поколения 2 уже не предусматривают загрузку с физического CD/DVD-привода. Источниками загрузки дистрибутива гостевой ОС могут быть только сеть и ISO-образ. В нашем случае это ISO-образ. Жмем «Далее».

Завершающий этап мастера – жмем «Готово».

6. Подключение виртуальной машины

Создав виртуальную машину, вернемся в окно диспетчера Hyper-V. Теперь ее нужно подключить. Для этого существует команда «Подключить» в числе прочих команд контекстного меню, вызываемого на виртуальной машине. Команда «Подключить» присутствует и в правой части окна диспетчера Hyper-V. Для подключения также можно сделать двойной клик левой клавишей мыши на окошке-превью выбранной виртуальной машины.

В открывшемся окне подключения жмем зеленую кнопку запуска.

Далее нажимаем любую кнопку, чтобы виртуальная машина загрузилась с ISO-образа.

Последует обычный процесс установки Windows 8.1, как это происходило бы на физическом компьютере.

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

Закрытие окна подключения высвободит какие-то ресурсы физического компьютера для выполнения других задач, при этом виртуальная машина продолжит свою работу в фоновом режиме. Ее рабочие показатели будут отображаться в диспетчере Hyper-V.

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

Все – Windows 8.1 установилась. Выключить, приостановить, сохранить виртуальную машину или сбросить ее состояние можно и командами в диспетчере Hyper-V, и кнопками на верхней панели окна подключения.

7. Приоритет загрузки

Чтобы в дальнейшем при запуске виртуальной машины не терять время на окно загрузки с CD/DVD-диска, нужно в выключенном ее состоянии открыть окно параметров и убрать путь к ISO-файлу с дистрибутивом. Это делается во вкладке DVD-привода настроек оборудования виртуальной машины.

Альтернативный вариант – поднять жесткий диск в приоритете загрузки выше DVD-привода (но не выше файла «bootmgfw.efi»). Это делается во вкладке «Встроенное ПО» настроек оборудования.

В обоих случаях проделанные изменения сохраняются кнопкой «Применить» внизу.

8. Обход ограничений окна подключения Hyper-V

Во главу угла работы гипервизора Hyper-V поставлена производительность виртуальных машин, а не функциональность. В отличие от своих конкурентов – VMware и VirtualBox – виртуальные машины Hyper-V не работают с подключенными флешками, не воспроизводят звук, а взаимодействие с физическим компьютером осуществляется только вставкой внутри гостевых ОС текста, скопированного в основной ОС. Такова цена производительности виртуальных машин Hyper-V. Но это если работать с обычным окном подключения Hyper-V.

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

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

Подключение к виртуальной машине таким образом обеспечит в гостевой ОС воспроизведение звука и двустороннюю передачу файлов.

Читайте также: