Глава 12. Управление Hyper-V

Hyper-V это гипервизор Виртуальных машин (ВМ, VM) Microsoft. И Windows Server 2022, и Windows 10 содержат Hyper-V как вариант вашей установки, причём во всех версиях Windows Server 2022, а также в редакциях Enterprise, Professional и Education Windows 10.

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

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

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

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

Эта глава начинается с установки функциональности Hyper-V. После установки Hyper-V, вы переходите к созданию некой ВМ, PSDirect, что требует от вас выгрузки образа ISO Windows Server из Интернета.

После того как вы создадите такую ВМ PSDirect, Вы можете воспользоваться PowerShell Direct для применения некого удалённого сеанса к такой ВМ без применения сетевого подключения. Вы также можете настраивать возможности оборудования и сетевых ресурсов этой ВМ. Затем вы пользуетесь командлетами PowerShell для управления значением состоянием этой ВМ.

Hyper-V позволяет вам перемещать ВМ и/ или хранилище ВМ между хостами Hyper-V. Для восстановления в аварийных ситуациях вы можете реплицировать некую запущенную ВМ (и применяете такую реплику в случае отказа первичной ВМ).

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

Установка Hyper-V в Windows Server 2022 достаточно простая, что и показано в этом рецепте. После того как вы установили его, вы можете настраивать этот компонент.

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

На Шаге 1 вы устанавливаете функциональность Hyper-V и в HV1, и в HV2. Вывод этого шага выглядит так:

Для завершения необходимой установки в Hyper-V, на Шаге 2, вы перезапускаете и HV1, и HV2. Этот шаг не создаёт никакого вывода, но перезапускает оба хоста.

После перезапуска HV1 и HV2 вы заходите обратно в эти хосты при помощи Reskit/Administrator. На Шаге 3 вы создаёте два новых удалённых сеанса PowerShell к HV1 и HV2. На Шаге 4 вы пользуетесь удалёнными сеансами и создаёте новые папки в HV1 и HV2 для содержания ВМ Hyper-V и виртуальные диски Hyper-V. На Шаге 5 вы настраиваете Hyper-V в обоих хоста чтобы применять эти новые местоположения для хранения ВМ и виртуальных устройств, а на Шаге 6 вы определяете что этот хост должен поддерживать пятна NUMA. Затем, на Шаге 7 вы настраиваете расширенный режим сеанса для улучшения подключений ВМ. Наконец, на Шаге 8, вы устанавливаете два хоста Hyper-V чтобы воспользоваться измерениями ресурсов. Эти шесть шагов не производят никакого консольного вывода.

На Шаге 9 вы просматриваете ключевые настройки хоста Hyper-V со следующим выводом:

На Шаге 1 вы устанавливаете функциональную возможность Hyper-V в двух серверах. Вы можете выполнить успешно это только когда применяемый вами хост поддерживает необходимые возможности виртуализации и вы включили их в BIOS своей системы. Чтобы гарантировать что ваша система способна поддерживать Hyper-V, ознакомьтесь с этой ссылкой: https://mikefrobbins.com/2012/09/06/use-powershell-to-check-for-processor-cpu-second-level-address-translation-slat-support/. Кроме того, убедитесь что вы дважды проверили что вы включили виртуализацию в BIOS хоста ВМ прежде чем вы выполните этот шаг.

На Шаге 2 вы перезапускаете оба эти сервера. Для автоматического перезапуска серверов вам надлежит позволить Install-WindowsFeature (применявшемся на Шаге 1) такой перезапуск при помощи переключателя -Restart. С точки зрения автоматизации, это могло бы означать, что ваша система начинает перезапускаться до завершения вашего удалённого сценария, что может вызвать ошибку в Invoke-Command. Данный рецепт избегает этого не перезапускаясь после установки компонентов Hyper-V. Затем вы перезапускаете свой хост управляемым образом на следующем шаге. По завершению перезапуска ваш сценарий может позаботиться об управлении обоими серверами.

На Шагах с 4 по Шаг 8 вы настраиваете по одной из сторон своих хостов ВМ на каждом шаге. Вы можете собрать эти шаги и просто вызвать Set-VMHost один раз со всеми необходимыми предписываемыми свойствами сервера Hyper-V.

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

Таблица 12-1. Функциональные возможности Hyper-V

Функциональность	Ссылки для дополнительных сведений
Подключение к ВМ, включая режим расширенного сеанса	https://docs.microsoft.com/en-gb/windows-server/virtualization/hyper-v/learn-more/use-local-resources-on-hyper-v-virtual-machine-with-vmconnect
Основы параметров жёсткого диска	https://www.altaro.com/hyper-v/understanding-working-vhdx-files/
Hyper-V и NUMA	https://blogs.technet.microsoft.com/pracheta/2014/01/22/numa-understand-it-its-usefulness-with-windows-server-2012/
Настройка измерений ресурсов Hyper-V	https://redmondmag.com/articles/2013/08/15/hyper-v-resource-metering.aspx

Создание ВМ Hyper-V относительно не сложное и состоит из нескольких простых шагов. Во- первых, вам требуется создать внутри Hyper-V саму необходимую ВМ. Затем вы создаёте соответствующий виртуальный жёсткий диск ВМ и добавляете его в эту ВМ. Вы можете также пожелать отрегулировать число процессоров и память для этой ВМ и настроить содержимое устройство DVD ВМ. Когда вы создали свою ВМ, вам потребуется установить операционную систему (ОС) ВМ. У вас имеется множество вариантов относительно того как вы развёртываете в ВМ Hyper-V Windows (или Linux).

Бесплатный продукт от Microsoft, Windows Assessment and Deployment Kit, содержит различные инструменты для содействия автоматизации в развёртывании Windows. Они включают в себя Deployment Image Servicing and Management (DISM, Обслуживание и управление образом развёртывания), Windows Imaging and Confguration Designer (Windows ICD, Конструктор образов и конфигураций Windows), Windows System Image Manager (Windows SIM, Диспетчер системных образов Windows), User State Migration Tool (USMT, Инструмент миграции состояния пользователя) и множество прочих. Для получения дополнительных сведений по этим инструментам развёртывания Windows, обращайтесь к https://docs.microsoft.com/windows/deployment/windows-deployment-scenarios-and-tools.

Другой способ установки ОС в ВМ состоит в создании соответствующей ВМ (либо при помощи PowerShell, либо применяя Диспетчер Hyper-V) и подключать необходимый образ ISO ОС к соответствующему устройству DVD ВМ. После запуска этой ВМ вы выполняете установку вручную и когда вы завершаете установку этой ОС, вы можете применять рецепты из этой книги для настройки своего сервера под ваши потребности.

В данном рецепте вы создаёте ВМ PSDirect. Изначально она обладает назначаемым Windows именем хоста, которое вы позднее изменяете на Wolf. При построении этой ВМ вы назначаете для устройства DVD ВМ DVD Windows Server 2022. Этот шаг гарантирует что когда вы запускаете эту ВМ, Windows приступает к соответствующему процессу установки графического интерфейса. Получаемым результатом должна оказаться полностью установленная ОС внутри этой ВМ. Основные подробности выполнения реальной установки выходят за рамки данного рецепта.

Двумя незначительными проблемами при использовании соответствующего графического интерфейса для установки Windows Server 2022 заключаются в том, что такая настройка Windows случайным образом вырабатывает название машины и такая ВМ настраивается как компьютер рабочей группы и она не подключается к вашему домену. Те сценарии, которые применяются для выработки нашей фермы ВМ в этой книге являются примерами развёртывания Windows Server 2022 более автоматизированным образом при помощи файла SETUP.XML, который определяет подробности установки. Тот сценарий, который создаёт эти применяемые ВМ доступен через Интернет в GitHub. За этими сценариями и документации по ним обращайтесь к https://github.com/doctordns/ReskitBuildScripts.

Вы запускаете данный рецепт в соответствующей ВМ хоста HV1, который вы создавали в рецепте Установка Hyper-V внутри Windows Server. Вам также потребуется образ ISO Windows Server. Для целей проверки это может быть версия для оценки или полная розничная версия - а для этой главы вы можете воспользоваться образом Windows Server 2022 или Windows Server 2019. Для получения оценочной версии Windows Server посетите Microsoft Evaluation Center в https://www.microsoft.com/evalcenter/evaluate-windows-server.

Также вы можете выгружать некий ISO самой последней копии предпросмотра Windows Server и применять ISO при установке соответствующей ВМ. Для выгрузки сборок предпросмотра обращайтесь к https://www.microsoft.com/en-us/software-download/windowsinsiderpreviewserver, а также к https://techcommunity.microsoft.com/t5/windows-server-insiders/bd-p/WindowsServerInsiders для дополнительных сведений относительно сборок Windows Insiders. Для этого вам придётся стать участником в программе Windows Insiders, подробности в https://docs.microsoft.com/windows-insider/get-started.

На Шаге 1 вы определяете ВМ и местоположения жёстких дисков ВМ и назначаете их переменным. Вы также проверяете что обеспечили то, что необходимый ISO Windows Server расположен там где надо. Допустим что такой ISO имеется и вы обладаете правильным его названием, тогда этот шаг не производит никакого вывода. Если этот шаг отказывает в поиске такого файла, он будет прерван.

На Шаге 2 вы создаёте новую ВМ при помощи командлета New-VM с выводом, который выглядит как- то так:

На Шаге 3 вы создаёте файл виртуального диска для своей ВМ и вы добавляете этот VHDX в нашу ВМ PSDirect на Шаге 4. На Шаге 5 вы добавляете необходимый образ ISO в свою ВМ PSDirect и затем, на Шаге 6 вы запускаете эту ВМ. Эти четыре шага не создают никакого вывода.

На заключительном Шаге 7 этого рецепта вы пользуетесь Get-VM для просмотра подробностей созданной ВМ, что выдаёт такой вывод:

На Шаге 1 вы определяете соответствующее название образа ISO для Windows Server. В зависимости от того какой образ вы применяете, значение имени файла применяемого ISO может отличаться. Либо отрегулируйте значение имени файла чтобы оно соответствовало этому этапу, или измените его чтобы оно соответствовало названию файла применяемого ISO. Для выпущенных версий Windows Server вы можете найти образы ISO для оценочных версий в Microsoft Evaluation Center.Если вы обитаете на быстрой линии, рассмотрите вариант сборки предпросмотра Windows Insiders.

На Шаге 2 вы создаёте ВМ. Хотя этот шаг и должен быть успешным, вы не сможете пока запустить эту ВМ, поскольку вам требуется определить по крайней мере один виртуальный жёсткий диск для применения с этой ВМ. Вы позаботитесь об этих шагах настройки на последующих шагах.

После того как вы запустили эту ВМ, на Шаге 6, соответствующая ВМ запускает и завершает установку Windows Server. Для завершения соответствующей установки Windows Server вам требуется воспользоваться ей графическим интерфейсом. Для целей данной главы примените все установки по умолчанию и проверьте что вы настроили пароль на Pa$$w0rd. Как и со всеми применяемыми в этой книге паролями, не стесняйте себя в применении тех паролей, которые нравятся вам больше - просто убедитесь что вы не забудете их впоследствии.

PowerShell Direct это функциональная возможность Hyper-V, которая позволяет открывать удалённые сеансы PowerShell в некой ВМ без применения сетевого подключения. Эта функциональность делает возможным для вас создание удалённых сеансов внутри определённой ВМ для исправления проблем, таких как неверные сетевые настройки. Администратор может вводить в действие новый хост и почти правильно настроить IP адрес своего хоста, что подразумевает ситуацию подключения Catch-22. При не работающем сетевом подключении к такой ВМ вы не можете исправить данную проблему - однако пока вы не справитесь с этой проблемой, вы не можете выполнить подключение к такой ВМ. При помощи PS Direct вы имеете возможность создать удалённый сеанс в такой ВМ, как вы узнаете из данного рецепта.

Данный рецепт применяет HV1, хост Datacenter Windows Server, в котором вы обладаете установленной функциональностью Hyper-V. Вы также должны обладать созданной ВМ Windows Server с названием PSDirect. Вы должны обеспечить ВМ PSDirect в рабочем состоянии. Данный рецепт демонстрирует PowerShell Direct, поэтому не имеет значения какую именно версию Windows Server вы установили, пока это Windows Server 2016 или последующая версии (и вы выполнили установку такой ОС внутри своей ВМ PSDirect).

 

{Прим. пер.: В Windows Server 2016 Существует ошибка Powershell Direct (по крайней мере для версий PowerShell Core 6x, 7x), а именно: Invoke-Command -VMName «VMName» завершается сбоем с невозможностью преобразовать объект типа "System.String" в тип "VMState" (Invoke-Command: Unable to cast object of type 'System.String' to type 'VMState'). Подробнее: GiHub issues14738 Alexey Yeltsov, Jordan Borean and Patrick Meinecke. Наличие указанной ошибки проявляется следующим образом: (@(Get-VM -VMName «VMName»)[0]).State.GetType().FullName. Patrick Meinecke предположил, что "версия 2016 года применяет неявное удалённое взаимодействие (либо автоматический вызов уровня wincompat) по причине того, что модуль Hyper-V не получает тег Core через обновления Windows. В качестве обходного пути он рекомендует Import-Module HyperV -SkipEditionCheck перед запуском выдающей ошибку команды. Это работает:}

PS C:\Users\User> Import-Module Hyper-V -SkipEditionCheck
PS C:\Users\User> (@(Get-VM -VMName «VMName»)[0]).State.GetType().FullName
Microsoft.HyperV.PowerShell.VMState
		

Первую часть данного рецепта вы выполняете в HV1. Затем вы выполняете окончательные шаги данного рецепта в DC1, которые показывают как подключаться к некой ВМ удалённо с имеющегося хоста Hyper-V.

На Шаге 1 вы создаёте объект полномочий PowerShell. Вы пользуетесь этим объектом позднее в данном рецепте для разрешения подключения к своей ВМ PSDirect. Этот шаг не производит вывод.

На Шаге 2 вы пользуетесь командлетом Get-VM для просмотра своей ВМ PSDirect с примерно следующим выводом:

На Шаге 3 для исполнения команды вывода имени хоста в своей ВМ PSDirect вы применяете Invoke-Command и получаете такой вывод:

На Шаге 4 вы активируете внутри своей ВМ PSDirect команду, но на этот раз при помощи GUID необходимой ВМ с подобным приводимому ниже выводом:

На Шаге 5 для входа в интерактивный сеанс со своей ВМ PSDirect вы пользуетесь командой Enter-PSSession. Внутри этого удалённого сеанса вы запускаете Get-CimInstance для возврата подробностей вычислительной системы в этой ВМ. Получаемый вывод должен выглядеть как- то так:

Теперь, когда вы создали в HV1 некую работающую ВМ, вы исполняете все остающиеся шаги настройки этой ВМ удалённо в DC1. На Шаге 6 вы создаёте объект полномочий PowerShell, которым вы пользуетесь для подключения к ВМ PSDirect изнутри HV1.

На Шаге 7 вы создаёте удалённый сеанс с HV1. Этот шаг также не производит вывод. На Шаге 8 вы входите в удалённый сеанс для HV1. Получаемый на этом шаге вывод выглядит как показано далее:

На Шаге 9 вы создаёте полномочия для PSDirect внутри своей ВМ HV1, что не производит вывод.

На Шаге 10 вы входите в интерактивный сеанс с PSDirect из уже установленного сеанса в HV1. Изнутри этого сеанса вы исполняете команду HOSTNAME.EXE, которая производит приводимый ниже вывод:

На заключительном шаге данного рецепта, Шаге 11, вы покидаете свои удалённые сеансы в ВМ PSDirect и ВМ HV1. Вот вывод с этого шага:

На Шаге 3 вы пользуетесь PowerShell Direct для входа в удалённый сеанс ВМ и выполняете некую команду. В предположении что вы установили Windows в своей ВМ PSDirect при помощи поддерживаемой версии Windows, этот процесс установки вырабатывает некое случайное название машины, в данном случае WIN-0TKMU3D2DFM. Значение названия машины для вашей ВМ может быть совершенно иным.

На Шаге 4 Вы пользуетесь функциональностью PowerShell Direct для исполнения команды внутри своей ВМ PSDirect. Как вы видели из вывода на Рисунке 12-07, состоянием NIC для этой ВМ является отключена (disconnected). Этот шаг показывает вам как вы можете воспользоваться PowerShell Direct для входа в некую ВМ, а затем просмотреть и восстановить сетевое подключение.

Группы ВМ Hyper-V позволяют вам группировать ВМ для автоматизации. Существует два типа групп ВМ, которые вы можете создавать, VMCollectionType и ManagementCollectionType:

При помощи групп ВМ вы можете обладать двумя типами групп ВМ VMCollectionType, SQLAccVMG (которая содержит ВМ {абонентов} SQLAcct1, SQLAcct2 и SQLAcct3), а также SQLMfgVMG, которая включает в себя ВМ {разработчиков} SQLMfg1 и SQLMfg2. Затем вы можете создать группу ВМ ManagementCollectionType, VM-All, содержащую указанные две группы VMCollectionType.

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

Вы исполняете этот рецепт в HV2, сервере Windows Server 2022 с добавленной функциональностью Hyper-V. Вы настроили этот хост в нашем рецепте Установка Hyper-V внутри Windows Server.

На Шаге 1 при помощи командлета New-VM вы создаёте несколько ВМ с выводом на этом шаге, выглядящим следующим образом:

На Шаге 2 вы применяете командлет Get-VM чтобы взглянуть на свои шесть только что созданных ВМ с подобным приводимому ниже выводом:

На Шаге 3 вы создаёте несколько типов групп ВМ коллекций ВМ Hyper-V, что не производит вывод. На Шаге 4 вы изучаете имеющиеся в HV2 группы ВМ с отображаемым далее выводом:

Для упрощения создания групп наборов ВМ, на Шаге 5, вы создаёте массивы названий соответствущих ВМ. На Шаге 6 вы добавляете ВМ в группу ВМ SQLAccVMG, в то время как на Шаге 7 вы добавляете виртуальные машины в группу ВМ SQLMfgVMG. Все три шага не производят вывод.

На Шаге 8 вы снова просматриваете имеющиеся группы ВМ с подобным приводимому ниже выводом:

На Шаге 9 вы создаёте группу набора управления ВМ, а на Шаге 10 вы заполняете эту коллекцию управления ВМ. Для упрощения получаемого вывода, на Шаге 11 вы устанавливаете значение $FormatEnumerationLimit равным 99. Эти три шага не вырабатывают вывод.

На Шаге 12 вы просматриваете все свои полностью заполненные группы ВМ, отсортированные по типу групп ВМ с подобным приводимому ниже выводом:

На Шаге 13 вы пользуетесь имеющимися созданными вами группами ВМ, а именно, всеми ВМ SQL. На Шаге 14 вы устанавливаете все ВМ в группе коллекции управления ВМ VMMGSQL на наличие четырёх виртуальных процессоров, а на Шаге 15 вы устанавливаете для ВМ из группы набора ВМ SQLAccVMG наличие шести виртуальных процессоров. Эти три шага не продуцируют никакого консольного вывода.

На Шаге 16 вы повторно просматриваете значения виртуальных процессоров, назначенных каждой ВМ SQL, подобно следующему:

На Шаге 17 вы удаляете из групп наборов ВМ все имеющиеся ВМ, а на Шаге 18 вы удаляете всех участников из групп управления ВМ. Наконец, на Шаге 19, вы удаляете все имеющиеся группы ВМ. Эти три шага не производят вывод на консоль.

На Шаге 11 вы устанавливаете значение для переменной автоматизации $FormatEnumerationLimit.Эта переменная управляет тем, сколько повторяющихся групп отображается командлетами Format-*. По умолчанию, PowerShell инициализирует эту переменную со значением 4. Применяя эту установку по умолчанию, на Шаге 11 вы бы увидели только 4 участников в каждой группе ВМ с отображением PowerShell "..." для указания на то, что у вас имеется более 4 участников. Для данного шага PowerShell способен отображать до 99 ВМ участников в каждой из групп ВМ.

Настройка оборудования в вашей ВМ во многом аналогична настройке физического компьютера, просто без необходимости для вас пользоваться отвёрткой. В физическом компьютере вы способны регулировать настройки ЦПУ и BIOS и регулировать физическую оперативную память, сетевые интерфейсы, интерфейсы диска, дисковые устройства, устройства DVD (с/ без загруженного DVD) и много иного. Вы можете обнаружить все эти компоненты и внутри ВМ Hyper-V. Как вы можете наблюдать в этом рецепте, командлеты PowerShell упрощают настройку конкретного виртуального оборудования для всех ВМ Hyper-V.

В данном рецепте вы регулируете BIOS своей ВМ, количество ЦПУ и память, а затем добавите некий контроллер SCSI. Получив на своём месте этот контроллер, вы создадите новый виртуальный диск и назначите его созданному контроллеру SCSI. Затем вы просмотрите полученные результаты.

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

Данный рецепт не охватывает виртуальную NIC соответствующей ВМ. По умолчанию, ВМ (такие как те, которые мы создали в своём рецепте Создание ВМ Hyper-V) содержит единственную виртуальную NIC. Вы можете добавить дополнительные NIC во все ВМ, в которые пожелаете. Вы настраиваете сетевую среду ВМ в рецепте Настройка сетевой среды Hyper-V позднее в этой главе.

Этот рецепт пользуется HV1, хостом Windows Server Datacenter, в котором вы установили функциональность Hyper-V. Вы также обладаете созданной ВМ с Windows Server и носящей название PSDirect.

На Шаге 1 вы выключаете свою ВМ PSDirect и проверяете значение состояния этой ВМ со следующим выводом:

На Шаге 2 вы настраиваете порядок запуска для своей ВМ и затем просматриваете настройку виртуального BIOS этой ВМ. Вот вывод с этого шага:

На Шаге 3 вы выполняете регулировку значения числа виртуальных процессоров для своей ВМ PSDirect с подобным следующему выводом:

На Шаге 4 вы настраиваете виртуальную память PSDirect и затем просматриваете имеющиеся установки памяти с приводимым ниже выводом:

На Шаге 5 вы добавляете в свою ВМ PSDirect контроллер SCSI. Когда вы затем просматриваете имеющиеся внутри этой ВМ PSDirect контроллеры SCSI, вы должны должны наблюдать вывод, подобный приводимому ниже:

Теперь, когда вы отрегулировали необходимое виртуальное оборудование для своей ВМ PSDirect, на Шаге 6 вы повторно запускаете эту ВМ и дожидаетесь пока эта ВМ не появится. Этот шаг не производит вывод.

На Шаге 7 вы создаёте новый файл виртуального диска для своей ВМ PSDirect с подобным следующему выводом:

На Шаге 8 вы получаете имеющиеся контроллеры в своей ВМ PSDirect и того контроллера, который вы добавили на Шаге 5. Далее, на Шаге 9 вы добавляете вновь созданное устройство виртуального диска к своему вновь созданному контроллеру SCSI. Эти два шага не производят вывод.

На Шаге 10 вы получаете все дисковые устройства, подключённые к контроллерам SCSI в вашей ВМ PSDirect с подобным приводимому ниже выводом:

При помощи Hyper-V вы обладаете возможностью обновления некоторых настроек конфигурации оборудования ВМ только когда вы выключили эту ВМ. На Шаге 1 вы отключаете свою ВМ чтобы позволить себе настроить установки виртуального BIOS. После того как вы осуществили эти изменения BIOS (и, возможно, прочие) вы можете перезапустить свою ВМ.

На Шаге 2 вы устанавливаете порядок запуска этой ВМ и просматриваете полученные настройки. В промышленном решении вы можете иметь подобные этому сценарии, которые настраивают установки ВМ в предпочтительные корпоративные стандарты, причём вне зависимости от установленных по умолчанию настроек.

Некоторые настройки, такие как дисковые контроллеры SCSI и дисковые устройства могут добавляться и удаляться в запущенной ВМ. На Шаге 9 вы добавляете внвь созданное устройство виртуального диска для его работы с ВМ PSDirect.

В рецепте Создание ВМ Hyper-V вы создали некую ВМ, PSDirect. Эта ВМ, по умолчанию обладает единственной сетевой картой, которую Hyper-V настраивает для достижения подробностей IP адреса от DHCP. В этом рецепте вы назначаете конкретную NIC коммутатору и настраиваете подробности IP адреса для этого виртуального сетевого адаптера.

Вы исполняете этот рецепт в HV1, который применяет ВМ PSDirect, создали в рецепте Создание ВМ Hyper-V Этот рецепт также применяет запущенный в DC1 сервер DHCP. В Главе 7, Управление сетевыми средами в вашей корпорации вы установили поднятой службу DHCP в рецепте Установка DHCP. Затем вы настроили свой сервер DHCP в рецепте Настройка областей действия и параметров DHCP.

Эта глава пользуется ВМ PSDirect, которую вы создали ранее. Когда вы строите эту машину при помощи обычной процедуры установки, Windows назначает случайное название машины, что вы наблюдали в предыдущем рецепте ( Применение PowerShell Direct). В этом рецепте мы также изменяем значение имени своего хоста внутри на Wolf.

В этом рецепте вы устанавливаете сетевую карту ВМ PSDirect чтобы разрешить имитацию MAC адреса. Этот шаг позволяет данной ВМ просматривать имеющуюся сетевую среду и получать некий IP адрес от сервера DHCP в DC1. Если вы запускаете в качестве ВМ HV1, вы также должны разрешить имитацию (spoofing) MAC в соответствующих NIC в этой ВМ в соответствующем хосте ВМ HV1. Вы таке должны разрешить имитацию MAC в HV2.

На Шаге 1 вы настраиваете NIC своей ВМ PSDirect на разрешение имитации (snoofing) MAC адреса. На этом шаге нет вывода.

На Шаге 2 вы получаете сведения об имеющейся NIC, назначенной нашей ВМ PSDirect с подобным приводимому ниже выводом.

На Шаге 3 вы создаёте объект полномочий для своей ВМ PSDirect. Затем вы применяете эти полномочия для исполнения Get-NetIPConfiguration получения сведений изнутри этой ВМ с подобным следующему выводом:

На Шаге 4 вы создаёте новый коммутатор ВМ Hyper-V внутри своего хоста ВМ HV1, что производит такой вывод:

На Шаге 5 вы подключаете свою NIC из ВМ PSDirect к созданному коммутатору ВМ, что не создаёт вывод. На Шаге 6 вы можете повторно просмотреть сетевые сведения для ВМ PSDirect с подобным приводимому далее выводом:

На Шаге 7 вы выполняете блок сценария внутри своей ВМ PSDirect для возврата подробностей сетевого подключения этой ВМ, что производит вывод, подобный приводимому ниже:

На Шаге 8 вы просматриваете имеющееся название хоста своей ВМ PSDirect с выводом, выглядящим следующим образом:

На Шаге 9 вы пользуетесь командлетом Rename-Computer, запускаемом внутри своей ВМ PSDirect. Этот шаг изменяет значение имени хоста нашей ВМ на Wolf и производит такой вывод:

На Шаге 10 вы перезапускаете свою ВМ , что не производит консольного вывода. После повторного запуска этой ВМ, на Шаге 11 вы исполняете команду HOSTNAME внутри этой ВМ с подобным приводимому ниже выводом:

На Шаге 1 настраиваете NIC своей ВМ PSDirect для разрешения имитации MAC адреса. Об имитации (snoofing) MAC адреса в Hyper-V вы можете прочитать в https://charbelnemnom.com/how-to-set-dynamic-mac-address-on-a-hyper-v-vm-with-powershell/.

На Шаге 5 вы подключаете NIC своей ВМ PSDirect к созданному внутри HV1 виртуальному коммутатору. Так как NIC вашей ВМ PSDirect (по умолчанию) настроен на получение IP адреса через DHCP, как только вы подключаете эту виртуальную NIC к созданному коммутатору, ваша ВМ должна получить необходимую конфигурацию от своего хоста DC1, который исполняет DHCP. На Шаге 6 вы просматриваете подробности полученной от DHCP конфигурации IP.

Встроенная виртуализация это функциональная возможность, которая позволяет ВМ Hyper-V выступать хостом виртуальных машин, в которых также имеется включённой виртуализация. Например, вы можете взять некий хост Hyper-V (допустим, HV1) и в этом хосте запустить некую ВМ (предположим, PSDirect). При помощи встроенной виртуализации вы можете разрешить своей ВМ PSDirect выступать хостом для виртуальных машин. Затем вы можете создать некую строенную ВМ внутри PSDirect с названием NestedVM.

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

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

Включение встроенной виртуализации выполняется очень просто. Прежде всего вы должны обновить имеющиеся виртуальные ЦПУ внутри своей ВМ, для которой вы хотите поддерживать вложение. Более того, в этом рецепте вы регулируете имеющиеся виртуальные ЦПУ в своей ВМ PSDirect для выставления необходимых расширений виртуализации. Изменение имеющегося BIOS для осуществления этого должно быть выполнено после того как вы отключите свою ВМ. После того как вы перезапустите эту ВМ, вы устанавливаете необходимую функциональность Hyper-V и создаёте встроенную ВМ NestedVM. Этот рецепт не показывает подробности настройки созданной ВМ NestedVM. Эти детали являются упражнением для читателя.

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

На Шаге 1 вы обеспечиваете останов ВМ PSDirect, что не производит консольного вывода. Шаге 2 вы регулируете имеющиеся виртуальные процессоры ВМ для поддержки виртуализации. Затем вы повторно просматриваете настройки имеющихся процессоров, что выглядит как- то так:

На Шаге 3 вы запускаете ВМ PSDirect и затем просматриваете её при помощи Get-VM, что отображается следующим образом:

На Шаге 4 вы создаёте объект полномочий PowerShell для своей ВМ PSDirect. На Шаге 5 вы создаёте блок кода, который устанавливает функциональность Hyper-V. Затем, на Шаге 6 вы создаёте удалённый сеанс PowerShell с этой ВМ PSDirect. Эти три шага не создают вывод на консоль.

На Шаге 7 вы пользуетесь созданным удалённым сеансом для установки функциональности Hyper-V внутри своей ВМ PSDirect, что вырабатывает такой вывод:

Как вы можете определить из полученного вывода, после установки функциональности Hyper-V внутри PSDirect, вам требуется перезапустить эту ВМ для завершения процесса установки. На Шаге 8 вы перезапускаете PSDirect, дожидаетесь её запуска и просматриваете сведения об этой ВМ с подобным приводимому ниже выводом:

На заключительном шаге этого рецепта, Шаге 9, вы создаёте встроенную ВМ, NestedVM, внутри своей ВМ PSDirect, что продуцирует такой вывод консоли:

На Шаге 7 вы устанавливаете функциональные возможности Hyper-V для своей встроенной ВМ (NestedVM) внутри виртуальной машины PSDirect. Установка Hyper-V внутри ВМ PSDirect успешна, как вы это можете наблюдать на данном шаге из Рисунка 12-35. Когда ВМ PSDirect не поддерживает виртуализацию, командлет Install-WindowsFeature возбудит некую ошибку. К тому же, раз вы не установите в PSDirect Hyper-V, Шаг 9 откажет без создания соответствующей ВМ. По своему выбору вы можете отрегулировать показанные шаги из нашего рецепта Создание ВМ Hyper-V для установки и настройки некой ОС в этой NestedVM.

Hyper-V снабжает вас возможностью запускать, останавливать и ставить на паузу ВМ Hyper-V. Также вы можете сохранять и восстанавливать ВМ. Вы применяете командлеты Hyper-V для управления своими виртуальными машинами либо локально (то есть в хосте Hyper-V или через RDP, или через удалённый сеанс PowerShell), либо при помощи инструментов RSAT для управления текущим состоянием виртуальных машин в удалённых хостах Hyper-V.

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

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

Вы исполняете этот рецепт в своём хосте HV1 после того как вы создали соответствующую ВМ PSDirect. Вы создали эту ВМ в нашем рецепте Создание ВМ Hyper-V.

На Шаге 1 вы останавливаете свою ВМ PSDirect и проверяете её состояние. Вывод выглядит следующим образом:

На Шаге 2 для запуска своей ВМ PSDirect вы пользуетесь Start-VM и далее применяете Wait-VM для ожидания запуска этой ВМ и получения адреса IP. Вот как выглядит вывод с этого шага:

На Шаге 3 для приостановки ВМ PSDirect вы используете Suspend-VM и рассматриваете её состояние со следующим выводом:

Обладая поставленной на паузу ВМ PSDirect, на Шаге 4 для снятия этой ВМ с паузы вы применяете командлет Resume-VM со следующим выводом:

На Шаге 5 вы сохраняете свою ВМ PSDirect, что приводит к такому выводу:

Вы можете возобновить сохранённую ВМ воспользовавшись командой Start-VM, что вы наблюдаете на Шаге 6, который приводит к такому выводу:

На Шаге 7 демонстрирует применение командлета Restart-VM для перезапуска вашей ВМ PSDirect. Вывод с этого шага приводится ниже:

На нашем предыдущем шаге вы перезапускали свою ВМ, что заняло определённое время, в зависимости от вашего хоста ВМ и размера ВМ. На Шаге 8 вы дожидаетесь перезапуска этой ВМ и затем применяете Get-VM чтобы рассмотреть состояние своей ВМ PSDirect подобно следующему:

На заключительном шаге этого рецепта, Шаге 9, вы выполняете аппаратное отключение своей ВМ PSDirect с подобным приводимому ниже выводом:

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

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

Hyper-V позволяет вам передвигать ВМ в новый хост ВМ и перемещать хранилище ВМ в некое новое местоположение. Перемещение ВМ и передвижение хранилища ВМ это две важные функциональные возможности, которые вы можете применять для управления своими хостами.

При миграции в реальном времени вы обладаете способностью перемещать ВМ Hyper-V в другие хосты ВМ без какого бы то ни было времени простоя. Миграция хранилища лучше работает когда ваша ВМ удерживается в неком совместно применяемом хранилище (через SAN с оптоволоконным каналом, iSCSI, SMB). Вы также обладаете способностью перемещать хранилище ВМ (любые связанные с вашими ВМ VHD/ VHDX) в другое местоположение. Вы можете сочетать это и перемещать поддерживаемые локальным хранилищем ВМ в прочие хосты Hyper-V, перемещая как саму ВМ, так и лежащее в её основе хранилище.

В данном рецепте вы вначале перемещаете имеющееся для ВМ PSDirect хранилище. Вы создали эту ВМ в нашем рецепте Создание ВМ Hyper-V и сохранили конфигурацию этой ВМ и соответствующий VHD ВМ в устройстве H:. Для перемещения этого хранилища вы создаёте новый совместный ресурс SMB и затем перемещаете хранилище этой ВМ в новый совместный ресурс SMB.

Во второй части этого рецепта вы осуществляете миграцию ВМ PSDirect в реальном масштабе времени с HV1 на HV2. Такое перемещение ВМ носит название перемещения в реальном масштабе времени поскольку вы выполняете миграцию работающей ВМ, которая продолжает оставаться поднятой и работающей на протяжении миграции.

В этом рецепте вы пользуетесь системами с HV1 и HV2 (Windows 2022 с загруженным Hyper-V) в том виде как они были установлены в в нашем рецепте Установка Hyper-V внутри Windows Server, а также ВМ PSDirect, созданную в нашем рецепте Создание ВМ Hyper-V.

В первой части данного рецепта вы перемещаете хранилище для ВМ PSDirect. Вы создали эту ВМ в нашем рецепте Создание ВМ Hyper-V. Вы должны убедиться что эта ВМ поднята и запущена.

Вы исполняете первую часть данного рецепта в HV1 для перемещения ВМ PSDirect с HV1 на HV2. После того, как вы переместили эту ВМ на HV2, вы исполняете заключительную часть данного рецепта в HV2 для перемещения этой ВМ обратно в HV1. Если вы попытаетесь исполнить эту последнюю часть данного рецепта удалённо, например, для клиентской машины из HV1 (надлежащим образом обёрнутым в блок сценария, который вы исполняете при помощи Invoke-Command), вы обнаружите ошибку Kerberos по причине двойного прыжка Kerberos. Чтобы обойти эту проблему, вы можете развернуть Windows Credential Security System Provider (CredSSP).

На Шаге 1 вы проверяете текущее состояние своей ВМ PSDirect чтобы убедиться что она поднята и исполняется. Вывод должен выглядеть примерно так:

На Шаге 2 определяете значение местоположения, которое Hyper-V применяет для хранения имеющейся конфигурации ВМ для своей ВМ PSDirect с подобным следующему консольным выводом:

На Шаге 3 вы просматриваете то местоположение, которое применяется для хранения имеющихся у ВМ PSDirect виртуальных жёстких дисков с приводимым далее выводом:

На Шаге 4 вы перемещаете хранилище исполняющейся ВМ PSDirect. Этот шаг не вырабатывает вывод. После перемещения этого хранилища ВМ, на Шаге 5, вы повторно просматриваете значение местоположения конфигурации ВМ и имеющиеся подробности относительно всех жёстких дисков для нашей ВМ PSDirect. Вывод на данном шаге подобен следующему:

На Шаге 6 вы проверяете чтобы убедиться какие виртуальные машины доступны в HV2 с подобным приводимому далее выводом:

На Шаге 7 вы создаёте в HV2 новый коммутатор External для включения в HV2 сетевой среды. Видимый вами вывод таков:

На Шаге 8 вы включаете миграцию и в HV1, и в HV2. На Шаге 9 вы настраиваете в обоих серверах миграцию ВМ Hyper-V. Затем, на Шаге 10, вы выполняете миграцию в реальном масштабе времени своей ВМ PSDirect в HV2. Эти шаги не производят вывод.

На Шаге 11 вы отображаете сколько времени заняла в Hyper-V миграция вашей ВМ PSDirect с подобным отображаемому ниже выводом:

На Шаге 12 для просмотра имеющихся в HV2 виртуальных машин вы применяете командлет Get-VM. Поскольку вы осуществили миграцию PSDirect в HV2, в HV1 нет никаких ВМ. Таким образом, на данном шаге нет никакого консольного вывода. Затем, на Шаге 13, вы просматриваете имеющиеся в HV2 виртуальные машины, что производит похожий на представляемый далее вывод:

На Шаге 14 вы изучаете все подробности того где Hyper-V хранит свою конфигурацию ВМ и виртуальные жёсткие диски для своей ВМ PSDirect. Вывод с этого шага аналогичен такому:

На Шаге 15 (который вы исполняете в HV2) вы осуществляете миграцию своей ВМ PSDirect обратно в HV1, что не производит никакого консольного вывода. На финальном шаге данного рецепта, Шаге 16, вы просматриваете как долго потребовалось Hyper-V выполнять миграцию этой ВМ обратно в HV1 со следующим выводом:

На Шаге 1 вы проверяете текущее состояние своей ВМ PSDirect чтобы убедиться что она исполняется, если в получаемом вами выводе вы наблюдаете, что эта ВМ не запущена, вам надлежит воспользоваться для её запуска командлетом Start-VM, прежде чем продолжать этот рецепт.

На Шаге 6 для просмотра определённых в HV2 виртуальных машин вы применяете Get-VM . Получаемый вывод отображает те ВМ, которые были созданы в нашем рецепте Применение групп ВМ Hyper-V.

На Шаге 13 вы просматриваете имеющиеся в HV2 виртуальные машины, что теперь отображает и нашу ВМ PSDirect. Обратите внимание, что эта ВМ продолжает исполняться, поскольку вы осуществили миграцию в реальном масштабе времени. Рассмотрите возможность открытия удалённого подключения рабочего стола при помощи mstsc.exe или воспользуйтесь функциональной возможностью консоли управления Hyper-V и откройте сеанс с ВМ PSDirect. В каждом из применённых вариантов вы просмотрите как эта ВМ выполняет свою миграцию. Когда эта миграция завершится, вам может потребоваться снова зарегистрироваться в вашем сеансе ВМ.

Репликация ВМ это функциональная возможность восстановления после сбоев в рамках Hyper-V. Hyper-V создаёт реплику ВМ в удалённом сервере Hyper-V и удерживает эту реплику поднятой и актуальной в соответствии с оригинальными изменениями ВМ. Эта ВМ в таком удалённом хосте не активна на протяжении обычных действий своей первоначальной ВМ. Вы можете превратить эту реплику в активную в случае отказа по какой- то из причин хоста этой ВМ.

При помощи репликации Hyper-V хост ВМ источника укладывает в стопку все изменения в файле (файлах) VHD исполняющейся ВМ и своевременно отправляет их в сервер своей реплики. Этот сервер реплики затем применяет эти изменения к спящей реплики.

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

В данном рецепте вы создаёте и применяете реплику своей ВМ PSDirect, которой вы пользовались в нашем предыдущем рецепте этой главы.

Данный рецепт создаёт реплику ВМ Hyper-V для нашей запущенной на HV1 виртуальной машины PSDirect в HV2. Вы создали эту ВМ в нашем рецепте Создание ВМ Hyper-V. Вы также применяли эту ВМ в рецепте Управление ВМ и перемещением хранилища. Вам надлежит загрузить в DC1 инструменты управления Hyper-V. Если вы ещё этого не выполнили, осуществите в DC1 следующее:

Install-WindowsFeature -Name RSAT-Hyper-V-Tools,
                        Hyper-V-PowerShell        |
  Out-Null
		

Дополнительно, помните, что этот рецепт предполагает что отключили все межсетевые экраны в своей ВМ (и в хосте). Это упрощает вашу среду и позволяет сосредоточиться на данном рецепте, в данном случае, на репликации ВМ.

На Шаге 1 вы настраиваете HV1 и HV2 на то чтобы они доверяли делегированию для поддержки реплицирования ВМ и затем, на Шаге 2, вы перезапускаете оба хоста. Эти два шага не производят вывода на консоль.

После перезапуска хостов, на Шаге 3 вы настраиваете оба хоста Hyper-V на поддержку репликации ВМ. На Шаге 4 вы настраиваете партнёрство репликации Hyper-V между HV1 и HV2. Эти два шага не создают вывод.

На Шаге 5 вы просматриваете текущее состояние репликации Hyper-V сервера HV1, что создаёт подобный приводимому далее вывод:

На Шаге 6 вы проверяете текущее состояние репликации своей виртуальной машины PSDirect, что вы осуществляете в обоих серверах Hyper-V. Вот как примерно выглядит вывод этого шага:

На Шаге 7 вы запускаете процесс репликации своей ВМ. Этот шаг вовлекает создание Hyper-V дубликата ВМ в HV2, по существу, полное копирование нашей ВМ PSDirect. Что не производит вывод.

На Шаге 8 непосредственно сразу после Шага 7 вы можете наблюдать процесс первоначальной репликации. Вы должны видеть вывод, похожий на следующее:

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

Теперь, когда вы обладаете активированной репликацией PSDirect и Hyper-V завершил первоначальную репликацию, вы можете проверить способность восстановления после отказа. На Шаге 10 вы запускаете проверку восстановления после отказа своей ВМ PSDirect с HV1 на HV2. Этот шаг не вырабатывает вывод.

На Шаге 11 вы просматриваете текущее состояние PSDirect в HV2 с подобным приводимому ниже выводом:

На Шаге 12 вы останавливаете проверку восстановления после отказа, что не производит вывод. На Шаге 13 вы просматриваете текущее состояние виртуальных машин в HV1 и HV2 после останова отработки отказа, что производит подобный приводимому ниже вывод:

На Шаге 14 вы останавливаете свою ВМ PSDirect прежде чем позаботиться о запланированной отработке отказа. Затем, на Шаге 15, вы выполняете плановое восстановление после отказа PSDirect с HV1 на HV2. По завершению плановой отработки после отказа (то есть когда этот командлет завершается), на Шаге 16 вы завершаете свой процесс восстановления после отказа. На Шаге 17 вы запускаете PSDirect в HV2. Эти четыре этапа не производят вывод.

На Шаге 18 вы проверяете текущее состояние ВМ PSDirect в обоих хостах Hyper-V. Этот шаг производит такой вывод:

На Шаге 19 вы удаляете репликацию ВМ PSDirect с HV2. Этот шаг оставляет вашу ВМ PSDirect исполняющейся в HV1, хотя больше и не реплицируемую в другой сервер. На Шаге 20 вы удаляете ВМ PSDirect с HV1. Наконец, на Шаге 21 вы перемещаете свою ВМ PSDirect обратно на HV1 для завершения этого рецепта. Эти три последних шага не производят вывод.

На Шаге 11 вы просматриваете две ВМ PSDirect в HV1. На протяжении этого шага PSDirect поднята и исполняется в HV1, а также реплицирует все изменения в HV2. Вы видите отдельный тест ВМ, показывающий что соответствующая реплика ВМ поднята и выполняется в HV2. Всегда неплохо выполнять проверку отработки отказа после настройки репликации, чтобы убедиться что ваши реплицирование и восстановление работают как вы пожелали.

На Шаге 18 вы просматриваете текущее состояние ВМ PSDirect в обоих хостах ВМ. Как вы можете наблюдать на выводе с этого шага, на Рисунке 12-63, ваша ВМ PSDirect поднята и исполняется в HV2. В HV1 вы всё ещё обладаете некой (более старой) копией этой ВМ. После отработки отказа ВМ (и когда она заработала) в HV2, вы теперь можете перевернуть репликацию (то есть начать репликацию обратно к HV1 с HV2). Или, как мы сделали это в нашем случае, вы можете удалить эту ВМ в HV1, что позволяет вам переместить эту ВМ обратно на HV1, что и осуществлено на Шаге 21, который завершает данный рецепт.

При помощи Hyper-V в Server 2022, некая контрольная точка захватывает текущее состояние какой- то ВМ в момент восстановления. Далее Hyper-V позволяет вам откатывать назад ВМ в контрольную точку. Эту функциональную возможность предоставила версия Hyper-V Windows Server 2008. В Server 2008 такие точки восстановления носили название моментальных снимков (snapshots).

Начиная с Server 2012 Microsoft изменила это название на контрольную точку (checkpoint). Это изменение названия затем было приведено к соответствию с System Center и избавило от путаницы в отношении моментальных снимков Volume Shadow Copy Service (VSS), применяемых многими системами резервного копирования. В то время как команда Hyper-V изменила свою терминологию, некоторые из названий командлетов остались неизменными. Например, для восстановления некой ВМ в контрольной точке вы пользуетесь командлетом Restore-VMSnapshot.

Когда вы создаёте некую контрольную точку, Hyper-V временно приостанавливает эту ВМ. Hyper-V создаёт новый диск приращения (AHVDX). Затем Hyper-V возобновляет ту ВМ, которая записала все данные в диск приращений. Для некой ВМ вы можете создавать разнообразие контрольных точек.

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

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

В этом рецепте вы создаёте контрольную точку своей ВМ PSDirect и затем создаёте некий файл внутри этой ВМ. Вы получаете последующую контрольную точку и создаёте второй файл. Затем вы возвращаетесь к первой контрольной точке и наблюдаете что ваш первый файл всё ещё на месте, но второй отсутствует (поскольку вы создали свой второй файл после взятия этой контрольной точки). После этого вы удаляете все имеющиеся контрольные точки. После каждой операции контрольной точки вы рассматриваете свои файлы VHDX и AHVDX, которые Hyper-V применяет в вашей ВМ PSDirect.

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

На Шаге 1 вы создаёте объект полномочий Windows для его применения в вашей ВМ PSDirect. Этот шаг не производит вывод.

На Шаге 2 вы изучаете внутри PSDirect устройство C:\, что вырабатывает вывод, подобный следующему:

На Шаге 3 вы создаёте контрольную точку ВМ для своей ВМ PSDirect, что не производит консольного вывода. После создания вами такой контрольной точки ВМ, на Шаге 4, вы изучаете те файлы, которые Hyper-V применяет для её поддержки. Вывод с этого шага выглядит примерно так:

На Шаге 5 вы создаёте в устройстве C:\ своей ВМ PSDirect новый файл. Затем вы просматриваете содержимое этого файла. Вот как выглядит получаемый вывод:

После создания файла внутри вашей ВМ, на Шаге 6, вы создаёте вторую контрольную точку, что не производит никакого вывода. На Шаге 7 вы пользуетесь командлетом Get-VMSnapshot для просмотра имеющихся в настоящее время для PSDirect контрольных точек в HV1, что выглядит примерно так:

На Шаге 8 вы изучаете все файлы, которые Hyper-V применяет для хранения образов вашего виртуального диска и файлов контрольных точек для вашей ВМ PSDirect, примерно так:

На Шаге 9 вы создаёте в своей ВМ PSDirect новый файл, добавляете в этот файл содержимое и затем просматриваете созданные до сих пор файлы подобно следующему:

На Шаге 10 вы возвращаете свою ВМ PSDirect обратно к самой первой контрольной точке, что не производит никакого консольного вывода. На Шаге 11 вы просматриваете какие файлы теперь имеются в вашем устройстве C:\, например, так:

На Шаге 12 вы восстанавливаете свою ВМ PSDirect во второй контрольной точке, что не производит никакого вывода. На Шаге 13 вы изучаете те файлы, которые созданы в PSDirect, что выглядит следующим образом:

На Шаге 14 вы восстанавливаете PSDirect в его первую контрольную точку, что не генерирует никакого вывода. На Шаге 15 вы снова проверяете имеющиеся контрольные точки и файлы виртуального диска с подобным приводимому ниже выводом:

На Шаге 16 вы удаляете все контрольные точки для PSDirect в HV1, что не вырабатывает вывод. На заключительном Шаге 17 этого рецепта вы проверяете файлы данных своей ВМ из HV1, что производит такой вывод:

На Шаге 8 вы изучаете все файлы, которые Hyper-V применяет для поддержки контрольных точек ВМ PSDirect. Имеющиеся два файла VHDX удерживают начальное состояние когда вы сделали самую первую контрольную точку. Далее следуют ещё два набора файлов AHVDX. Каждый из этих файлов предоставляет всю ту работу, которая была произведена после взятия некой контрольной точки вплоть до взятия следующей.

На Шаге 9 вы просматриваете те два файла, которые вы создали в своей ВМ PSDirect. После возврата к своей первой контрольной точке, на Шаге 11, вы видите, что в устройстве C:\ нет никаких из тех двух файлов, которые вы создали после этой первой контрольной точки. Такое положение дел является ожидаемым результатом восстановления контрольной точки.