Глава 6. Hyper-V

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

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

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

Интеллектуальная подкачка страниц (Smart paging) является специализированной технологией в Hyper-V, которая работает при определённых условиях запуска некоторой ВМ. Интеллектуальная подкачка страниц применяет некий файл на определённом диске для эмуляции соответствия памяти требованиям Начальной оперативной памяти в случае, когда установки Начальной оперативной памяти превосходят установки Минимальной оперативной памяти. Начальная оперативная память (Startup RAM) является тем значением оперативной памяти, которое выделяется такой ВМ при её запуске, однако не тогда, когда она находится в состоянии исполнения. Например, вы можете установить значение Начальной оперативной памяти в 2048 MB, а значение Минимальной оперативной памяти в 512 MB для некоторой определённой ВМ. В сценарии, при котором в её хосте виртуализации доступно 1024 MB свободной оперативной памяти, интеллектуальная подкачка страниц позволит данной ВМ получить доступ к необходимым ей 2048 MB.

Так как он применяет диск для эмуляции памяти, механизм интеллектуальной подкачки страниц является актуальным только в случае, когда в одно и то же время происходят сразу три условия:

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

Вы можете настраивать местоположение конкретного файла интеллектуальной подкачки страниц на основе выделения для каждой ВМ. По умолчанию файлы интеллектуальной подкачки страниц записываются в папку конкретной виртуальной машины в папке C:\ProgramData\Microsoft\Windows\Hyper-V. Такой файл интеллектуальной подкачки страниц создаётся только в случае его необходимости и удаляется в пределах 10 минут перезапуска данной ВМ.

Измерение ресурсов позволяет вам отслеживать потребление индивидуальной ВМ ресурсов процессора, диска, оперативной памяти и сети. Чтобы включить измерение ресурсов, воспользуйтесь cmdlet PowerShell Enable-VMResourceMetering. Просматривать замеряемые данные вы можете применяя cmdlet PowerShell Measure-VM. Измерение ресурсов позволяет вам записывать следующую информацию:

Среднее использование ЦПУ измеряется в МегаГерцах (MHz, МГц). Все остальные замеры осуществляются в Мегабайтах. Хотя вы и можете выделять данные при помощи cmdlet Measure-VM, для их представления в визуальном виде, например, в виде графиков, вам необходимо применять другое решение.

Службы интеграции (integration services) позволяют определённому хосту виртуализации выделять информацию и осуществлять операции в размещённой на нём ВМ. Обычно требуется установка служб интеграции Hyper-V, хотя Windows Server 2016, Windows Server 2012 R2, Windows 10 и Windows 8.1 содержат службы интеграции Hyper-V по умолчанию. Файлы установки служб интеграции доступны для всех операционных систем, которые поддерживаются в Hyper-V. Вы можете включать следующие службы интеграции:

ВМ 2 поколения (Generation 2) являются специализированным типом ВМ, которые отличаются в настройке от тех ВМ, которые теперь называются ВМ 1 поколения, которые могут созадваться в хостах виртуализации, исполняющихся в операционных системах Windows Server 2008, Windows Server 2008 R2 и Windows Server 2012. ВМ 2 поколения поддерживаются в Windows Server 2016 и Windows Server 2012 R2.

ВМ 2 поколения предоставляют следующую функциональность:

В ВМ 2 поколения отсутствуют наследуемые сетевые адаптеры и основные наследуемые устройства, такие как COM порты и устройства считывания с дискет, более не присутствуют в них. ВМ 2 поколения выполнены для "виртуализации в первую очереди" и не разработаны для эмуляции компьютерного оборудования, которое вынуждено претерпевать преобразование физическогов виртаульное (P2V, physical to virtual). Если вам необходимо развёртывать некие ВМ, которым требуется эмуляция таких компонентов как COM порты, вам потребуется развёртывать ВМ 1 поколения.

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

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

Режим расширенного сеанса (Enhanced Session Mode) позволяет вам при использовании окон соединений Виртуальных машин осуществлять операции, включающие в свой состав вырезку и вставку {Прим. пер.: в буфер обмена}, перенапрваление аудио, а также установку соответствия томов и устройств. Вы также можете при помощи режима Расширенного сеанса осуществлять подпись в некоторой ВМ с использованием смарт карт. Вы включаете Режим расширенного сеанса в выбранном сервере Hyper-V выбирая флаговую кнопку для Allow Enhanced Session Mode в разделе Enhanced Session Mode Policy свойств данного сервера Hyper-V.

Вы можете применять Режим расширенного сеанса только с гостевыми ВМ, исполняющими операционные системы Windows Server 2016, Windows Server 2012 R2, Windows 10 и Windows 8.1. Для использования Режима расширенного сеанса вам необходимо иметь полномочия для связи с данной ВМ при помощи Удалённого рабочего места (Remote Desktop) для той учётной записи, которую вы применяете при регистрации в данной гостевой ВМ. Вы можете получить полномочия добавив данного пользователя в группу Remote Desktop Users. Также эти полномочия имеют пользователи, которые являются участниками локальной группы Administrators. На такой ВМ должна исполняться служба Remote Desktop Services.

RemoteFX предоставляет для ВМ поддержку неких 3D виртуального адаптера и перенаправления USB. Вы можете применять RemoteFX только если ваш хост виртуализации имеет совместимое GPU. RemoteFX позволяет одному или более совместимым графическим адаптерам выполнять задачи графической обработки для монжества ВМ. RemoteFX зачастую применятеся для предоставления поддержки в VDI сценариях приложениям с интенсивной графикой, таким как CAD.

Hyper-V в Windows Server 2016, а также все версии клиентских ОС с Windows 10 поддерживают встроенную виртуализацию. Вложенная виртуализация позволяет вам включать Hyper-V и размещать виртуальные машины в виртуальной машине, исполняемой в свою очередь под Hyper-V, в то время как эта ВМ исполняет Windows Server 2016 или Windows 10. Вложенная виртуализация может включаться на основе для каждой ВМ путём исполнения следующей команды PowerShell:

Set-VMProcessor -VMName NameOfVM -ExposeVirtualiationExtensions $true
 	   

.

Когда вы исполните эту команду, у вас появится возможность разрешения на данной ВМ Hyper-V. У вас нет возможности регулировать объём оперативной памяти некоторой виртуальной машины, которой разрешена вложенная виртуализация, при её исполнении. Хотя имеется возможность включения динамической памяти, причём объём оперативной памяти, выделяемый некоторой виртуальной машине, настроенной для вложенной виртуализации не будет плавать когда она будет включена.

Для маршрутизации сетевых пакетов через множество виртуальных коммутаторов, требующееся в процессе вложенной виртуализации, вы можете либо включить спуфинг (spoofing, подстановку) MAC адресов, либо настроить трансляцию сетевых адресов (NAT, network address translation). Вы можете разрешить спуфинг MAC адресов на той виртуальной машине, которую вы настроили для вложенной виртуализации. Вы можете осуществить это при помощи следующей команды PowerShell:

Get-VMNetworkAdapter -VMName NameOfVM | Set-VMNEtworkAdapter -MacAddressSpoofing On
 	   

Чтобы включить NAT, создайте виртуальный коммутатор NAT в той ВМ, которой разрешена вложенная виртуализация с использованием таких команд PowerShell:

New-VMSwitch -name VMNAT -SwitchTypeInternal
New-NetNAT -Name LocalNAT -InternalIPInterfaceAddressPrefix "192.168.15.0/24"
Get-NetAdapter "vEthernet (VmNat)" | New-NetIPAddress -IPAddress 192.168.15.1 -AddressFamily IPv4 -PrefixLength 24
 	   

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

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

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

Для установления соединения PowerShell Direct воспользуйтесь следующей командой:

Enter-PSSession -vmname NameOfVM
 	   

При помощи cmdlet Exit-PSSession вы выйдите из PowerShell Direct

Hyper-V поддерживает два отдельныйх формата виртуальных жёстких дисков.Файлы виртуальных жёстких дисков в формате .vhd имеют ограничение до 2040 ГБ. Виртуальные жёсткие диски в этом формате могут применяться на всех поддерживаемых версиях Hyper-V. Другим отличным от ограничения в размере является важным для запоминания момент, что вы не можете применять файлы виртуальных жёстких дисков в формате .vhd для ВМ 2 поколения.

Файлы виртуального жёсткого диска в формате .vhdx являются улучшенными в отношении виртуальных жёстких дисков в формате .vhd. Основным ограничением виртуальных жёстких дисков в формате .vhdx является то, что они не могут применяться с Hyper-V в Windows Server 2008 или Windows Server 2008 R2. Виртуальные жёсткие диски в формате .vhdx имеют следующие преимущества:

Вы можете выполнять преобразования жёстких дисков между форматами .vhd и .vhdx. Вы можете создавать виртуальные жёсткие диски в момент создания своей ВМ при помощи мастера New Virtual Hard Disk или cmdlet Windows PowerShell New-VHD.

Виртуальные жёсткие диски могут быть либо динамическими, либо использующими приращения, либо фиксированными. Когда вы создаёте диск фиксированного размера (fixed-size), всё используемое этим диском пространство выделяется на размещающем его томе в момент создания. Диски фиксированного размера увеличивают производительность если носитель физического хранилища не поддерживает Разгружаемый Windows обмен данными (Windows Offloaded Data Transfer). Выделяемое данному диску пространство толжно присутствовать на размещающем его томе при создании данного диска. Например, вы не можете создать диск фиксированного размера в 3 ТБ на томе, который имеет только 2 ТБ пространства.

Динамически расширяемые (dynamically expanding) диски используют изначально малый файл, который затем растёт по мере того, как его ВМ размещает на этом виртуальном жёстком диске данные. Это означает, что вы можете создать 3 ТБ динамический фиртуальный жёсткий диск в 2 ТБ томе, поскольку все 3 ТБ не будут выделяться при создании диска. Однако, в подобном сценарии вам необходимо гарантировать что вы расширите имеющийся размер 2 ТБ тома прежде чем подобный динамический виртуальный диск выйдет за пределы доступного пространства хранения.

Диски приращений (differencing)являются специализированным типом виртуального жёсткого диска, который состоит в потомственной связи с неким родительским жёстким диском. Родительский диск может быть диском фиксированного размера или динамическим виртуальным жёстким диском, однако диск приращений должен иметь тот же самый тип, что и родительский диск. Например, вы можете создать диск приращений в формате .vhdx для родительского диска, который использует формат .vhdx. Однако вы не можете создать диск приращений в формате .vhd для родительского диска с форматом .vhdx.

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

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

Вы можете создавать жёсткие диски приращений применяя cmdlet Windows PowerShell New-VHD, а также при помощи мастера New Virtual Hard Disk. При таком процессе создания вам необходимо определить его родительский диск.

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

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

Вы преобразовываете тип виртуального жёсткого диска (.vhd в .vhdx, .vhdx в .vhd, динамичский в фиксированный и фиксированный в динамический) либо применяя мастер New Virtual Hard Disk или при помощи cmdlet Windows PowerShell Convert-VHD. При преобразовании из .vhdx в .vhd помните, что виртуальные жёсткие диски в формате .vhd не могут превышать в размере 2040 ГБ. Таким образом, хотя и возможно выполнять преобразование виртуальных жёстких дисков в формате .vhdx, которые имеют размер менее 2040 ГБ, в формат .vhd, у вас нет возможности виртуальные жёсткие диски с большим размером.

Вы можете выполнять преобразования из одного формата в другой и из одного типа во второй только когда такие ВМ выключены. Прежде чем вы выполните усечение выбранного виртуального жёсткого диска при помощи мастера New Virtual Hard Disk или cmdlet Resize-VHD, вы должны усечь такой виртуальный жёсткий диск применяя диспетчер диска в операционной системе его ВМ. Вы можете выполнять изменение некоторого виртуального жёсткого диска пока такая ВМ испоняется при следующих условиях:

Пробрасывемые (pass-through) диски, также имеющие название непосредственно подключаемых дисков, делают возможным некоторой ВМ прямой доступ к лежащему в основе хранилищу вместо того, чтобы некий виртуальный жёсткий диск располагался в таком хранилище. Например, обычно применяя Hyper-V вы будете присоединять некую ВМ к какому- нибудь файлу виртуального жёсткого диска размещаемого на томе, отформатированном при помощи NTFS или ReFS. В случае пробрасываемых дисков такая ВМ вместо этого осуществляет прямой доступ к диску, а файл виртуального жёсткого диска отсутствует.

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

Пробрасываемые диски могут нарямую подключаться к имеющемуся хосту виртуализации, либо мугут быть дисками Fibre Channel или iSCSI. При добавлении пробрасываемого диска вам необходимо быть уверенным, что данный диск находится в отключённом состоянии. Вы можете применять консоль управления дисками или утилиту diskpart.exe на таком хосте виртуализации для установки такого диска в отключённое состояние.

Для добавления пробрасываемого диска с применением Windows PowerShell, для начала получите свойства того диска, который вы собираетесь пробросить, воспользовавшись cmdlet Get-Disk, а затем конвейеризируйте результат в cmdlet Add-VMHardDiskDrive. Например, чтобы добавить физический диск 3 в Вм с именем Alpha-Test, выполните следующую команду:

Get-Disk 3 | Add-VMHardDiskDrive –VMName Alpha-Test
 	   

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

Контрольные точки (checkpoint) представляют собой состояние некоторой виртуальной машины в определённый момент времени. Вы можете создавать контрольные точки и когда ВМ исполняется, и когда она остановлена. В случае, если вы создаёте некую контрольную точку исполняющейся ВМ, в этой контрольной точке также сохраняется состояние оперативной памяти такой исполняющейся ВМ. Создание некой контрольной точки приводит в результате к созданию либо .avhd, либо .avhdx файла (в зависимости от того, использует ли эта ВМ виртуальные жёсткие диски в формате .vhd или в формате .vhdx). Windows Server 2016 поддерживает два типа контрольных точек:

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

Вы можете создавать контрольные точки при помощи Windows PowerShell, применяя cmdlet Checkpoint-VM. Все прочие cmdlet Winows PowerShell, связанные с контрольными очками в Windows Server 2016 применяют существительное VMSnapshot, хотя в Windows 10 они имеют сбивающее с толку существительное VMCheckPoint.

В Windows Server 2016 имеются следующие cmdlet, связанные с контрольной точкой:

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

Виртуальные Fibre Channel позволяют вам осуществлять непосредственное соединение из исполняющейся под Hyper-V ВМ к хранилищу Fibre Channel. Виртуальные Fibre Channel поддерживаются в Windows Server 2016 если выполнены следующие требования:

Работающие под Hyper-V ВМ поддерживают до четырёх виртуальных адаптеров Fibre Channel, причём каждый из них должен быть связан с отдельной SAN (Storage Area Network).

Прежде чем вы сможете применять некий виртуальный адаптер Fibre Channel, вам придётся создать по крайней мере одну виртуальную SAN в данном хосте виртуализации Hyper-V. Виртуальная SAN является некоторой группой физических портов Fibre Channel, которые присоединяются к той же самой SAN.

Поддерживаются играция ВМ в реальном времени и отказоустойчивые кластеры ВМ; однако, виртуальный Fibre Channel не поддерживает контрольные точки ВМ, резервное копирование на основе хоста, или миграцию данных SAN в реальном времени.

Качество обслуживания (QoS, Quality of Service) хранилища позволяет вам ограничивать максимальное значение IOPS (Input/Output operations per second, операций ввода/ вывода в секунду) для виртуальных жёстких дисков. IOPS измеряются в 8- кБ приращениях. Если вы определяете максимальное значение IOPS, данный виртуальный жёсткий диск не имеет возможности превосходить это значение. Вы используете QoS хранилища для гарантии того, что никакая отдельная рабочая нагрузка в некотором хосте виртуализации Hyper-V не будет потреблять непропорциональный объём ресурсов хранения.

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

Некоторые встроенные в Windows Server 2016 технологии позволяют вам оптимизировать общую производительность и требования хранилища данных для связанных с ВМ файлов.

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

Когда она установлена, вы можете включать дедупликацию через узел Томов (Volumes node) или раздел Служб хранилища (Storage Services) в консоли Диспетчера сервера. При включении дедупликации вы определяете желаете ли вы применять общую схему дедупликации данных файлового сервера или схему инфраструктуры виртуальных рабочих мест (VDI, virtual desktop infrastructure). Для томов, которые размещают файлы ВМ, подходит схема VDI. Вы не можете включать дедупликацию в томе самой операционной системы, только в томах данных.

Многоуровневое хранение является технологией, которая делает для вас возможным смешивать быстрые хранилища, такие как твердотельные диски (SSD, solid state disk), с обычными шпиндельными магнитными дисками для одновременной оптимизации и производительности и ёмкости хранилища. Многоуровневое хранилище работает исходя из предпосылки, что меньшая часть всех сохраняемых в некотором томе данных отвечает за большую часть операций чтения и записи. Вместо того, чтобы создавать некий большой том, который целиком состоит из SSD, многоуровневое хранение, которое может быть включено посредством функциональности Пространств хранения (storage spaces), позволяет вам создавать некий том, состоящий и из твердотельных устройств и из шпиндельных магнитных дисков. При такой настройке часто используемые данные перемещаются на части данного тома, которые размещаются на SSD, а менее часто используемые данные перемещаются в те части тома, которые размещаются на более медленных шпиндельных магнитных дисках. Такая конфигурация позволяет большую часть преимуществ томов с только SSD дисками при её реализации без платы полной стоимости применения исключительно SSD дисков.

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

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

Внешние (external) коммутаторы подключаются к внешнему физическому или беспроводному сетевому адаптеру или групповому (team) NIC. Например, если хост виртуализации имеет четыре физических адаптера, настроенных как два групповых NIC, у вас имеется возможность настроить два внешних виртуальных коммутатора. Если у хоста виртуализации имеются три физических сетевых адаптера, которые не участвуют ни в каких группированных NIC, вы можете настроить три внешних сетевых коммутатора. Все подключаемые к одному и тому же внешнему коммутатору могут взаимодействовать друг с другом, а также с любым внешним хостом, подключённым к той сетевой среде, которой соответствует данный сетевой адаптер, в свою очередь подключённый к внешнему коммутатору. Например, если внешний коммутатор подключён к некоторому сетевому адаптеру, который присоединён к сетевой среде, которая може выполнять маршрутизацию обмена в Интернет, подключённая к такому внешнему коммутатору ВМ также имеет возможность осуществлять соединения с хостами в Интернете. Когда вы создаёте внешний коммутатор, в данном хосте виртуализации создаётся некий виртуальный сетевой адаптер, который соответствует данному коммутатору, только если вы не очистили те опции, которые позволяют управляющей операционной системе осуществлять совместное использование этого сетевого адаптера. Если вы сбрасываете этот параметр, данный хост виртуализации не будет способен взаимодействовать через такой сетевой адаптер, связанный с данным внешним коммутатором.

Внутренний (internal) коммутатор делает возможным коммуникацию между всеми ВМ и самим хостом виртуализации. Все подключённые к одному и тому же виртуальному коммутатору могут взаимодействовать друг сдругом и с самим хостом виртуализации. Например, вы можете успешно инициировать RDP соединение из самого хоста виртуализации к надлежащим образом настроенной ВМ или применить cmdlet Windows PowerShell Test-NetConnection из приглашения Windows PowerShell в данном хосте виртуализации для получение некоторого отклика от подключённой к внутреннему сетевому соединению. ПОдключённые к некоторому внутреннему коммуникатору ВМ не имеют возможности применять данный виртуальный коммуникатор для взаимодействия с хостами на отдельном хосте виртуализации, который подключён к некоторому внутреннему коммуникатору с тем же самым именем.

Подключённые к одному и тому же частному (private) коммуникатору ВМ на некотором хосте ВМ имеют возможность для взаимодействия друг с другом, однако у них нет возможности прямого взаимодействия с самим хостом виртуализации. Частные коммутаторы позволяют осуществлять взаимодействие только между ВМ в одном и том же хосте виртуализации. Например, ВМ alpha и beta подключены к частному коммуникатору p_switch_a на хосте виртуализации h_v_one. ВМ gamma подключена к к частному коммуникатору p_switch_a на хосте виртуализации h_v_ two. ВМ alpha и beta будут иметь возможность взаимодействовать друг с другом, однако не смогут взаимодействовать с h_v_one или ВМ gamma.

ВМ 1 поколения поддерживают два типа сетевых адаптеров: синтетические (synthetic) сетевые адаптеры и наследуемые (legacy) сетевые адаптеры. СИнтетический сетевой адаптер применяет драйверы, которые предоставляются когда вы устанавливаете в операционной системе данной ВМ службы интеграции. Если некоторая операционная система не имеет этих драйверов, или для данной операционной системы не доступны службы интеграции, тогда этот сетевой адаптер не работает. Синтетические сетевые адаптеры не доступны, пока некоторая операционная система ВМ, которая поддерживает их, не исполняется. Это означает, что вы не можете выполнять начальную загрузку PXE через некий синтетический адаптер в случае, когда вы настроили ВМ 1 поколения.

Наследуемые сетевые адаптеры эмулируют некий физический сетевой адаптер, аналогичнsq многопортовой карте DEC/Intel 21140 10/100TX 100 MB. Этот сетевой адаптер поддерживают многие операционные системы, даже те, которые не поддерживают службы интеграции. Это означает, что если вы желаете исполнять некую операционную систему в ВМ, которая не имеет услуг поддержки службы интеграции, например, такие как Linux или BSD, которые официально не поддерживается в Hyper-V, тогда вам придётся применять наследуемый сетевой адаптер, так как он скорее всего будет распознан такой гостевой операционной системой.

Наследуемый сетевой адаптер в ВМ 1 поколения также работает до того как будет загружена гостевая опреационная система данной ВМ. Это означает, что если вам желательна начальная загрузка PXE некоторой ВМ 1 поколения - например, если вы собираетесь применять WDS для развёртывания некоторой операционной системы на данной ВМ - вам необходимо настраивать некий наследуемый сетевой адаптер.

ВМ 2 поколения не разделяют синтетические и наследуемые сетевые адаптеры и имеют только один тип сетевого адаптера. ВМ 2 поколения поддерживают начальную загрузку PXE через такой единственный сетевой адаптер. Важно помнить, что в некоторой ВМ 2 поколения поддерживаются только самые последние операционные системы клиента и сервера Windows.

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

Дополнительный метод оптимизации сетевой производительности состоит в настройке управления полосой пропускания на уровне имеющегося виртуального сетевого адаптера. Управление полосой пропускания позволяет вам определять минимальную и максимальную пропускные способности обмена, вычисляемые для некоторого виртуального сетевого адаптера. Выделение минимального значения полосы пропускания является объёмом, который Hyper-V резервирует для данного сетевого адаптера. Например, если вы установите для каждой ВМ значение минимальной полосы пропускания в 10 MBps, Hyper-V обеспечит, что когда прочим ВМ требуется большее значение, они будут иметь возможность увеличивать использование своей полосы пропускания пока они не достигнут предела, определяемого объединением минимальных полос пропускания для всех размещённых на данном сервере ВМ. Выделения максимальной полосы пропускания определяет верхний предел для использования полосы пропускания. ПО умолчанию на виртуальных сетевых адаптерах не устанавливаются никакие минимальные и максимальные пределы.

Вы настраиваете управление полосой пропускания через выбор опции Enable bandwidth management (Включить управление полосой пропускания) для некоторого виртуального сетевого адаптера и определяя минимальное и максимальное выделение полосы пропускания в мегабитах в секунду (Mbps, megabits per seconds).

Виртуализация ввода/ вывода с единым корнем (SR-IOV, Single Root I/O Virtualization) увеличивает сетевую пропускную способность за счёт обхода виртуального коммутатора и отправки сетевого обмена напрямую к ВМ получателю. В кчестве такового, SR-IOV требует чтобы операционная система такой ВМ имела драйвер для своего физического сетевого адаптера. Вы можете применять SR-IOV только если физический сетевой адаптер и те драйверы сетевого адаптера, которые применяются самим хостом виртуализации поддерживают данную функциональность. Вы можете настроить SR-IOV для некоторого виртаульного коммутатора в процессе создания коммутатора. Когда у вас имеется некий вируальный коммутатор с разрешённой SR-IOV, вы затем можете включать SR-IOV на том виртуальном сетевом адаптере, который подключён к этому коммутатору.

Динамическая очередь виртуальной машины (Dynamic Virtual Machine Queue) является некоторой дополнительной технологией, которую вы можете применять для оптимизации сетевой производительности. Когда некоторая ВМ подключается к какому- то сетевому адаптеру, который поддерживает Очереди Виртуальных машин (VMQ), и VMQ включён в свойствах данного виртуального сетевого адаптера, тогда этот виртуальный сетевой адаптер имеет возможность применять DMA (Direct Memory Access, прямой доступ к памяти) для пересылки обмена напрямую к этой ВМ. При применении VMQ сетевой обмен обрабатывается тем ЦПУ, который назначен данной ВМ вместо того, чтобы применять сам сетевой адаптер, используемый в хосте виртуализации Hyper-V. Динамический VMQ автоматически выравнивает общее число ядер ЦПУ, применяемое для обработки сетевого обмена. Когда вы включаете VMQ на имеющемся виртуальном сетевом адаптере, в виртуальном коммутаторе автоматически включается динамический VMQ.

Группирование (teaming) NIC позволяет вам объединять полосы пропускания для множества сетевых адаптеров, а также предоставлять избыточное сетевое соединение на тот случай, если откажет один из имеющихся в группе сетевых адаптеров. Группирование NIC позволяет вам объединять до 32 сетевых адаптеров и использовать их как единый сетевой интерфейс. У вас имеется возможность настройки групп NIC при помощи адаптеров от различных производителей и при этом работающих на различных скоростях (хотя хорошей мыслью будет применение в промышленной среде сделанного одним и тем же производителем и при этом одну и ту же модель).

Если у вас в хосте виртуализации имеется несколько сетевых адаптеров, вы можете настроить на уровне хоста виртуализации группирование NIC. Препятствием является то, что вы не можете настроить группирование NIC на уровне хоста, если данный сетевой адаптер настроен на применение SR-IOV. Если вы желаете применять и SR-IOV, и группирование NIC, создавайте вместо этого в данной ВМ группированный NIC. Вы можете настроить группирование NIC внутри ВМ добавляя к ним адаптеры в новую группу при помощи консоли Диспетчера сервера или cmdlet PowerShell New-NetLbfoTeam.

При настройке в некоторой ВМ группового NIC, убедитесь что все виртуальные сетевые адаптеры, которые будут участвовать в данной группе имеют включённым спуфинг (spoofing) MAC адресов.

По умолчанию исполняющиеся на хостах Hyper-V ВМ применяют динамические адреса MAC. При каждом включении некоторй ВМ ей назначается некоторый MAC адрес из пула адресов MAC. Вы можете настроить все свойства данного пула адресов MAC через доступные в Диспетчере Виртуального коммутатора (Virtual Switch Manager) установки Диапазона MAC адресов (MAC Address Range).

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

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

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

Hyper-V поддерживает пометку VLAN (Virtual Local Area Network, Виртуальной локальной сети) тегами как на уровне самого сетевого адаптера, так и на уровне виртуального коммутатора. Теги VLAN делают возможным изоляцию обмена для подключённых к одной и той же сетевой среде хостов путём создания отдельных широковещательных доменов. Корпоративные аппаратные коммутаторы также поддерживают VLAN как способ разбиения на части сетевого обмена. Для применения VLAN в Hyper-V сетевой адаптер самого хоста виртуализации должен поддерживать VLAN. Идентификатор VLAN имеет 12 бит, что означает, что вы можете настраивать 4 094 идентификаторов VLAN.

Вы настраиваете теги VLAN на уровне виртуального сетевого адаптера выбирая флаговую кнопку Enable virtual LAN identification (Включить идентификацию виртуальной локальной сети) в свойствах данного виртуального сетевого адаптера. Применяемый на уровне виртуального коммутатора тег VLAN перекрывает тег VLAN, применяемый на уровне данного виртуального сетевого адаптера. Для настройки тегов VLAN на уровне виртуального коммутатора выберите Enable virtual LAN identification для управления опцией операционной системы и определите необходимый идентификатор VLAN.

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

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

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

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

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

Для настройки репликации Hyper-V вам необходимо настроить требующиеся установки Конфигурации репликации (Replication Configuration). Первый шаг состоит в выборе флаговой кнопки для Enable This Computer As A Replica server (Включения данного компьютера в качестве сервера реплики). Затем выберите метод аутентификации, который вы намереваетесь применять. Если все компьютеры являются частью одной и той же среды Active Directory, вы можете выбрать Kerberos. Когда вы используете Kerberos, реплицируемые данные Hyper-V не шифруются при их передаче по сети. Если вы беспокоитесь о шифровании сетевых данных, вы можете настроить IPsec. Другой опцией на случай, когда вы заботитесь о шифровании обмена репликации, которая полезна в случае если вы передаёте данные при помощи общедоступного Интернета без применения некоторого зашиврованного туннеля VPN, является применение аутентификации на основании сертификата. При применении аутентификации на основе сертификата вам необходимо имортировать и выбрать общедоступный сертификат, выпускаемый для имеющегося сервера партнёра при помощи такого диалога.

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

Когда репликация настроена и на сервере источнике, и на сервере получателе, вам также необходимо включить необходимые предварительно определённые правила межсетевого экрана на разрешение всего входящего обмена репликаций. Имеется два правила: одно для репликации при помощи Kerberos (HTTP) по порту 80, и другое для применения аутентификаии на основе сертификатов по порту 443.

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

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

Если ваши настройки реплики Hyper-V содержат в качестве источника или получателя отказоустойчивый кластер Hyper-V вам необходимо настроить и развернуть некого посредника (broker) реплик Hyper-V. Если же в качестве участника в источнике и получателе н участвует отказоустойчивый кластер, у вас нет потребности в настройке и развёртывании посредника реплик Hyper-V. Вы устанавливаете роль Hyper-V Replica Broker при помощи Диспетчера Отказоустойчивого кластера после того как вы включите роль Hyper-V в узлах кластера.

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

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

При рассмотрении хранилища для отказоустойчивого кластера помните о следующем:

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

Вы можете изменить имеющийся режим кворума вручную или при помощи Dynamic Quorum в Windows Server 2016, соответствующий режим кластера изменяется автоматически когда вы добавляете или удаляете узлы, или представляемые диски, или представляемые совместные ресурсы.

 

Большинство узлов

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

 

Большинство узлов и дисков

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

 

Большинство узлов и совместных файловых ресурсов

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

 

Без большинства: Только диски

Модель Без большинства: Только диски необходимо настраивать вручную и применяется только в проверочных средах, так как единственный голос, который вычисляется для кворума состоит в имеющемся представительном диске на совместно используемом томе. Такой кластер сохраняет свой кворум пока данный свидетель доступен, даже если отказали все узлы за исключением единственного. Аналогично, данный кластер будет в состоянии отказавшего если все его узлы являются доступными, а то совместно используемое хранилище, которое размещает единственный диск свидетеля отключается.

 

Вес узла кластера

Вместо того, чтобы каждый узел в кластере имел некий одинаковый голос при определении кворума, вы можете настроить какой из узлов кластера способен голосовать для определения кворума выполнив мастер Configure Cluster Quorum (Настройки кворума кластера). Настройка веса узла полезна когда вы развёртываете кластер со множеством площадок, и вы желаете управлять тем, какая из площадок сохраняет кворум в случае когда теряется взаимодействие между этими площадками. Вы можете определять каким узлам в кластере в настоящее время назначены голоса выбрав Nodes в своём Диспетчере Отказоустойчивого кластера.

 

Динамический кворум

Динамический кворум позволяет повторное вычисление некоторого кворума кластера всякий раз когда некий узел удаляется из или добавляется в кластер. Динамический кворум включён по умолчанию в кластере Windows Server 2016. Динамический кворум работает следующим образом:

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

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

При настройке адресации IPv4 или IPv6 для узлов отказоустойчивого кластера убедитесь что адреса для сетевых адаптеров узлов кластера выделяются либо статически, либо динамически. Избегайте применения смеси из статического и динамического выделения адресов, поскольку это вызовет некую ошибку при выполнении мастера проверки кластера. Также проверьте, что сетевым адаптерам кластера настроен шлюз по умолчанию {Прим. пер.: при этом единственный для каждого узла вне зависимости от общего числа сетевых адаптеров в нём. Подробнее см. раздел Групповой сервер в нашем изложении основ программно определяемых центров обработки данных.} Хотя мастер проверки кластера и не выдаст ошибки, если некий шлюз по умолчанию не представлен для данных сетевых адаптеров всякого потенциального узла кластера, вы не сможете создать некий отказоустойчивый кластер, пока отсутствует какой- нибудь шлюз по умолчанию.

Допустим, у вас имеется кластер из пяти узлов со множеством площадок в Мельбурне и Сиднее, причём три узла располагаются в Сиднее. Предположим, что Интернет связь к площадке в Сиднее утрачена. Внутри самого сайта в Сиднее весь кластер остаётся рабочим, так как с тремя узлами он имеет кворум. Однако если если внешняя связь с площадкой в Сиднее недоступна, у вас может возникнуть необходимость принудительного запуска имеющегося на площадке в Мельбурне кластера (который будет пребывать в состоянии отказавшего, поскольку имеется только два узла) при помощи ключа /fq (forced quorum, принудительный кворум) для предоставления служб клиентам.

В предыдущих версиях, после восстановления связи, это могло приводить к "раздвоению сознания", или разбиению кластера на части, так как обе стороны данного кластера настроены на то чтобы заслуживать доверие. Для разрешения этой проблемы в кластерах, исполняющихся под Windows Server 2012 или более ранней версией, вам необходимо было вручную повторно запускать все узлы, которые не являются частью принудительно запущенного набора кворума при помощи ключа /pq (prevent quorum, с исключением кворума). Windows Server 2016 предоставляет некое свойство, имеющее название Force Quorum Resiliency (Принудительная устойчивость к ошибкам кворума), которое автоматически перезапускает все узлы, которые не являются частью множества принудительно запускаемого кворума с тем, чтобы данный кластер не оставался в состоянии разделённого на части.

Совместные тома кластера (CSV, Cluster Shared Volumes) являются технологией хранения с высокой доступностью, которая делает возможным для множества узлов в некотором отказоустойчивом кластере иметь доступ только для чтения к тому же самому LUN. Это имеет следующие преимущества для отказоустойчивых кластеров Hyper-V:

CSV размещаются на серверах под управлением Windows Server 2016 или последующих операционных систем, позволяя множеству узлов в кластере осуществлять доступ к одним и тем же файловым системам, отформатированным под NTFS или ReFS. CSV поддерживает BitLocker, при помощи которого все узлы выполняют дешифрацию и шифрование содержимого при помощи учётной записи компьютера кластера. В CSV также интегрированы Многоканальность SMB (Server Message Block Multichannel) и SMB Direct, что делает возможным сетевой обмен по множеству сетевых сред и усиливается сетевыми картами, которые содержать технологию RDMA (Remote Direct Memory Access, Удалённого прямого доступа к памяти). CSV также может осуществлять сканирование и восстановление томов без необходимости перевода хранилище в отключённое состояние. Вы можете преобразовать хранилище кластера в некий CSV применив Disks node Диспетчера отказоустойчивого кластера.

Отсоединённые кластеры Active Directory, также называемые "кластерами без сетевых имён", являются свойством Windows Server 2016 и Windows Server 2012 R2. Отсоединённые кластеры имеют свои имена, хранящиеся в DNS, однако не требуют создания некоторой учётной записи компьютера внутри Active Directory. Основное преимущество отсоединённых кластеров состоит в том, что они делают возможным создавать без требования того, чтобы для представления данного кластера в Active Directory создавался некий объект компьютера, либо чтобы такая учётная запись для создания того, чтобы данный кластер имел возможность создавать объекты компьютеров в Active Directory. Хотя данная учётная запись, применяемая для создания некоторого отсоединённого кластера, не требует разрешения для создания объектов в Active Directory, все узлы, которые будут размещены в отсоединённом кластере должны быть всё же подключены к домену.

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

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

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

Отказоустойчивые кластеры наблюдают за состоянием ролей кластера чтобы обеспечивать их работоспособность. Это означает, что некий гостевой отказоустойчивый кластер может определять когда возникает определённый отказ какой- либо роли кластера и может предпринять меры по восстановлению данной роли. например, вы развернули некий отказоустойчивый кластер SQL Server 2016 в качестве гостевого кластера внутри какого- то отказоустойчивого кластера. Один из экземпляров данного SQL Server 2016, который участвует в данном гостевом кластере испытывает некий отказ. В данном варианте, когда внутри нашего гостевого кластера осуществляется восстановление после отказа, а другой экземпляр SQL Server 2016, размещённый в ином имеющемся узле гостевого кластера, продолжит обслуживать запросы клиента.

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

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

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

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

Все условия использования iSCSI, виртуального FC, CSV и CAFS в ВМ гостевых кластерах по существу те же самые, что и настраиваемые для обычных физических узлов размещения отказоустойчивого кластера.

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

Разделяемые виртуальные жёсткие диски имеют следующие требования:

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

Миграция в реальном времени (live migration) является процессом перемещением работающей ВМ с одного физического хоста виртуализации на другой без прерывания для клиентов или пользователей ВМ. Миграция в реальном времени поддерживается между узлами кластера, которые совместно используют хранилище, между отдельными хостами виртуализации Hyper-V, которые не являются участниками отказоустойчивого кластера с использованием в качестве хранилища некоторых разделяемых файловых ресурсов SMB 3.0 и даже между отдельными хостами Hyper-V, которые не являются участниками отказоустойчивого кластера при помощи процесса, имеющего название "миграция в реальном времени без каких- либо совместных ресурсов" (shared nothing live migration).

Миграция в реальном времени имеет следующие предварительные требования:

Имеется возможность выполнения миграции в реальном времени с использованием пробрасываемых дисков при выполнении следующих условий:

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

При миграции хранилища (storage migration) вы можете перемещать некие файлы виртуальных жёстких дисков из одного местоположения в другое. Вы можете выполнять миграцию хранилища в то время, когда данная ВМ исполняется или в то время, когда данная ВМ выключена. Вы можете перемещать данные в любое местоположение, которое доступно данному хосту Hyper-V. Это позволяет вам перемещать данные с одного тома на другой, из одной папки в другую, либо даже в некий совместный файловый ресурс SMB 3.0 на другом компьютере. При выполнении миграции хранилища выберите имеющуюся опцию хранилища данной ВМ Move.

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

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

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

При импорте некоторой ВМ вы можете выбирать из следующих вариантов:

Определение состояния сети ВМ (VM Network Health Detection) является свойством для ВМ, которое развёртывается в кластерах хостинга Hyper-V. При помощи Определения состояния сети ВМ вы настраиваете установки некого сетевого адаптера ВМ и помечаете определённые сети как защищённые. Вы выполняете это в разделе Расширенных свойств (Advanced Features) данного сетевого адаптера.

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

Дренажное отключение ВМ (VM drain on shutdown) является свойством, которое будет осуществлять автоматическую миграцию в реальном времени для всех исполняющихся ВМ с некоторого узла, если вы начнёте останов этого узла без помещения его в режим сопровождения. Если вы придерживаетесь рекомендуемых практических приёмов, вы поместите узлы в режим сопровождения (maintenance mode) и миграция в реальном времени в любом случае удалит с перезапускаемых или отключаемых вами узлов исполняющихся рабочих нагрузок. Основным преимуществом Дренажного отключения ВМ состоит в том, что если у вас был трудный день и вы забыли поместить некоторый узел кластера в режим сопровождения прежде чем отключаете его или осуществляете его перезапуск, все исполняющиеся ВМ выполнят миграцию в реальном времени с него без необходимости вашего прямого вмешательства.

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

Если у вас выполнены данные условия, вам необходимо создать некий вфйл настроек XML с названием DCCloneConfig.xml при помощи cmdlet Windows PowerShell New-ADDCCloneConfig. После его создания вам необходимо изменить этот файл и определить такие установки как имя компьютера, сетевые настройки и информацию о площадке Active Directory. Вам следует проверить сам шаблон DC при помощи cmdlet Get-ADDCCloningExcludedApplicationsList для определения того, что никакие имеющиеся на данном шаблоне DC службы не вызовут проблем при данном клонировании, например, такие службы как сервер DHCP.

Экранированные виртуальные машины (Shielded virtual machines) являются специальным типом виртуальных машин, которые имеют некую микросхему TPM (Trusted Platform Module, Модуля доверенной платформы), шифруется с применением BitLocker, а также может работать только на определённом уполномоченном хосте, который поддерживает называемую защищённой связную инфраструктуру. Экранированные ВМ делают возможным исполнение обработки чувствительных данных и рабочих нагрузок на хостах виртуализации безе какого- либо беспокойства о том, что некий злоумышленник, либо даже администратор данного хоста виртуализации, сможет экспортировать данную виртуальную машину чтобы получить доступ к расположенным в ней чувствительным данным.

Модуль PowerShell Hyper-V содержит большое число cmdlet, которые вы можете применять для управления всеми сторонами Hyper-V и виртуальных машин в Windows Server 2016. Эти cmdlet описываются в Таблице 6-1.

Таблица 6-1. Cmdlet PowerShell Удалённого доступа

Существительное	Вид Глагол	Функция
VFD	New	Создаёт некий новый виртуальный гибкий диск
VHD	Convert, Merge, Resize, Optimize, Dismount, New, Mount, Set, Get, Test	Управляет виртуальными жёсткими дисками
VHDSet	Optimize, Get	Управляет набором файлов виртуальных жёстких дисков, некоторое обновление для всех файлов VHDX в сравнении с предыдущими версиями Hyper-V
VHDSnapShot	Get, Remove	Применяется для управления моментальными снимками при помощи VHDSet
VM	Wait, Move, Get, Export, Debug, Measure, Import, Save, Resume, Restart, Set, Suspend, Stop, Start, Repair, Checkpoint, Remove, New, Compare, Rename	Применяется для управления виртуальными машинами
VMAssignableDevice	Add, Get, Remove	Управляет назначаемыми устройствами ВМ
VMBios	Set, Get	Управляет установками BIOS ВМ
VMComPort	Set, Get	Управляет установками COM порта ВМ
VMConnectAccess	Grant, Revoke, Get	Управляет тем, какие пользователи могут соединяться с определёнными ВМ
VMConsoleSupport	Enable, Disable	Управляет устройствами поддержки HID для виртуальных машин
VMDvdDrive	Add, Set, Get, Remove	Управляет установками DVD устройства ВМ
VMEventing	Disable, Enable	Разрешает или запрещает события ВМ
VMFailover	Complete, Stop, Start	Управляет отработкой после отказа
VMFibreChannel	Set, Get, Remove, Add	Управляет установками HBA Fibre Channel
VMFile	Copy	Копирует некий файл с вашего хоста виртуализации в какое- то местоположение внутри данной виртуальной машины
VMFirmware	Set, Get	Управляет установками встроенного ПО (firmware) ВМ
VMGPUPartitionAdapter	Set, Add, Remove, Get	Управляет установками GPU ВМ
VMGroup	New, Get, Remove, Rename	Позволяет вам управлять Группами ВМ, которые вы применяете для управления группами машин, которые могут составлять многоуровневое приложение
VMGroupMember	Remove, Add	Добавляет и удаляет ВМ для определённой группы
VMHardDiskDrive	Set, Add, Remove, Get	Управляет установками жёстких дисков ВМ
VMHost	Set, Get	Настраивает установки хоста ВМ
VMHostAssignDevice	Add, Mount, Get, Remove, Dismount	Управляет назначаемыми устройствами хоста ВМ
VMHostCluster	Get, Set	Настраивает установки кластера хоста ВМ
VMHostNumaNode	Get	Просматривает информацию Numa узла хоста ВМ
VMHostNumaStatus	Get	Просматривает состояние Numa узла хоста ВМ
VMHostSapportedVersion	Get	Просматривает данные поддерживаемой информации хоста ВМ
VMIdeController	Get	Управляет установками контроллера IDE ВМ
VMInitialReplication	Import, Start, Stop	Настраивает начальные установки репликации ВМ
VMIntegrationService	Enable, Disable, Get	Управляет службами интеграции ВМ
VMKeyProtector	Get, Set	Управляет установками защиты ключа ВМ
VMKeyStorageDrive	Set, Remove, Get, Add	Управляет установками диска хранения ключа ВМ
VMMemory	Set, Get	Управляет памятью ВМ
VMMigration	Enable, Disable	Управляет миграцией ВМ
VMMigrationNetwork	Add, Remove, Get, Set	Настраивает установки сетевой среды миграции ВМ
VMNetworkAdapter	Disconnect, Connect, Remove, Test, Add, Set, Rename, Get	Настраивает сетевые адаптеры ВМ
VMNetworkAdapterAcl	Remove, Add, Get	Управляет ACL сетевых адаптеров ВМ
VMNetworkAdapterExtendedAcl	Remove, Add, Get	Управляет расширенными установками ACL сетевых адаптеров ВМ
VMNetworkAdapterFailoverConfiguration	Get, Set	Управляет установками восстановления сетевых адаптеров ВМ
VMNetworkAdapterIsolation	Set, Get	Управляет установками изоляции сетевых адаптеров ВМ
VMNetworkAdapterRdma	Set	Управляет установками RDMA виртуальных сетевых адаптеров
VMNetworkAdapterRoutingDomainMapping	Set, Get, Romove, Add	Настраивает домены маршрутизации виртуального сетевого адаптера
VMNetworkAdapterTeamMapping	Romove, Get, Set	Настраивает групповое соответствие виртуального сетевого адаптера
VMNetworkAdapterVlan	Get, Set	Управляет установками VLAN сетевого адаптера ВМ
VMPartitionableGpu	Get, Set	Управляет установками GPU ВМ
VMProcessor	Get, Set	Настраивает установки процессора ВМ
VMRemoteFx3dVideoAdapter	Remove, Set, Get, Add	Управляет RemoteFX3d видео адаптеров
VMRemoteFxPhysicalVideoAdapter	Disable, Get, Enable	Управляет RemoteFX физических адаптеров
VMReplication	Get, Stop, Suspend, Remove, Measure, Enable, Resume, Set	Управляет репликациями ВМ
VMReplicationAuthorizationEntry	Set, Remove, New, Get	Управляет записями авторизации репликаций ВМ
VMReplicationConnection	Test	Проверяет репликацию ВМ
VMReplicationServer	Get, Set	Настраивает установки сервера репликаций ВМ
VMReplicationStatistics	Reset	Сбрасывает статистики репликации ВМ
VMResourceMetering	Reset, Disable, Enable	Настраивает измерения ресурса ВМ
VMResourcePool	Set, Rename, Get, Measure, New, Remove	Управляет установками пула измерений ресурса ВМ
VMSan	Remove, Disconnect, Connect, New, Set, Rename, Get	Управляет установками SAN ВМ
VMSavedState	Remove	Удаляет сохранённые данные состояния
VMScsiController	Remove, Add, Get	Управляет контроллером SCSI ВМ
VMSecurity	Get, Set	Управляет информацией безопасности ВМ
VMSecurityPolicy	Set	Настраивает политики безопасности ВМ
VMSnapshot	Rename, Restore, Export, Get, Remove	Управляет контрольными точками ВМ
VMStorage	Move	Перемещает хранилище ВМ
VMStoragePath	Get, Remove, Add	Настраивает путь хранилища ВМ
VMSwitch	Set, Get, Rename, Remove, Add, New	Управляет виртуальными коммутаторами
VMSwitchExtention	Enable, Disable, Get	Управляет расширениями в некотором виртуальном коммутаторе
VMSwitchExtentionPortData	Get	Просматривает расширения порта в некотором виртуальном коммутаторе
VMSwitchExtentionPortFeature	Set, Add, Remove, Get	Управляет свойствами порта коммутатора
VMSwitchExtentionSwitchData	Get	Просматривает данные порта коммутатора
VMSwitchExtentionSwitchFeature	Add, Get, Set, Remove	Управляет свойствами коммутатора
VMSwitchTeam	Set, Get	Управляет группами коммутатора
VMSwitchTeamMember	Add, Remove	Управляет участием в группах коммутатора
VMSystemSwitchExtension	Get	Просматривает расширения коммутатора, установленные в ВМ хоста
VMSystemSwitchExtensionPortFeature	Get	Просматривает свойства уровня порта, поддерживаемые расширениями коммутатора в ВМ хоста
VMSystemSwitchExtensionSwitchFeature	Get	Просматривает свойства уровня коммутатора, поддерживаемые расширениями коммутатора в ВМ хоста
VMTPM	Disable, Enable	Управляет установками виртуального TPM
VMTrace	Stop, Start	Управляет установками отслеживания для отладки ВМ
VMVersion	Update	Обновляет текущую версию данной ВМ
VMVideo	Get, Set	Настраивает установки видео для виртуальных машин