Установка и настройка Hyper-V: виртуальные машины, виртуальные коммутаторы

До этого момента вся наша лаборатория itpages.lab.local существовала либо на физическом железе, либо где-то в облаке стороннего гипервизора. Пришло время взять управление виртуализацией в свои руки и поднять собственный сервер Hyper-V — srv-hv01. Это не только способ сэкономить на железе, разместив несколько серверов на одном физическом хосте, но и фундамент для тестовых стендов, снапшотов перед рискованными изменениями и быстрого восстановления после неудачного эксперимента.

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

Проверка совместимости оборудования

Прежде чем ставить роль, убедись, что процессор поддерживает аппаратную виртуализацию и она включена в BIOS/UEFI. Проверить это средствами Windows можно так:

Get-ComputerInfo -Property "HyperV*"

systeminfo | findstr /i "Hyper-V"

Если в выводе видно, что виртуализация в прошивке отключена, придётся зайти в настройки BIOS и включить Intel VT-x или AMD-V — без этого роль Hyper-V установится, но не сможет запускать виртуальные машины.

Установка роли Hyper-V

Ставим роль вместе с инструментами управления PowerShell — они пригодятся для скриптования создания машин в будущем:

Install-WindowsFeature -Name Hyper-V -IncludeManagementTools -Restart

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

Планирование виртуальных коммутаторов

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

• External — коммутатор привязан к физическому сетевому адаптеру, виртуальные машины получают доступ к реальной сети 192.168.10.0/24 наравне с физическими устройствами.
• Internal — виртуальные машины видят друг друга и сам хост, но не имеют выхода в физическую сеть; удобно для изолированных тестовых стендов.
• Private — виртуальные машины видят только друг друга, хост в этой сети не участвует вообще; используется для полностью закрытых лабораторных экспериментов.

Создание виртуальных коммутаторов

Для большинства серверов лаборатории, которые должны быть доступны из общей сети, создаём внешний коммутатор, привязанный к физическому адаптеру хоста:

Get-NetAdapter

New-VMSwitch -Name "External-LAN" -NetAdapterName "Ethernet0" -AllowManagementOS $true

Параметр -AllowManagementOS $true оставляет хостовой системе доступ к сети через тот же адаптер — без него сам сервер srv-hv01 потеряет сетевое подключение сразу после создания коммутатора, что при удалённом администрировании обернётся полной потерей связи с сервером.

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

New-VMSwitch -Name "Internal-Lab" -SwitchType Internal

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

Создаём виртуальную машину под будущий тестовый сервер, используя поколение 2 (Generation 2) — оно поддерживает UEFI, Secure Boot и в целом лучше подходит для современных версий Windows Server:

New-VM -Name "srv-test01" -Generation 2 -MemoryStartupBytes 4GB `
  -NewVHDPath "D:\VMs\srv-test01\srv-test01.vhdx" -NewVHDSizeBytes 60GB `
  -SwitchName "External-LAN" -Path "D:\VMs"

Подключаем ISO-образ для установки системы и настраиваем количество виртуальных процессоров и динамическую память, чтобы не резервировать фиксированный объём оперативной памяти хоста под каждую машину:

Set-VMDvdDrive -VMName "srv-test01" -Path "D:\ISO\WindowsServer2025.iso"
Set-VMProcessor -VMName "srv-test01" -Count 2
Set-VMMemory -VMName "srv-test01" -DynamicMemoryEnabled $true -MinimumBytes 2GB -MaximumBytes 8GB -StartupBytes 4GB

Настройка Secure Boot и запуск

Для виртуальных машин поколения 2 с Windows Server имеет смысл оставить Secure Boot включённым — он защищает загрузочный процесс от подмены загрузчика вредоносным кодом:

Get-VMFirmware -VMName "srv-test01"

Start-VM -Name "srv-test01"
vmconnect localhost srv-test01

Контрольные точки (снапшоты)

Одно из главных преимуществ виртуализации — возможность сохранить состояние машины перед рискованным изменением и откатиться назад одной командой, если что-то пошло не так:

Checkpoint-VM -Name "srv-test01" -SnapshotName "Before-Update-2026-08"

Get-VMCheckpoint -VMName "srv-test01"
Restore-VMCheckpoint -Name "Before-Update-2026-08" -VMName "srv-test01" -Confirm:$false

Важно понимать, что контрольные точки — это не полноценный бэкап, а скорее временная страховка для конкретной операции. Оставлять их накопленными месяцами не стоит: каждая контрольная точка добавляет накладные расходы на дисковые операции и постепенно замедляет работу виртуальной машины.

Ограничение ресурсов и мониторинг хоста

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

Set-VMProcessor -VMName "srv-test01" -Reserve 10 -Maximum 60

Get-VM | Select-Object Name, State, CPUUsage, MemoryAssigned, Uptime

Регулярно проверяй общую загрузку хоста srv-hv01 — если суммарное потребление памяти виртуальными машинами приближается к физическому объёму хоста, самое время либо добавить память, либо пересмотреть распределение нагрузки между машинами.

Экспорт и перенос виртуальных машин

Одно из практических преимуществ Hyper-V — лёгкость переноса готовой машины на другой хост, например при замене железа или переезде в новый дата-центр. Экспортируй виртуальную машину целиком вместе со всеми виртуальными дисками и конфигурацией:

Export-VM -Name "srv-test01" -Path "D:\Export"

Import-VM -Path "D:\Export\srv-test01\Virtual Machines\<GUID>.vmcx" -Copy -GenerateNewId

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

Организация хранения виртуальных дисков

По мере роста числа виртуальных машин важно не потерять контроль над дисковым пространством хоста. Заведи единую структуру папок по типу D:\VMs\<имя-машины>\ и периодически проверяй реальный размер файлов VHDX, особенно если используются динамически расширяемые диски:

Get-VHD -Path "D:\VMs\srv-test01\srv-test01.vhdx" | Select-Object Path, VhdType, Size, FileSize

Optimize-VHD -Path "D:\VMs\srv-test01\srv-test01.vhdx" -Mode Full

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

Репликация виртуальных машин

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

Enable-VMReplication -VMName "srv-test01" -ReplicaServerName "srv-hv02.itpages.lab.local" `
  -ReplicaServerPort 80 -AuthenticationType Kerberos

Start-VMInitialReplication -VMName "srv-test01"

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

Виртуальные жёсткие диски: типы и когда что использовать

Hyper-V поддерживает три типа виртуальных дисков, и выбор между ними влияет и на производительность, и на удобство управления местом на хосте:

• Динамически расширяемый (Dynamic) — занимает на хосте ровно столько места, сколько реально записано внутри гостевой ОС, растёт по мере необходимости. Удобен для экономии места, но чуть медленнее фиксированного из-за необходимости расширять файл на лету.
• Фиксированного размера (Fixed) — сразу резервирует на хосте весь заявленный объём. Немного быстрее и предсказуемее по производительности, поэтому рекомендуется для продуктивных нагрузок с интенсивным вводом-выводом, например баз данных.
• Разностный (Differencing) — хранит только отличия от родительского диска. Полезен для быстрого создания множества похожих тестовых машин на основе одного golden-образа, но для продакшена не годится из-за зависимости от родителя.

New-VHD -Path "D:\VMs\Templates\golden.vhdx" -SizeBytes 60GB -Fixed

New-VHD -Path "D:\VMs\srv-test02\srv-test02.vhdx" -ParentPath "D:\VMs\Templates\golden.vhdx" -Differencing

Виртуальные машины поколения 2 против поколения 1

Поколение 2, которое мы использовали для srv-test01, подходит только для 64-битных гостевых ОС не старше Windows Server 2012 / Windows 8 и поддерживает UEFI, Secure Boot и загрузку напрямую с виртуального SCSI-контроллера без эмуляции IDE. Поколение 1 нужно только для устаревших гостевых систем или специфичного legacy-софта, требующего BIOS-загрузки:

Get-VM -Name "srv-test01" | Select-Object Name, Generation, State

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

Nested-виртуализация для тестовых стендов

Если внутри виртуальной машины на srv-hv01 тебе самому нужен ещё один уровень Hyper-V — например, чтобы смоделировать целый кластер внутри одной физической машины лаборатории, — включи вложенную виртуализацию явно, по умолчанию она выключена:

Set-VMProcessor -VMName "srv-test01" -ExposeVirtualizationExtensions $true

Get-VMNetworkAdapter -VMName "srv-test01" | Set-VMNetworkAdapter -MacAddressSpoofing On

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

Интеграционные службы и обновление гостевых дополнений

Интеграционные службы Hyper-V (Integration Services) обеспечивают корректную работу мыши, синхронизацию времени с хостом, плавное выключение из консоли управления и обмен файлами между хостом и гостем. На современных версиях Windows Server они обновляются вместе с Windows Update, но стоит периодически проверять их состояние, особенно после миграции машины со старого хоста:

Get-VMIntegrationService -VMName "srv-test01" | Select-Object Name, Enabled, PrimaryStatusDescription

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

Частые ошибки и как их избежать

• Внешний коммутатор без AllowManagementOS. Создание внешнего коммутатора без этого параметра моментально обрывает сетевой доступ к самому хосту, если управление велось через тот же адаптер. Для удалённого сервера это означает полную потерю доступа до физического вмешательства.
• Фиксированная память на всех машинах одновременно. Если задать каждой виртуальной машине статический максимум памяти без учёта общего объёма хоста, легко превысить физические ресурсы и получить деградацию производительности всех машин сразу. Используй динамическую память там, где нагрузка непостоянна.
• Накопление старых контрольных точек. Забытые снапшоты годовой давности не только занимают место на диске, но и замедляют работу машины из-за цепочки дифференцирующих дисков. Удаляй контрольные точки сразу после того, как необходимость в откате отпала.
• Отсутствие плана размещения по хостам. Когда все критичные машины крутятся на одном физическом хосте без резервирования, его отказ останавливает сразу всю инфраструктуру. Распределяй критичные роли — контроллер домена, файловый сервер — так, чтобы они не зависели от единственной точки отказа.

Автор — Команда IT-Pages