Для планового обслуживания используйте Live Migration, чтобы перенести работающую виртуальную машину на другой хост, или Storage Migration, чтобы перенести только её файлы. Hyper-V Replica создаёт асинхронную копию VM для управляемо го аварийного переключения, а failover cluster автоматически перезапускает кластерную VM после отказа узла. Эти механизмы можно сочетать, но ни один из них не заменяет резервное копирование.
Выбор механизма по задаче
| Цель | Механизм | Простой и переключение | RPO | Основные требования |
|---|---|---|---|---|
| Освободить хост для обновления или ремонта | Live Migration | VM остаётся включённой; при финальном переключении возможна краткая пауза | Не применяется: это перенос, а не репликация | Совместимые хосты, сеть миграции, целевой хост с ресурсами, аутентификация |
| Перенести VHDX и конфигурацию на другое хранилище, не меняя хост | Storage Migration | VM обычно может продолжать работать; финальный этап может кратко повлиять на I/O | Не применяется | Доступное целевое хранилище и достаточное свободное место |
| Перенести VM и её файлы на другой хост | Live Migration вместе со Storage Migration | Работа VM обычно сохраняется с краткой паузой при переключении | Не применяется | Требования обеих операций |
| Восстановить VM на отдельном или удалённом сервере после аварии | Hyper-V Replica | Переключение выполняется оператором: planned failover, failover или test failover | Зависит от интервала репликации и фактического состояния репликации | Сеть между площадками, Kerberos или сертификаты, авторизация реплики, DNS и firewall |
| Автоматически восстановить VM при отказе одного узла | Hyper-V failover cluster | Кластер обнаруживает отказ и запускает VM на другом узле; гостевая ОС и приложение перезапускаются | Не применяется: используются те же кластерные файлы VM | Валидированный кластер, quorum, подходящее хранилище, N+1-ёмкость |
Границы возможностей и поддерживаемые выпуски
Ниже описана типичная конфигурация для Windows Server 2019 и Windows Server 2022 с ролью Hyper-V. Эти выпуски поддерживают Live Migration, Storage Migration, Hyper-V Replica и Failover Clustering; доступность отдельных параметров зависит от редакции, установленных обновлений, способа управления и конфигурации хостов. В Microsoft Learn сверяйте руководства Hyper-V live migration overview, Move virtual machine storage, Hyper-V Replica overview и Failover Clustering overview именно для своего выпуска Windows Server.
Для Windows Server 2019 и 2022 роли Hyper-V и Failover Clustering доступны в редакциях Standard и Datacenter. Storage Spaces Direct — отдельная архитектура распределённого хранения на локальных дисках узлов — требует Datacenter. Лицензирование гостевых ОС, права на запуск экземпляров Windows Server и возможность использовать дополнительные компоненты нужно сверять с актуальными лицензионными условиями Microsoft: техническое наличие роли не подтверждает лицензионное право для конкретного числа VM.
О названиях в интерфейсе
Названия страниц, кнопок, состояний и параметров в Hyper-V Manager, Failover Cluster Manager, Windows Admin Center и PowerShell зависят от версии Windows Server, сборки, языка и способа управления. Для рабочей процедуры сверяйте формулировки с официальным руководством Microsoft для своего выпуска, а не переносите путь по меню из другой версии.
Live Migration и Storage Migration: что переносится
Live Migration переносит вычислительное состояние запущенной VM между хостами виртуализации. Память VM копируется на целевой хост в несколько проходов; затем VM кратко приостанавливается, передаются оставшиеся изменённые страницы и управление продолжает целевой узел. Диски могут оставаться на общем хранилище либо переноситься вместе с VM, если выбран вариант с переносом хранения.
Storage Migration переносит расположение файлов VM, не меняя хост выполнения. В типичном сценарии переносятся файлы конфигурации, виртуальные диски VHDX, файлы контрольных точек и связанные файлы состояния. Целью может быть локальный том хоста, SMB 3.x-файловый ресурс или поддерживаемое кластерное хранилище — при условии, что выбранный хост имеет к нему нужный доступ.
«Без простоя» не означает отсутствия любого эффекта
Live Migration не следует обещать как нулевой простой. На финальном переключении VM кратко приостанавливается; активные сетевые соединения обычно сохраняются, но чувствительные к задержкам приложения могут заметить паузу или тайм-аут. Миграция не защищает от внезапного отказа исходного хоста до завершения операции, от повреждения гостевых данных и от отказа общего хранилища, сети или доменной инфраструктуры.
Подготовка и запуск Live Migration между двумя Hyper-V-хостами
Порядок подходит для самостоятельных Hyper-V-хостов Windows Server 2019 или 2022. Перед началом зафиксируйте текущий хост, пути к файлам VM, IP-адреса, используемые виртуальные коммутаторы и способ возврата.
- 1Проверьте версию, роль и ресурсы обоих хостовНа источнике и назначении убедитесь, что установлены роль Hyper-V и совместимые обновления Windows Server, а на целевом хосте достаточно CPU, RAM, места для файлов VM при переносе хранения и пропускной способности сети. Если VM использует закреплённые устройства, SR-IOV, Discrete Device Assignment, включая назначенный GPU, или иные специальные функции, отдельно подтвердите их поддержку на целевом хосте; такие конфигурации могут ограничить миграцию.
- 2Сверьте процессоры и виртуальное оборудованиеДля Live Migration без режима совместимости процессоры хостов должны быть совместимы; перенос между Intel и AMD не поддерживается. При миграции между разными поколениями CPU одного производителя можно включить для VM режим процессорной совместимости, но он скрывает часть новых инструкций и должен быть проверен для нагрузки заранее. Поколение VM, количество vCPU, виртуальные адаптеры и подключённые носители должны поддерживаться обоими хостами.
- 3Подготовьте сеть управления и сеть миграцииПроверьте взаимную DNS-разрешимость имён хостов, двустороннюю IP-связность и правила Windows Firewall для Live Migration. Для предсказуемой нагрузки выделите или приоритизируйте сеть миграции, не смешивая её без расчёта с критичным трафиком VM и хранил ища. Live Migration может использовать TCP/IP, сжатие или SMB; режим выбирайте по возможностям сети и хранилища.
- 4Настройте аутентификацию запускаCredSSP используйте, когда администратор входит на исходный хост и запускает перенос непосредственно с него: CredSSP передаёт учётные данные удалённому компьютеру, но не решает задачу второго перехода при запуске с отдельной управляющей машины. Для запуска из удалённой консоли управления используйте Kerberos и корректно настройте constrained delegation для компьютерных учётных записей хостов и требуемых служб миграции. Если удалённый запуск выдаёт ошибку делегирования, не обходите её передачей пароля: проверьте SPN, DNS и настройки делегирования в Active Directory.
- 5Сопоставьте виртуальные коммутаторыНа целевом хосте должен существовать совместимый виртуальный коммутатор Hyper-V, к которому можно подключить сетевые адаптеры VM. Практически безопаснее создать эквивалентный коммутатор с тем же именем и нужными VLAN, uplink и политиками до миграции. После переноса проверьте MAC-адреса, VLAN и доступность VM из её рабочих сетей.
- 6Сначала перенесите некритичную VMЗапустите перенос одной некритичной VM через Hyper-V Manager, Windows Admin Center или PowerShell. Наблюдайте состояние задачи, нагрузку сети и диска. Успешный результат: VM отображается на целевом хосте, гостевая ОС работает, сеть и приложения доступны. При ошибке остановите массовые переносы и локализуйте проблему по событиям Hyper-V, сети, делегированию и хранилищу; маршрут диагностики приведён в статье «Диагностика проблем виртуальных машин и гипервизоров».
- 7Подтвердите результат и возможность возвратаПосле миграции сравните конфигурацию VM с инвентаризацией: хост, пути дисков, виртуальные сети, контрольные точки, доступность сервисов и резервного копирования. Не удаляйте исходные файлы вручную: успешная операция сама должна завершить перенос. Возврат выполняйте обратной миграцией только после выяснения причины, если целевой хост или сеть работают нестабильно.
Показывает, разрешена ли входящая Live Migration на текущем хосте, выбранную аутентификацию и режим производительности. Выполните на обоих хостах PowerShell от имени администратора.
Get-VMHost | Format-List VirtualMachineMigrationEnabled,VirtualMachineMigrationAuthenticationType,VirtualMachineMigrationPerformanceOptionВывод:
Ожидаемый результат: VirtualMachineMigrationEnabled : True. Если значение False, включите Live Migration в настройках хоста и повторно проверьте firewall и аутентификацию.Пример переноса работающей VM на другой хост при доступном общем хранилище. Имя хоста должно разрешаться в DNS, а учётная запись должна иметь права на оба хоста.
Move-VM -Name "Test-VM" -DestinationHost "HV02.contoso.example"Вывод:
Ожидаемый результат: задача завершается без ошибки, а Test-VM запускается на HV02. Если файлы VM лежат на локальном диске источника, используйте Storage Migration или параметр переноса хранения после проверки свободного места на назначении.Пример Storage Migration: переносит файлы VM в новое расположение на том же хосте. Целевой каталог должен быть доступен службе Hyper-V и иметь достаточный запас места.
Move-VMStorage -VMName "Test-VM" -DestinationStoragePath "D:\Hyper-V\Test-VM"Вывод:
Ожидаемый результат: пути конфигурации и дисков VM меняются на целевые, VM продолжает работать. При нехватке места или ошибке доступа не удаляйте частично создан ные файлы до анализа состояния задачи.Когда достаточно Storage Migration
Storage Migration достаточно, если проблема относится только к хранилищу: нужно заменить локальный массив, освободить том, перенести VM на более производительное хранилище или изменить структуру каталогов, а текущий Hyper-V-хост остаётся рабочим и имеет нужные ресурсы. Это не переносит вычислительное состояние на другой сервер и не освобождает хост для перезагрузки.
Выбирайте Live Migration, когда обслуживается сам хост: обновляется Windows Server, firmware, сетевой адаптер, память или физический сервер. Если одновременно меняются хост и расположение файлов VM, используйте комбинированный перенос после отдельной проверки ресурсов сети и места на целевом хранилище. Общие варианты live, cold, V2V и P2V-миграции разобраны отдельно в статье «М играция виртуальных машин: live migration, V2V и P2V».
Hyper-V Replica: аварийная копия, а не непрерывная работа
Hyper-V Replica асинхронно передаёт изменения выбранной VM с первичного сервера на сервер-реплику. Реплицированная VM в обычном режиме не работает одновременно с исходной: копия предназначена для запуска при planned failover или аварийном failover. Поэтому Replica подходит для восстановления на отдельном сервере или площадке, а не для миграции без простоя.
Replica, кластер и резервное копирование решают разные задачи
| Механизм | Что происходит при отказе хоста | Что защищает | Главное ограничение |
|---|---|---|---|
| Hyper-V Replica | Оператор выполняет failover на сервере-реплике | Отказ первичной площадки или хоста при доступной реплике | Асинхронность: последние изменения могут не попасть в реплику |
| Failover cluster | Кластер пытается запустить VM на доступном узле | Отказ одного узла при доступной кластерной инфраструктуре | Гостевая ОС и сервис перезапускаются; общий компонент может остаться точкой отказа |
| Резервная копия | Данные восстанавливают в согласованную точку по процедуре backup | Удаление, логическое повреждение, длительные сбои и исторические версии | Восстановление обычно требует больше времени, чем failover |
Replica не равна резервной копии
Replica способна передать на вторую площадку удаление файла, ошибочное изменение базы данных или логическое повреждение, если оно успело войти в поток репликации. Её фактический RPO определяется настроенным интервалом, задержкой сети, очередью репликации и последним успешно применённым изменением. Нужны отдельные резервные копии с независимым сроком хранения и проверенным восстановлением.
Для Windows Server 2019 и 2022 Microsoft документирует интервалы репликации 30 секунд, 5 минут или 15 минут. Можно настроить до 24 дополнительных почасовых точек восстановления; фактическая глубина истории зависит от выбранной конфигурации, свободного места и состояния репликации. Extended replication создаёт вторую цепочку с сервера-реплики на расширенный сервер-реплику; для неё в этих выпусках используются интервалы 5 или 15 минут. Перед включением параметров сверяйте документацию Microsoft для установленного выпуска: в других версиях доступные значения могут отличаться.
Настройка Hyper-V Replica и безопасная проверка переключения
Planned failover, обратную репликацию и тест аварийного переключения выполняйте сначала на некритичной VM либо в согласованное окно. Не запускайте первичную VM и её аварийную копию одновременно в одной производственной сети.
- 1Определите RPO, сервер-реплику и сетьЗафиксируйте требуемый RPO и выберите доступный интервал репликации — 30 секунд, 5 минут или 15 минут — который не превышает допустимую потерю данных и подходит нагрузке. Настроенный интервал сам по себе не гарантирует такой RPO: задержка сети, очередь и ошибки применения изменений могут увеличить фактическую потерю данных. Подготовьте сервер-реплику с достаточными CPU, памятью и местом под VHDX, точки восстановления и рост данных. Проверьте DNS в обоих направлениях и маршрут между первичным и реплицирующим хостами.
- 2Выберите и подготовьте аутентификациюДля доменных серверов обычно используют Kerberos по HTTP; стандартный порт Hyper-V Replica — TCP 80. Для репликации между недоверенными доменами или рабочими группами используйте сертификатную аутентификацию по HTTPS; стандартный порт — TCP 443. Сертификат должен быть доверен участвующими сторонами и содержать имя, по которому первичный сервер обращается к реплике. Откройте только необходимый входящий TCP-порт на сервере-реплике и проверьте его сетевым тестом до начальной репликации.
- 3Авторизуйте источник на сервере-репликеНа сервере-реплике включите приём репликации, выберите Kerberos или сертификаты и задайте, какие первичные серверы или доверенные группы вправе создавать реплики. Укажите разрешённые пути хранения. Не используйте разрешение для всех серверов без необходимости: ограничьте список известными хостами или группой, применимой к вашей архитектуре.
- 4Включите репликацию для одной VMДля выбранной VM укажите сервер-реплику, порт, тип аутентификации, целевое расположение файлов, интервал, число точек восстановления и способ начальной репликации. Если исходные диски уже доступны на целевой площадке, допустимы поддерживаемые сценарии initial replication через внешний носитель или предварительно размещённые файлы; убедитесь, что они относятся к той же VM и корректно сопоставлены.
- 5Дождитесь начальной репликации и проверьте здоровьеНачальная репликация должна завершиться успешно, а состояние репликации — стать норма льным. Проверьте время последней отправки, очередь ожидающих изменений, свободное место на сервере-реплике и журналы Hyper-V. Если очередь растёт, не считайте заявленный RPO достигнутым: проверьте сеть, производительность дисков, нагрузку хостов и ошибки аутентификации.
- 6Выполните test failover в изолированной сетиСоздайте тестовую копию реплики через операцию test failover и подключите её к отдельному тестовому виртуальному коммутатору либо изолированному VLAN. Исходная VM и штатная реплика продолжают существовать; тестовая VM не должна получить доступ в ту же производственную сеть с теми же IP и именем. Проверьте загрузку гостевой ОС, диски, службы и прикладную целостность, затем удалите тестовую копию штатной операцией завершения теста.
- 7Проверьте planned failover и возвратДля планового переключения убедитесь, что реплика здорова и очередь изменений обработана, затем штатно завершите работу и выключите первичную VM. После этого запустите planned failover: Hyper-V передаст оставшиеся изменения и запустит реплику на новой стороне. После проверки сервисов настройте обратную репликацию, чтобы прежний первичный сервер получил роль реплики. Не считайте процедуру переключения и подготовки возврата завершённой, пока обратное направление не инициализировано и не показывает нормальный статус.
Проверяет TCP-доступность HTTPS-порта Hyper-V Replica при сертификатной аутентификации. Для Kerberos по HTTP замените 443 на 80.
Test-NetConnection -ComputerName "HV-REPLICA.contoso.example" -Port 443Вывод:
Ожидаемый результат: TcpTestSucceeded : True. При False проверьте DNS-имя, маршрут, Windows Firewall, межсетевой экран и то, что сервер-реплика принимает соединения на выбранном протоколе.Запускает test failover для уже созданной реплики. Выполните команду на сервере-реплике. До подключения сетевого адаптера созданной тестовой VM убедитесь, что он отключён от производственной сети или подключён только к заранее подготовленному изолированному коммутатору, например Replica-Test-Isolated.
Start-VMFailover -VMName "Test-VM" -AsTestВывод:
Ожидаемый результат: создаётся тестовая VM, не изменяющая рабочую репликацию. Проверьте её сетевое подключение до запуска прикладных тестов. После проверки завершите test failover штатной операцией в используемой консоли или соответствующим cmdlet, чтобы удалить т естовую копию и освободить ресурсы.Planned failover — контролируемое переключение для обслуживания без намеренной потери уже переданных изменений. Сначала первичную VM штатно выключают, затем Hyper-V передаёт оставшиеся изменения и запускает реплику. Failover используют при аварии, когда первичный сервер недоступен: запускается доступная точка реплики, поэтому последние неподтверждённые изменения могут отсутствовать. Test failover создаёт отдельную тестовую VM на основе реплики и не должен затрагивать рабочие сети. После planned failover или аварийного failover возврат к исходной площадке требует спланированной обратной репликации, а не одновременного запуска прежней VM.
Hyper-V failover cluster: автоматический перезапуск VM
Высокая доступность в Hyper-V failover cluster строится вокруг кластерной роли VM. Служба кластеризации контролирует узлы, сети, quorum и доступность кластерных ресурсов. Если узел становится недоступен, кластер пытается выбрать другой подходящий узел и запустить на нём VM при наличии доступа к её файлам и достаточных ресурсов.
Это не непрерывное выполнение сервиса. При отказе узла кластеру нужно обнаружить сбой, принять решение с учётом quorum, освободить или восстановить доступ к ресурсам, запустить VM, дождаться загрузки гостевой ОС и старта приложения. Фактическое RTO зависит от настроек обнаружения, размера памяти VM, скорости хранилища, состояния сети, времени загрузки ОС и самого приложения.
Кластер не устраняет все точки отказа
Failover cluster не заменяет отказоустойчивость приложения и не гарантирует восстановление при отказе общего компонента: например, единственного SAN, общего SMB-сервера, сети управления, DNS или Active Directory. Также он не создаёт запас CPU и RAM автоматически: если после отказа узла оставшиеся серверы не вмещают его VM, часть ролей не запустится.
Создание и проверка Hyper-V failover cluster
Перед созданием кластера согласуйте архитектуру хранения и N+1-ёмкость. Расчёт ресурсов, сети и хранилища для продакшена вынесен в статью «Как спроектировать виртуальную инфраструктуру для продакшена и 1С».
- 1Выберите поддерживаемую архитектуру храненияДля обычного Hyper-V-кластера VM обычно размещают на поддерживаемом общем хранилище, доступном всем узлам: например, кластерных общих томах на SAN/iSCSI/Fibre Channel/SAS или поддерживаемых SMB 3.x-файловых ресурсах. Storage Spaces Direct — другой вариант: он объединяет локальные диски узлов в распределённое хранилище и требует Windows Server Datacenter. Не переносите диски кластерных VM на локальные тома одного узла, если архитектура не предусматривает Storage Spaces Direct или иной поддерживаемый механизм доступа.
- 2Подготовьте одинаковые узлы и сетиУстановите одинаковый поддерживаемый выпуск Windows Server, обновления, роли Hyper-V и Failover Clustering. Проверьте драйверы и firmware по документации производителей. Подготовьте сеть управления, кластерную связь и доступ к хранилищу; для производственной среды их обычно разделяют логически или физически по требованиям архитектуры. У всех узлов должны быть корректные DNS-имена, синхронизация времени и права для создания объекта кластера в Active Directory, если используется доменная конфигурация.
- 3Выполните полную проверку конфигурацииЗапустите Validate Configuration для всех будущих узлов и выбранного хранилища, включая сеть, систему и storage tests. Исправьте ошибки до создания продуктивного кластера; предупреждения оцените документированно, а не игнорируйте автоматически. Отчёт валидации — доказательство, что конфигурация проверена средствами Windows, но не заменяет тест нагрузки и восстановления.
- 4Создайте кластер и настройте quorumСоздайте кластер с уникальным именем и адресом управления, затем проверьте выбранную конфигурацию quorum. Для двухузлового кластера особенно важен witness: disk witness, file share witness или cloud witness выбирают по архитектуре и доступности. Witness не должен находиться в той же отказовой зоне, которую он должен помочь пережить.
- 5Сделайте VM кластерной рольюСоздавайте новые VM сразу как высокодоступные роли либо добавляйте существующую VM после проверки, что её конфигурация и VHDX лежат на доступном кластеру хранилище. Настройте предпочтительных владельцев и порядок запуска только если это обосновано ресурсами и зависимостями. Убедитесь, что VM видна в Failover Cluster Manager как кластерная роль, а не только в локальном Hyper-V Manager одного узла.
- 6Проверьте N+1-ёмкость контролируемым переносомПереведите один узел в режим обслуживания с drain, чтобы кластер перенёс или запустил его роли на оставшихся узлах. Успех: все критичные VM остаются запущены или штатно перезапускаются на других узлах без исчерпания CPU, памяти, места и сетевой пропускной способности. Если часть VM не размещается, увеличьте запас ресурсов или пересмотрите приоритеты до ввода кластера в эксплуатацию.
- 7Проведите согласованный тест отказа и возвратаВ отдельное окно на некритичной нагрузке имитируйте недоступность одного узла по утверждённому сценарию и измерьте: время обнаружения, запуск VM на другом узле, загрузку гостевой ОС и восстановление приложения. Затем верните узел в кластер и проверьте состояние quorum, хранилища, сетей и ролей. Не используйте первый реальный отказ как проверку архитектуры.
Запускает проверку готовности двух будущих узлов к кластеру. Выполняйте из PowerShell с установленным модулем FailoverClusters и правами администратора.
Test-Cluster -Node "HV01","HV02"Вывод:
Ожидаемый результат: создаётся отчёт валидации с результатами системных, сетевых и при выбранной архитектуре хранилищных тестов. Ошибки исправьте до создания кластера; спорные предупреждения сопоставьте с официальной документацией Microsoft и документацией поставщика хранилища.Переводит узел в режим обслуживания и пытается переместить его кластерные роли на другие доступные узлы. Это безопаснее для первичной проверки N+1, чем внезапное выключение сервера.
Suspend-ClusterNode -Name "HV01" -DrainВывод:
Ожидаемый результат: роли VM переходят на другие узлы, а HV01 получает состояние Paused. Если роли не перемещаются или остаются Pending, проверьте доступную память и CPU, владельцев ролей, состояние хранилища и сети кластера.Возвращает узел из режима обслуживания в работу кластера. Автоматический обратный перенос ролей зависит от настроек кластера и не должен предполагаться без проверки.
Resume-ClusterNode -Name "HV01"Вывод:
Ожидаемый результат: HV01 имеет состояние Up. Проверьте состояние всех ролей командой Get-ClusterGroup и убедитесь, что восстановленный узел не создаёт ошибок сети или хранилища.Безопасный порядок работ и план отката
- Составьте карточку каждой VM: владелец сервиса, допустимый RTO и RPO, текущий хост, пути конфигурации и VHDX, сеть, зависимости, объём данных и способ резервного копирования.
- Выберите цель: обслуживание хоста — Live Migration; перенос файлов — Storage Migration; аварийная копия на отдельную площадку — Replica; автоматический перезапуск после отказа узла — кластер.
- Проверьте предпосылки до изменения продуктивной VM: совместимость CPU и виртуального оборудования, DNS, сеть, firewall, права, аутентификацию, свободное место и доступность целевого хранилища.
- Сделайте проверенную резервную копию и зафиксируйте способ восстановления. Контрольная точка VM не является заменой резервной копии.
- Проведите пробную операцию на некритичной VM: миграцию, test failover Replica или drain кластерного узла. Измерьте фактические паузы, RPO и время восстановления приложения.
- Выполняйте массовую операцию в согласованное окно, контролируя задачи Hyper-V, свободное место, очередь репликации, состояние кластера и прикладные проверки.
- План отката должен содержать конкретное действие: обратная Live Migration, завершение test failover, обратная репликация после planned failover или возврат узла из режима обслуживания. Не удаляйте исходные файлы и не меняйте DNS до подтверждения работы на новой стороне.
Что проверять после любой операции
Проверяйте не только статус Hyper-V. Нужны загрузка гостевой ОС, доступность сети и DNS, подключение к приложению, целостность данных на уровне приложения, мониторинг, резервное копирование и отсутствие роста очереди Hyper-V Replica. Для настройки базовой роли и виртуальных коммутаторов используйте статью «Установка и настройка Hyper-V на Windows Server: роль, VM и сеть»; для проектирования сегментации — «Сети VM в ESXi, Hyper-V и Proxmox VE: vSwitch, VLAN и bridge».
Термины в статье
- Виртуальная машина
- Изолированная вычислительная среда с виртуальными процессорами, памятью, дисками и сетевы ми адаптерами, в которой под управлением гипервизора работает гостевая ОС.
- Виртуальная сеть
- Виртуальная сеть — логическая сеть, реализованная программными средствами для связи ВМ и других виртуальных нагрузок между собой и, при необходимости, с физической сетью.
- Виртуальное оборудование
- Виртуальное оборудование — логическая аппаратная платформа, которую гипервизор предоставляет ВМ: виртуальные процессоры, память, устройства и системную прошивку.
- Виртуальный коммутатор Hyper-V
- Виртуальный коммутатор Hyper-V — программный коммутатор, обеспечивающий в зависимости от типа связь между ВМ, хостом и физической сетью.
- Высокая доступность
- Высокая доступность (HA) — способность системы сохранять сервис или автоматически восстанавливать его с минимальным простоем при отказе компонентов.
- Режим обслуживания
- Режим обслуживания — состояние хоста виртуализации, в котором на нём не запускают новые ВМ, а работающие ВМ предварительно эвакуируют, выключают или переводят в допустимое состояние.
- Роль Hyper-V
- Роль Hyper-V — серверная роль Windows Server, устанавливающая гипервизор и компоненты для создания, запуска и управления виртуальными машинами на узле.
- Холодная миграция
- Холодная миграция — перенос выключенной виртуальной машины между хостами, хранилищами или платформами с переносом её файлов, но без состояния выполнения.
- Хост виртуализации
- Хост виртуализации — физический сервер или вычислительная система, на которой работает гипервизор и размещаются виртуальные машины; его CPU, память, сеть и хранилище распределяются между гостями.
- Checkpoint
- Контрольная точка Hyper-V — сохранённое состояние конфигурации и виртуальных дисков ВМ для отката; стандартная точка также сохраняет память работающей ВМ.
- Guest OS
- Операционная система, установленная в виртуальной машине и работающая под управлением гипервизора; не следует путать с хостовой ОС гипервизора типа 2.
- Hyper-V
- Платформа виртуализации Microsoft с гипервизором типа 1, доступная как роль Windows Server и компонент Windows 10/11 Pro, Enterprise и Education.
- Hyper-V Manager
- Hyper-V Manager — графическая консоль управления Hyper-V, предназначенная для настройки хостов, виртуальных машин, виртуальных коммутаторов и операций с их состоянием.
- Hyper-V Replica
- Встроенный механизм Hyper-V для асинхронного поддержания копии виртуальной машины на другом хосте или кластере с целью аварийного восстановления.
- Live Migration
- Перенос работающей виртуальной машины между хостами без выключения гостевой ОС; переключение обычно вызывает краткую паузу, а сохранение соедине ний зависит от сети и платформы.
- SAS
- SAS — последовательный интерфейс и набор протоколов SCSI для подключения накопителей, поддерживающий адресацию устройств, экспандеры и обычно двухпортовое подключение дисков.
- SR-IOV
- Спецификация PCI-SIG для PCIe, позволяющая физическому устройству создавать виртуальные функции (VF), назначаемые виртуальным машинам для близкого к прямому доступа.
- Storage Migration
- Storage Migration — механизм Hyper-V для переноса файлов работающей виртуальной машины между хранилищами без смены хоста, на котором она выполняется.
- Uplink
- Uplink — соединение или интерфейс, ведущий от устройства либо локального сегмента к вышестоящей сети; в виртуализации — подключение виртуального коммутатора к физической сети.
- V2V
- V2V — перенос существующей виртуальной машины с одной платформы виртуализации на другую с преобразованием дисков и конфигурации под целевой гипервизор.
- vCPU
- vCPU — виртуальный логический процессор, предоставляемый виртуальной машине; гипервизор планирует его выполнение на процессорных ресурсах хоста.
- VHDX
- VHDX — формат виртуального диска Microsoft, рассчитанный на Hyper-V и поддерживающий диски до 64 ТБ, журналирование метаданных и современные размеры секторов.