Глава 5. Практический опыт, советы и трюки Hyper-V

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

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

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

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

Microsoft создал ряд правил для помощи вам в улучшении ваших окружений - их обычно называют наилучшими решениями (best practices). Однако теперь достаточно просто узнать их все и проверить что ваши серверы Hyper-V совместимы со всеми этими практическими рекомендациями.

Чтобы сделать это задание более простым, Windows Server поступает с BPA (Best Practices Analyzer, Анализатором наилучших решений). Он имеет набор наилучших практических советов и правил, которые он сравнивает со всеми компонентами вашего сервера и затем создаёт отчёт обо всех тех проблемах, которые он обнаружил в процессе сканирования. Такой отчёт содержит полезные подробности, такие как проблемы, столкновения, а также решения для возможных разногласий.

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

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

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

Следуя приводимым ниже шагам вы увидите как исполнять BPA для Hyper-V и изучите его результаты:

BPA для Hyper-V имеет 66 сканеров для определения того какие настройки не выполнены на основе документации Microsoft и практического опыта. Он включается автоматически при установке роли Hyper-V.

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

BPA доступен в Диспетчере сервера и может применяться в любое время. Рекомендуется осуществлять сканирование каждого сервера после его окончательной настройки, а также после этого на ежемесячной основе.

Hyper-V BPA также будет отображать информацию о поддержке Microsoft. Если ваш сервер имеет настройки, которые не поддерживаются Microsoft, он сообщит вам об этом в своих отчётах.

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

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

Все наилучшие практические решения Windows также доступны через PowerShell. Вы можете сканировать, фильтровать, получать результаты и выделять отчёты при помощи cmdlet powerShell.

Чтобы начать сканирование при помощи BPA Hyper-V, наберите следующую команду:

Invoke-BpaModel –BestPracticesModelId Microsoft/Windows/Hyper-V
 	   

После вызова BPA Hyper-V вы можете воспользоваться командой Get-BPAResult для анализа полученных результатов. Следующая команда отображает результаты выполнения сканирования BPA:

Get-BpaResult –BestPracticesModelId Microsoft/Windows/Hyper-V
 	   

Ниже в качестве примера того, как может выглядеть вывод Get-BPAResult приводится снимок экрана:

Если вы желаете отфильтровать при помощи PowerShell только предостережения и ошибки вы также можете воспользоваться следующей командой:

Get-BpaResult -BestPracticesModelId Microsoft/Windows/Hyper-V | Where-Object {$_.Severity –eq "Warning" –or $_.Severity –eq "Error"}
 	   

Вы также можете настроить PowerShell для отображения только наиболее полезной информации по каждой из ошибок, применяя следующую команду:

Get-BpaResult –ModelId Microsoft/Windows/Hyper-V | Where-Object {$_.Severity –eq 'Error'} | FL Title, Problem, Resolution, Help
 	   

Вот её результаты:

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

Применение PowerShell для создания отчётов HTML с результатами BPA

Для улучшения результатов PowerShell существует возможность проедоставления отчёта BPA HTML при помощи следующей команды. Данный сценарий применяет предыдущий пример фильра Get-BPAResult для отображения только результатов предостережений и ошибок:

$head = '<style>
 BODY{font-family:Verdana; background-color:lightblue;}
 TABLE{border-width: 1px;border-style: solid;border-color: black;bordercollapse: collapse;}
 TH{font-size:1.3em; border-width: 1px;padding: 2px;border-style: solid;border-color: black;background-color:#FFCCCC}
 TD{border-width: 1px;padding: 2px;border-style: solid;border-color: black;background-color:yellow}
</style>'
$header = "<H1>Hyper-V BPA Errors and Warnings Results</H1>"
$title = "Hyper-V BPA"

Get-BpaResult -BestPracticesModelId Microsoft/Windows/Hyper-V | Where-Object {$_.Severity -eq "Error" -or $_.Severity -eq "Warning" } | ConvertTo-HTML -head $head -body $header -title $title | Out-File report.htm
.\report.htm
 	   

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

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

Windows Server 2008 R2 SP1 ввёл новую функциональность, называемую Dynamic Memory (DM, Динамичской памятью), которая позволяет совместно применять оперативную память хоста всеми ВМ, использующими метод с названием Ballooning (Надувание). Ballooning гарантирует что ваши ВМ используют только ту оперативную память, которая им требуется и освобождает её обратно своему хосту или другой ВМ, которой требуется больше оперативной памяти. Это делает возможным автоматически перераспределять между ВМ имеющуюся в в родительском разделе оперативную память, увеличивая или уменьшая её потребление на основании текущей рабочей нагрузки.

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

Как мы уже обсуждали выше, Microsoft ввёл Динамическую память в Windows Server 2008 R2 SP1. Однако, Динамическая память не приемлема для всех рабочих нагрузок, например, таких как SQL или сервер Exchange. В Windows Server 2016 Microsoft ввёл новую функциональность с названием Runtime Memory Resize (Изменение размера памяти времени исполнения), которая делает возможной для вас в горячем режиме добавлять и удалять оперативную память для статических (выполняющихся) ВМ.

В Windows Server 2012 Microsoft ввёл поддержку для проектирования виртуальной топологии NUMA (Архитектуры с неравномерной памятью, Non-Uniform Memory Access) в ВМ Hyper-V усилив существующие физические узлы NUMA в работающей системе. Эта возможность может помочь улучшению производительности рабочей нагрузки выполняемой ВМ которая настроена на большие объёмы оперативной памяти.

Для получения дополнительной информации по Hyper-V Virtual NUMA, пожалуйста, ознакомьтесь с информацией по следующей ссылке: https://technet.microsoft.com/en-us/library/dn282282%28v=ws.11%29.aspx.

В данном рецепте вы ознакомитесь со всеми настройками и необходимыми установками для применения Динамической памяти, Изменения размера памяти времени исполнения и виртуального NUMA для ваших ВМ.

Чтобы быть уверенным, что Dynamic Memory (DM, Динамическая память) будет работать в вашей ВМ, убедитесь что были установлены самые последние версии службы интеграции. Для применения DM ВМ требуется установленной одна из нижеперечисленных ОС:

Что касается Изменения размера памяти времени исполнения, ваш хост должен исполнять Windows Server 2016 Hyper-V, а ВМ должны работать с предустановленной ОС из следующих:

Следующие шаги продемонстрируют как включить и осуществлять мониторинг Динамической памяти для ваших ВМ:

Всегда осуществляйте наблюдение за использованием памяти своих гостей применяющих Динамическую память; вы можете автоматизировать эту задачу при помощи PowerShell, что поможет вам держать на глазу запросы оперативной памяти и выделяемые вашим ВМ объёмы. {Прим. пер.: более основательные действия можно выполнять при помощи, например, таких средств, как Zabbix.}

Откройте свою консоль Windows PowerShell и выполните следующий cmdlet:

Get-VM | where DynamicMemoryEnabled -eq $true | select Name, MemoryAssigned, MemoryMinimum, MemoryMaximum, MemoryDemand | ConvertTo-Csv -NoTypeInformation | Add-Content -Path C:\PerfLogs\DynamicMemoryReport.csv
 	   

Следующие шаги продемонстрируют как по горячему добавлять и удалять оперативную память в выполняющиеся ВМ:

Приводимая далее информация продемонстрирует как настраивать для ВМ Виртуальную NUMA (Virtual NUMA) и Охватывающая NUMA (NUMA Spanning)

Виртуальная NUMA

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

Данные настройки связаны с общим числом процессоров (ядер), объёмом оперативной памяти и общему числу узлов на один разъём ЦПУ:

Давайте рассмотрим следующие два сценария.

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

Давайте предположим, что у нас имеются два хоста Hyper-V со следующими спецификациями:

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

Отметим, что на предыдущем снимке экрана присутствует кнопка Use Hardware Topology. Если вы измените настройки и представим себе, что вы не знаете какие значения были установлены первоначально, вы можете кликнуть по этой кнопке и все значения будут восстановлены обратно в рекомендуемые Hyper-V значения для данного определённого узла. В большинстве сценариев лучше всего применять именно кнопку Use Hardware Topology. Microsoft сделал для вас простым возврат назад к имеющейся у хоста физической топологии NUMA. Кроме того, для кластерыов Hyper-V с большим числом миграций в реальном времени, вам необходимо проверять сохранность одних и тех же значений настроек NUMA на одинаковых уздах для согласованности производительности.

Сценарий 2: Давайте предположим, что у вас имеется приложение, которому требуется для работы как минимум 2 ЦПУ, что является достаточно редким случаем, такое приложение осуществляет проверку числа ЦПУ, которая на самом деле всего лишь является числом "разъёмов"; вы получаете запрос на перемещение такого приложения в некую ВМ.

Если это имеет место и такому приложению необходимо более одного разъёма, тогда ему можно выставить два или более ЦПУ (vNUMA) для ВМ, если справедливы следующие условия:

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

Как это вычислить? Хорошо, это виртуализация лежащих в основе физических ЦПУ. имеющиеся vCPU всего лишь составляют расписание расслоения времени вычислений на таких физических ядрах. Запомните, пожалуйста, что vCPU и vNUMA являются логическими понятиями, причём осуществляют расслоение времени прерываний на процессоре, а Гипервизор всегда делает всё возможное по использованию наилучшего возможного расклада NUMA. Почти во всех случаях у вас нет нужды заботиться о наличии двух разъёмов для исполняющегося гостя, так как программное обеспечение должно заботиться об общем числе физических ЦПУ. Это всё касается логических ядер, причём один разъём с большим числом логических ядер может исключительно осуществлять параллельные вычисления (многопоточность).

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

Охватывающая NUMA

Как уже обсуждалось ранее в этом разделе, наилучшая производительность для системы со множеством узлов NUMA достигается для процессов, исполняющихся на ядрах процессора, применяющих локальную оперативную память {Прим. пер.: напомним, что начиная с архитектур K8 Hammer у AMD (II кв. 2003) и Nehalem у Intel (IV кв. 2008) x86 ЦПУ имеют собственный встроенный контроллер памяти.} внутри конкретного узла NUMA вместо того чтобы применять к узлам NUMA span (ресширение, охват), что будет означать что такая память требует установления соединения с другим процессором; она называется удалённой оперативной памятью и имеет более высокую латентность в сравнении с локальной памятью.

Существует два варианта охватывающих конфигураций NUMA: настройка на уровне хоста и настройка на уровне ВМ.

Настройки хоста: По умолчанию, начиная с Windows Server 2012 onwards, Hyper-V включает расширение (spanning) NUMA, что делает возможным выделять для ВМ оперативную память на всех узлах NUMA предполагающихся к применению ядер процессоров. Это позволяет не только исполнять больше ВМ, но также может приводить и к общей потере производительности, поскольку использование оперативной памяти вне того же самого узла NUMA данного процессора приводит к увеличению латентности.

Регистрация события Hyper-V-Worker отражает этот факт и вы можете обнаружить событие и идентификатором 3054:

Если вы в Hyper-V Settings запретите расширение NUMA, NUMA Spanning, повторно выберите Allow virtual machines to span physical NUMA nodes (Разрешить виртуальным машинам охват физических узлов NUMA), как это отображено на снимке экрана внизу. После этого ВМ не может выделяться оперативная память с удалённых узлов NUMA и мы могли бы ограничить использование только его собственным локальным узлом NUMA:

Запрет и разрешение охвата NUMA требуют перезапуска службы управления Виртуальной машиной Hyper-V (vmms.exe):

Охват NUMA допускает меньше способов оптимизации раз ресурсы не доступны в нутри определённых узлов NUMA за счёт стоимости производительности, однако он расширяет плотность и гибкость. Когда вы запрещаете охват (spanning) NUMA, вы запрашиваете состоятельную наивысшую производительность при имеющейся стоимости ресурсов, так как она не будет расширять узлы NUMA/

Мистер Бен Армстронг (Глава руководства Управления программой команды Hyper-V) снабдил нас более подробным и точным высказываением об охвате NUMA:

" "

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

-- мистер Бен Армстронг

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

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

Следующий снимок экрана отражает это, таким образом, данная ВМ не будет запущена:

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

Cmdlet PowerShell Get-VMHostNumaNode получает имеющуюся топологию NUMA некоторого хоста Hyper-V возвращает некий объект для каждого их узлов NUMA данного хоста. Если в итоге возвращается более одного узла NUMA, как это показано на снимке экрана ниже, ваш хост основывается на NUMA. Однако, если возвращается один узел, ваш хост не базируется на NUMA:

Настройки виртуальной машины

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

Как описывалось выше в Сценарии 1, если ВМ будет импортироваться или мигрировать между множеством хостов с различными топологиями NUMA, причём Охват NUMA был отключён (NUMA spanning has been disabled), это потребует настройки необходимых установок виртуальных NUMA для каждой ВМ на самые нижние значения по умолчанию, которые доступны в потенциальных хостах. Данное действие обеспечит то, что такая топология виртуального NUMA для данной ВМ будет подходить топологии физического NUMA для каждого хоста, на который она может мигрировать.

Однако, если Охват NUMA был включён (NUMA spanning has been enabled), будет иметь смысл также выполнить настройка установок такого виртуального NUMA для каждой ВМ. Это гарантирует то, что если данная ВМ перемещается на хост с другой топологией физического NUMA, такие назначения ресурсов ВМ не будут сдерживаться.

При отключённом Охвате NUMA на хосте вы можете воспользоваться cmdlet (Get-VMHost).NumaStatus или Get-VMHostNumaNodeStatus; эти cmdlet отобразят вам распределение памяти для всех ВМ по всем узлам NUMA.

Следующий снимок экрана отображает это. ВМ с названием WS-DC получила 50% (100ГБ) для свойе оперативной памяти от NUMA NodeId 1 и 50% (100ГБ) от NodeId 0:

Если производительность требуется на протяжении всего времени, что означает постоянную наилучшую производительность, тогда вы можете запретить охват NUMA (NUMA Spanning), однако вы должны гарантировать что все ВМ с их топологиями vCPU/ vNUMA смогут получать всю оперативную память внутри отдельного узла NUMA (из расчёта на узел vNUMA).

Помните, что если некая ВМ использует Динамическую память, тогда для этой ВМ Виртуальная NUMA отключена.

Я призываю вас ознакомиться с дополнительной информацией по Виртуальной NUMA и Охватывающей NUMA в TechNet по следующей ссылке: Hyper-V Virtual NUMA Overview.

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

Тремя наиболее важными настройками для Динамической памяти являются Minimum, Maximum и самая новая опция, RAM. В предыдущих версиях Hyper-V данная опция имела название Startup RAMю При всяком запуске такой ВМ, имеющееся в поле RAM field значение будет выделяться только для этой ВМ. Когда Windows и соответствующие службы интеграции загружены, Hyper-V начнёт изменять значение оперативной памяти этой ВМ на основе её загруженности, установленных настроек и остальных ВМ.

При установке RAM могут возникнуть проблемы, так как когда вам нужно повторно запустить некую ВМ, которая получает меньше оперативной памяти, чем это предписано в поле RAM, нет дополнительной доступной памяти от прочих ВМ. Hyper-V вводит понятие Smart Paging, что позволяет опускать значение для ВМ - необходимой для данной ВМ оперативной памяти - подлежащее записи в файле страниц подкачки данного сервера хоста, предоставляя надёжный процесс повторного запуска и тем самым не вызывая ошибок в процессе такого повторного запуска ВМ. Если данной ВМ необходим 1 ГБ оперативной памяти для запуска, Hyper-V может воспользоваться файлом подкачки страниц в таком компьютере хоста чтобы сделать возможным запуск такой ВМ. Опция Smart Paging может применяться только при повторном запуске такой ВМ в случае, когда нет доступной физической оперативной памяти или когда такая память не может быть отозвана от других исполняющихся на данном хосте ВМ. Сказав всё это, мы также рекомендуем добавить файл подкачки страниц на быстрый носитель во избежание проблем с производительностью.

Опция буферизации оперативной памяти (Memory buffer) позволяет вам определить процентное соотношение памяти, которое будет доступно для буфера при перемещении оперативной памяти другой ВМ. Это значение резервируется если никакие прочие ВМ не имеют более высокого приоритета и если имеется доступной физическая оперативная память в данном хосте. Например, если ВМ имеет 10ГБ оперативной памяти и е1 буфер настроен на 20 процентов, её компьютер хоста выделит дополнительные 20 процентов такой ВМ, что в данном случае составит 2ГБ физической памяти. Конечным результатом будет то, что такая ВМ будет иметь 12ГБ физической оперативной памяти, выделенной её на компьютере её хоста. Значением по умолчанию являются 20 процентов, однако оно может быть изменено на основании имеющегося приоритета ВМ.

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

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

Для целей мониторинга, чтобы просмотреть используемую в настоящее время загруженность DM, вы можете также применить закладку Memory в Диспетчере Hyper-V. Диспетчер Hyper-V предлагает следующую информацию:

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

После включения Динамической памяти (DM) для вашей ВМ, вы можете сберечь ресурсы оборудования, более эффективно использовать оперативную память и гарантировать то, что каждая ВМ получает необходимую память в зависимости от своей загруженности. Однако, применение Динамической памяти требует некоторого искусства. Несомненно, вы можете применять свою систему наблюдения для проектирования точных значений, однако это потребует от вас большого объёма времени, и при этом очень высока вероятность, что нечто изменится когда вы завершите выполнение этой задачи.

Изменение размера памяти времени исполнения (Runtime Memory Resize) является эволюцией Динамической памяти в Windows Server 2016. Интересной стороной статической оперативной памяти является то, что когда вы входите в свою консоль Диспетчера Hyper-V; таким образом, вы можете использовать оперативную память более эффективно увеличивая или уменьшая общий нужный при выполнении этих ВМ объём оперативной памяти.

Заметьте, пожалуйста, что увеличение в Изменении размера памяти времени исполнения для статической ВМ не пытается ограничивать исполнение ВМ сДинамической памятью на том же самом хосте. Оно всецело полагается на доступную память в корневом субъекте резервов DHMM (Dynamic Host Memory Management, Динамического управления памятью хоста).

Однако, уменьшение/ усечение статической памяти ВМ является более амбициозным.

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

Фрагментарные операции shrink могут происходить всякий раз, когда ваш гость использует ту оперативную память, которую вы пытаетесь удалить. Это наиболее общий случай. Он также может случиться, когда OS SKU имеет некоторое ограничение оперативной памяти, например, в x86, или если SKU имеет лицензию только до некоторого максимального предела. В данном случае такая ВМ настраивается с некоторым количеством оперативной памяти, однако гостевые ОС только "отслеживают" до своих пределов. Запрос у гостевой ОС на возврат оперативной памяти, к которой она не имеет доступ, будет иметь результатом частичное изменение размера памяти.

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

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

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

Модуль Hyper-V PowerShell в Windows Server 2016 имеет два cmdlet для регулировки имеющейся настройкой оперативной памятью виртуальных машин. Одной является Set-VM, а другой Set-VMMemory. В то время как первая применяется для изменения и настройки Виртуальной памятью, вторая в явном виде разработана для изменения настройки оперативной памяти.

Применение PowerShell для управления памятью виртуальных машин

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

Новым полезным свойством PowerShell является возможность применения вами сокращений, подобных MB для мегабайтов, GB для гигабайтов и TB для терабайтов:

Set-VMMemory -VMName SP* -DynamicMemoryEnabled $true -MaximumBytes 6GB -MinimumBytes 4GB -StartupBytes 5GB
 	   

Также для изменения тех же самых настроек вы можете применить cmdlet Set-VM, как это отображено в примере ниже:

Set-VM -Name SP* -DynamicMemory -MemoryMinimumBytes 4GB -MemoryMaximumBytes 6GB -MemoryStartupBytes 5GB
 	   

Помимо всего прочего через PowerShell также настраивается и Изменение размера памяти времени исполнения (Runtime Memory Resize): вы можете воспользоваться cmdlet Set-VM для изменения ваших установок статической памяти для исполняющихся ВМ, как это отображается следующим примером:

Set-VM -Name SP* -MemoryStartupBytes 4GB
 	   

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

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

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

$VMs = Get-VM * | Where-Object {$_.DynamicMemoryEnabled -eq $false}

Foreach ($VM in $VMs) {
# Memory Demand Before
$VMMemory = Get-VM -Name $VM.Name | `
        Select Name, State,@{Label=&qout;CPU Usage %&qout;;Expression={$_.CPUUsage}}, `
        @{Label=&qout;Assigned Memory MB&qout;;Expression={$_.MemoryAssigned/1048576}},
`
        @{Label=&qout;Memory Demand MB&qout;;Expression={$_.MemoryDemand/1048576}}, MemoryStatus

Write-Output &qout;Current Memory Demand&qout; $VMMemory

If ($VMMemory.'Memory Demand MB' -gt $VMMemory.'Assigned Memory MB') {
   [int64]$RAM = 1MB*($VMMemory.'Assigned Memory MB'+$VMMemory.'Memory Demand MB'+1)
   Set-VM -Name $VMName -MemoryStartupBytes $RAM

   # Memory Demand After
    $VMMemory = Get-VM -Name $VM.Name | `
        Select Name, State,@{Label=&qout;CPU Usage %&qout;;Expression={$_.CPUUsage}}, `
        @{Label=&qout;Assigned Memory MB&qout;;Expression={$_.MemoryAssigned/1048576}},
    `
        @{Label=&qout;Memory Demand MB&qout;;Expression={$_.MemoryDemand/1048576}}, MemoryStatus

    Write-Output &qout;Updated Memory Demand&qout; $VMMemory
    }
}
 	   

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

С рецептом Включение вложенной виртуализации в данной главе.

На протяжении многих лет это было одним из самых запрашиваемых свойств для Hyper-V. Именно потому, что Hyper-V не имел поддержки встроенной виртуализации. В Windows 10 и Windows Server 2016 Microsoft добавил поддержку Встраиваемой виртуализации.

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

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

Как отображается на следующей схеме, Microsoft встраивает вложенную виртуализацию в Hyper-V чтобы поддерживать в рабочем состоянии Контейнеры Hyper-V в ВМ, поэтому вы можете иметь некую ВМ Azur и всё ещё получать преимущества от исполнения Контейнеров Hyper-V в своём центре обработки данных, у поставщика хостинга или в Azur, причём при наличии той изолированности, которая требуется для имеющейся рабочей нагрузки и без какой бы то ни было необходимости заботы об управлении физическими машинами. Основная разница между Контейнерами Windows Server 2016 и Контейнерами Hyper-V состоит именно в таком добавлении уровня изолированности. Именно он предоставляет дальнейший этап изоляции и предотвращает совместное использование ядра данного хоста в тех случаях, когда вы желаете позволять приложениям без доверительных отношений и со "множеством арендаторов" (multi-tenant) исполняться на одном и том же хосте:

Для получения дополнительной информации о Контейнерах Windows Server и Hyper-V, пожалуйста, обратитесь к следующей ссылке:https://blogs.msdn.microsoft.com/msgulfcommunity/2015/06/20/what-is-windows-servercontainers-and-hyper-v-containers/. {Прим. пер.: также советуем свои переводы Главы 11, Контейнеры приложений и Docker в Полном руководстве Windows Server 2016, Главы 4, Реализация контейнеров Windows в ExamRef 70-740 и др.: включите тег HyperV в перечне наших ресурсов.}

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

Прежде чем начинать, убедитесь что ваша физическая система поддерживает работу с Hyper-V Windows Server 2016. Для получения дополнительной информации обратитесь, пожалуйста, к Главе 1, Установка и управление Hyper-V на полном сервере, Сервере ядра и Нано сервере. {Прим. пер.: также см. Главу 12 в переводе "Книги рецептов Windows Server 2016" или Глава 12 в переводе "Полного руководства Windows Server 2016" и других книг в теге HyperV наших ресурсов}.

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

Требования

Поддерживаемые сценарии

Не поддерживаемые сценарии

Приводимые ниже шаги продемонстрируют вам как включать и применять Вложенную виртуализацию в Windows 10 и Windows Server 2016:

Вариант сетевых настроек 1 - спуфинг адреса MAC

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

Вариант сетевых настроек 2 - трансляция сетевого адреса

Если вам не доступен спуфинг (подтасовка) MAC адреса, вы можете вместо него применять трансляцию сетевых адресов.

Чтобы позволить работать данной технологии, Microsoft виртуализирует функциональность Intel VT-x, которая обычно скрыта от той операционной системы, которая исполняется внутри некоторой гостевой ВМ. Следует также заметить, что на время написания данной книги поддерживаются только системы на основе Intel VT-x.

Вложенная виртуализация расширяет такую поддержку компонентов аппаратной виртуализации в некую гостевую виртуальную машину.

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

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

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

Такие пользователи были разделены на три следующие категории:

Для искушённых пользователей, которым необходимы для применения полные ресурсы GPU (Graphics Processing Unit) в приложениях с высокой напряжённостью, таких как нефть и газ, подобные приложения полагаются на максимально доступную вычислительную мощность, которая требует выделения GPU каждому пользователю. Здесь вы можете обнаружить HPC (High Performance Computing, высокопроизводительные вычисления), при которых вы желаете получить преимущества подобного GPU в качестве сопроцессора вычислений с одинарной или двойной точностью, что является обычным для таких рабочих нагрузок, при которых вы хотите получить всю имеющуюся вычислительную мощность.

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

Для Информационных работников, например, тех, кто обслуживает колл-центры; для них не требуются гигантские ресурсы GPU и, как правило, им не требуются ресурсы GPU и они вполне могут обходиться построением изображений программным способом. Однако мы наблюдаем, что даже Информационные работники могут получать небольшие преимущества от вычислений GPU, которые связаны с анимацией, а также PowerPoint или ускорением web. В качестве примера: декодирование видеографики из интернета, или усиление производимого сегодня основного веб контента.

Если вы знакомы с технологией удалённого доступа, вам известно, что у нас имеется поддержка множества пользователей, или App Remoting, которая является тем предметом, который способен увеличивать мощность отдельной ВМ или хоста со множеством пользователей чтобы увеличить плотность ваших Информационных сотрудников в пересчёте на машину. Однако, что касается приложений проектировщиков и искушённых пользователей, нам на самом деле требуются отдельное применение на ВМ. В терминах служб удалённых рабочих мест это не является ролью Хоста виртуализации Удалённых рабочих мест (RDVH, Remote Desktop Virtualization Host).

В Windows Server 2016, Microsoft вышел за её рамки, и ввёл новую технологию, а именно, версию Microsoft проброса аппаратных средств (Hardware Pass-Through), именуемую DDA (Discrete Device Assignment, Дискретное назначение устройства). Ключевым моментом, на который здесь следует указать, является наличие соответствия один- к- одному. Другими словами, существует одно GPU, адресуемое одной ВМ, следовательно вы можете ускорить столько ВМ, сколько GPU может поддерживать ваша система. Хорошая новость состоит в том, что такие производители оборудования как nVidia, Intel и AMD имеют большие серверные платы, которые могут содержать в себе множество GPU - от двух до четырёх GPU на каждой плате. Именно на этом основывалось начальное предложение Microsoft Azure.

В настоящее время они выпустили новый тип виртуальных машин, с названием N-Series, которые могут усиливать технологию DDA. В настоящее время ВМ N-Series Azure являются общедоступными. Для получения дополнительной информации посетите блог пост http://gpu.azure.com/.

Другой важный момент, на который следует здесь обратить внимание, состоит в том, что DDA не использует драйвер IHV Microsoft. На самом деле это будут драйверы самого производителя оборудования, работающие на самом госте, поэтому если у вас имеются такие приложения как SolidWorks или CATIA, имеющие собственные перечни различных определённых поддерживаемых драйверов, таким образом вы действительно можете загружать такой определённый драйвер в эту ВМ и он будет видеть это GPU просто как работающее голое железо (bare metal) и данное приложение будет великолепно работать.

Следующий снимок экрана демонстрирует, что Гостю целиком доступно GPU. Это означает, что доступны все возможности такого оборудования данного устройства, поэтому в случае nVidia Tesla M60, который имеет тонны мощности кодирования на борту, все эти возможности кодирования являются доступными такому гостю:

{Прим. пер.: Поскольку в Windows 8 и Windows Server 2012 (а также, скорее всего, в 2016) был удалён RPC интерфейс Удалённого доступа к PNP, При работе с Сервером Hyper-V вам могут понадобиться Device Management PowerShell Cmdlet. Данный модуль поддерживает следующие cmdlet:

Следующая таблица даёт вам подробности свойств вашей платы, а также перечень совместимостей в случаях, когда вы сопоставляете выбор между RemoteFX vGPU и DDA:

Стек Microsoft GFX Virtualization Hyper-V

Функция	RemoteFX vGPU	DDA
Масштабирование	1 GPU для множества ВМ	1 или более GPU для 1 ВМ
Совместимость приложений	DX 11.1, OpenGL 4.4, OpenCL 1.1	Все предоставляемые производителем возможности GPU (DX 12, OpenGL, CUDA и т.п.)
AVC444	По умолчанию включена (Win10/ Srv2016)	Доступна через Групповую политику (Win10/ Srv2016)
GPU VRAM	До 1ГБ VRAM	GPU Производителя (4ГБ и более)
Драйвер GPU у Гостя	Драйвер адаптера дисплея RemoteFX 3D (Microsoft)	Драйвер Производителя GPU (nVidia, AMD, Intel)
ОС Гостя	W7SP1, Win10, Server 2012R2, Server 2016	Windows 10, Server 2012R2, Server 2016, Linux
Гипервизор	Microsoft Hyper-V
Доступные ОС хоста	Win10, Server 2012R2, Server 2016	Server 2016
Оборудование GPU	GPU корпоративного класса (Quadro, GRID, FirePro)
Оборудование сервера	Нет особых требований	Современный сервер; предоставление IOMMU в ОС (обычно совместимые с SR-IOV аппаратные средства

Чтобы проверить вашу систему и удостовериться что все устройства соответствуют данному критерию для проброса в ВМ, вы можете загрузить следующий опубликованный Microsoft сценарий PowerShell и выполнить его на своём хосте: https://github.com/Microsoft/Virtualization-Documentation/blob/live/hypervtools/DiscreteDeviceAssignment/SurveyDDA.ps1.

На моей мобильной машине рабочей станции он возвращает длинный перечень, включающий элементы подобные тем, что приведены на следующем снимке экрана:

К сожалению, nVidia Quadro K2100M недопустима, однако Quadro K2100 должна работать.

Данный сценарий также сообщает вам соответствующие диапазоны MMIO для cmdlet Set-VM High/Low MMIO space; об этом немного подробнее.

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

DDA настраивается исключительно при помощи Windows PowerShell. Так как Microsoft рассматривает его как более чем расширенное свойство, оно не выставляется посредством диспетчера Hyper-V.

Мы начнём готовить свою виртуальную машину, которой будет назначено устройство DDA.

Откройте Windows PowerShell от имени администратора и выполните следующие cmdlets:

$VM = "DDA"
#Turn off VM
Stop-VM –Name $VM -TurnOff
#Set automatic stop action for the VM to Turn off
Set-VM –Name $VM -AutomaticStopAction TurnOff
#Enable Write-combining on the CPU
Set-VM -GuestControlledCacheTypes $true –VMName $VM
#Configure 32 bit MMIO space
Set-VM –LowMemoryMappedIoSpace 3Gb –VMName $VM
#Configure Greater than 32 bit MMIO space
Set-VM –HighMemoryMappedIoSpace 33280Mb –VMName $VM
 	   

Так как DDA назначает вашей ВМ всё устройство целиком, у нас имеются некоторые ограничения с переносимостью такой ВМ.

Чтобы автоматически остановить действие, которое настроено по умолчанию для сохранения состояния вашей виртуальной машины, нам необходимо установить его значение в Turn off, как это показано на следующем снимке экрана. Мы не можем в действительности сохранять состояние некоторой машины DDA; это обязательное требование; или же вы не сможете назначать оборудование через DDA. Вы будете получать некую ошибку, если пропустите данный шаг:

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

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

Set-VM -GuestControllerCacheTypes устанавливает значение в true. Это используется для оптимизации того, как ЦПУ взаимодействует с оперативной памятью на самом данном GPU чтобы осуществлять сбросы памяти и, таким образом, впечатляюще увеличивает производительность, аналогично с картой памяти пространства ввода/вывода (MMIO, memory mapped IO), по умолчанию Microsoft не создаёт большого пространства MMIO для таких ВМ, так как нет большого числа устройств, которые соответствуют этим ВМ, когда же мы начинаем говорить об GPU, им требуются для адресации большие диапазоны памяти, в качестве примера, VRAM токого GPU в 32- битном пространстве может масштабироваться до 3ГБ, а в 64- битном пространстве будет масштабироваться вплоть до 32ГБ, причём у вас нет необходимости изменять эти значения. Единственный случай, при котором эти установки становятся проблемой, это когда у вас выполняется соответствие со множеством GPU в данном хосте. Таким образом, например, ваш

Set-VM -HighMemoryMappedIoSpace когда вы начинаете иметь дело с 4 GPU, которые имеют каждая по 16 ГБ VRAM, например, nVidia Tesla K80, тогда вам на самом деле необходимо увеличить это значение до 65 536 МБ. Как уже упоминалось ранее, инспектирующий сценарий DDA сообщит вам диапазоны MMIO для cmdlet

Set-VM -LowMemoryMappedIoSpace и

Set-VM -HighMemoryMappedIoSpace.

На следующем шаге нам необходимо определить путь к вашему GPU и затем выполнить его размонтирование из вашего хоста.

Откройте от имени администратора Windows PowerShell в своём Hyper-V и выполните следующие cmdlet:

#Use Get-PnpDevice command with a search condition to narrow down the
PnpDdevice class
#In this example we are searching for "Display" class and NVIDIA GPU
$pnpdevs = Get-PnpDevice | Where-Object {$_.Present -eq $true} | Where-Object {$_.Class -eq "Display"} | Where-Object {$_.FriendlyName -match "NVIDIA"}
#Disable the GPU graphic device on the host system by using the DisablePnpDevice
Disable-PnpDevice -InstanceId $pnpdevs.InstanceId -Confirm:$false
#Specify the location path for the GPU card
$locationPath = (Get-PnpDeviceProperty -KeyName DEVPKEY_Device_LocationPaths -InstanceId $pnpdevs.InstanceId).Data[0]
#Dismount the device as a Display adapter from the host
Dismount-VMHostAssignableDevice –force –LocationPath $locationPath
 	   

InstanceId можно отыскать в Диспетчере устройств, что отображается на следующем снимке экрана, или воспользовавшись cmdlet Get-PnpDevice, как было показано в предыдущем примере:

LocationPath также можно отыскать в Диспетчере устройств, как это показано на приводимом ниже снимке экрана, или воспользовавшись cmdlet Get-PnpDeviceProperty, как было показано в предыдущем примере:

LocationPath является путём PCI вашей платы GPU в системе:

Самая последняя команда выполняет размонтирование данного устройства из родительского раздела вашего хоста при помощи cmdlet Dismount-VMHostAssignableDevice со следующим далее путём к местоположению.

На заключительном шаге нам необходимо добавить размонтированное устройство к своей ВМ воспользовавшись cmdlet AddVMAssignableDevice:

Assignment to VM
#Assign the device to the guest VM
Add-VMAssignableDevice –LocationPath $locationPath –VMName $VM
#Turn on VM
Start-VM –Name $VM
 	   

Если вы хотите усилить DDA при помощи служб Удалённых рабочих мест (на хосте RDSH или в сценариях App Remoting), вам необходимо включить внутри своей гостевой ОС следующую групповую политику.

Вы также можете пожелать взглянуть на остальные две групповые политики для опции AVC 444, которая может быть включена для DDA, в вашем разделе настроек RemoteFX vGPU:

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

Чтобы сделать это, откройте в качестве администратора Windows PowerShell и выполните следующие cmdlet:

#Remove a GPU from the VM and return it to the host
#Turn off VM that's currently using DDA
Stop-VM –Name $VM -TurnOff
#Get the locationpath for the dismounted display adapter
$DisMountedDevice = Get-PnpDevice -PresentOnly | Where-Object {$_.Class -eq "Display"} | Where-Object {$_.FriendlyName -match "NVIDIA"}
$DisMountedDevice | ft -AutoSize
$LocationPathOfDismDDA = ($DisMountedDevice | Get-PnpDeviceProperty
DEVPKEY_Device_LocationPaths).data[0]
$LocationPathOfDismDDA
#Remove the display adapter from the VM
Remove-VMAssignableDevice -LocationPath $LocationPathOfDismDDA -VMName $VM
#Mount the display adapter again to the host
Mount-VmHostAssignableDevice -locationpath $LocationPathOfDismDDA
#Enable the GPU graphic device on the host system by using the EnablePnpDevice
Enable-PnpDevice -InstanceId $pnpdevs.InstanceId -Confirm:$false
#Set the memory resources on the VM for the GPU to the defaults
Set-VM -GuestControlledCacheTypes $False -LowMemoryMappedIoSpace 256MB -HighMemoryMappedIoSpace 512MB -VMName $VM
#Start the VM
Start-VM -Name $VM
 	   

Настройка vGPU RemoteFX

Настройка RemoteFX vGPU может быть выполнена при помощи Диспетчера Hyper-V или Windows PowerShell.

Вы можете выделить 1 ГБ VRAM своему 3D видео адаптеру RemoteFX для ВМ в Windows Server 2016, как это показано на приводимом ниже снимке экрана:

Set-VMRemoteFx3dVideoAdapter -VMName <VMName> -MonitorCount 1 -MaximumResolution 1920x1200 –VRAMSizeBytes 1024MB
 	   

Что же касается хоста Hyper-V, у нас имеются два cmdlet для управления Физическим видео адаптером:

В Windows Server 2016 был обновлён RemoteFX vGPU. Когда вам необходима высокая плотность, именно RemoteFX является тем решением, которое вы ищите. В предыдущих выпусках RemoteFX поддерживал только DirectC 11. Однако, в Windows Server 2016, команда RemoteFX добавила поддержку в API ВМ для OpenGL 4.4 и OpenCL 1.1. Те же самые решения, которые допускает DDA, например, Adobe Photoshop, теперь также может принимать и RemoteFX.

Команда RemoteFX также поработала над различными улучшениями производительности в обмене и реализациях API. Вы также можете усиливать RemoteFX vGPU для Windows Server 2016 в качестве отдельной персональной ВМ. В прошлом RemoteFX поддерживал только клиентские ОС.

В RDP 8.1 Microsoft ввёл смешанный режим AVC/H.264, который, помимо применения для поддержки потокового мультимедиа RemoteFX, также расширяет и поддержку AVC/H.264 для изображений, посредством сжатия текста с применением имеющего владельца codec.

Однако в RDP 10 и Windows Serve 2016, Microsoft продвинул поддержку AVC/H.264 на шаг вперёд, введя режим полного экрана AVC 444 в качестве части в своём RDP (Remote Desktop Protocol). AVC 444 будет применять аппаратное ускорение AVC 420, если оно имеется, и для кодирования, и для декодирования, тем самым потенциально повышая производительность или уменьшая потребление батарей.

В Windows Server 2016 Microsoft добавил две новые групповые политики:

Приоритезация графического режима 444 H.264/AVC для соединений удалённых рабочих мест

Когда режим H.264/AVC включён в сервере RDP или внутри гостя, ему будет определён приоритет когда и клиент и сервер, оба, поддерживают AVC/H.264 и режим AVC 444. Отметим: для сред Сеансов хоста Удалённых рабочих мест (RDSH, Remote Desktop Session Host), осуществляется поддержка только полных сеансов рабочих мест с H.264/AVC 444, сеансы RemoteApp на текущий момент всё ещё применяют codec-и, имеющие частных владельцев.

Настройка аппаратного шифрования H.264/AVC для соединений удалённых рабочих мест

Данная политика позволяет вам включить аппаратное кодирование для AVC/H.264, когда оно применяется совместно с режимом AVC 444. Когда оно включено, все мониторы удалённых рабочих мест будут использовать один кодировщик AVC/H.264 в данном сервере. Если все кодировщики AVC/H.264 задействованы, данный сервер RDP автоматически вернётся к использованию программного кодирования. Данная политика должна быть включена на основной машине хоста Hyper-V если вы применяете RemoteFX vGPU, так как именно здесь происходит обработка. Если же вы применяете DDA, вы устанавливаете данную политику внутри своего гостя.

RemoteFX vGPU и DDA являются совершенно разными технологиями; при применении DDA у вас нет необходимости использовать роль RDVH (Remote Desktop Virtualization Host, Хоста виртуализации Удалённых рабочих мест) установленной на данном хосте.

Следующая схема отмечает различия между RemoteFX vGPU и DDA:

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

В противоположность описанному, при использовании DDA GPU совсем не предоставляется данному хосту; он идёт в полное распоряжение конкретного гостя. Такой гость имеет собственные драйверы, которые взаимодействуют через шину PCI хоста напрямую с самой графической картой, и именно по этой причине такое решение может работать с производительностью, близкой к производительности голого железа, так как здесь всё ещё присутствует между ними сам Гипревизор, и это в основном потому, что IOMMU выполняет перенаправление самих пакетов PCI, однако это приводит к потере производительности в пределах от двух до пяти процентов.

Как показано на следующей схеме, вы даже можете поставить в соответствие одной ВМ больше одного GPU:

Отметьте, пожалуйста, что DDA может применяться в более широком смысле, не только для графики. Microsoft изначально создавал её для графики, а также для целей NVMe. Это всего лишь два аппаратных устройства, которые Microsoft будет активно поддерживать на текущий момент, так как это по существу технология PCIe; у вас существует свобода в применении DDA также и для других устройств, однако, если вы столкнётесь с некоторыми проблемами, вам придётся обращаться напрямую к вашему производителю аппаратных средств.

Следующая матрица предоставит вам подробности вариантов сопоставления применения RemoteFX vGPU и DDA:

ОС гостевой ВМ сервера хоста	Windows Server 2012 R2 Hyper-V RemoteFX vGPU (ВМ 1 поколения)	Windows Server 2016 R2 Hyper-V RemoteFX vGPU (ВМ 2 поколения)	Windows Server 2016 R2 Hyper-V DDA (ВМ 1 и 2 поколения)
Windows 7 SP1	Да	Нет	Нет
Windows 8.1	Да	Нет	Нет
Windows 10	Да	Да	Да
Windows Server 2012 R2	Да	Нет	Да (требует KB3133690)
Windows Server 2016	Да	Да	Да
Windows Server 2012 R2 RDSH	Нет	Нет	Да (требует KB3133690)
Windows Server 2016 RDSH	Нет	Нет	Да
Linux	Нет	Нет	Да

Разделение GPU является новым свойством, которое будет оставаться в рабочем состоянии в последующих выпусках Hyper-V/

На момент написания, если мы выполняем поиск в модуле PowerShell Hyper-V, мы можем наблюдать различные команды, относящиеся к разбиению GPU, что отображено на снимке экрана внизу:

При отсутствии драйвера производителя оборудования данные команды бесполезны для нас и не могут применяться; однако, Microsoft планирует поддержку разбиения GPU.

Таким образом, что такое разбиение GPU? Это именно та технология, которую Microsoft разработал для производителей аппаратных средств, таких как nVidia, Intel и AMD, чтобы взять всё физическое GPU и разбить его на меньшие, виртуальные GPU. nVidia называет это технологией GRID vGPU, AMD именует её MxGPU, а Intel GVT-g. Они все имеют различную терминологию, но это всего лишь названия продуктов.

На самом деле это версия GPU SR-IOV ( Single-Root Input / Output Virtualization, Виртуализации ввода/ вывода с единым корнем) для сетевых сред. Самым большим отличием здесь является сложность самого GPU и то, как каждый производитель реализует его. Некоторые производители осуществляют его поддержку усиливая части спецификаций SR-IOV PCIe, в то время как другие имеют более индивидуальные решения. Microsoft абстрагируется от данного представления, позволяя каждому производителю осуществлять поддержку разделения GPU таким образом, как спроектировано его аппаратное решение, поэтому все имеющееся на рынке аппаратные средства и решения имеют возможность работать.

Это одна из наиболее дискутируемых тем. Многие ИТ специалисты скрещивают копья следует или нет устанавливать Анти- вирус на ваших хосте и ВМ.

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

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

Прежде чем вы начнёте, убедитесь что ваше антивирусное программное обеспечение поддерживает Hyper-V Windows Server 2016.

Следующие шаги покажут вам как определить используемый по умолчанию для ВМ и виртуальных дисков путь и как настроить исключения для вашей системы AV:

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

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

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

Защита статической среды сервера с использованием агентов на каждом из терминалов относительно проста, так как ваша среда не изменяется слишком часто. Администраторы будут обычно иметь доступ к вашему серверу для установки и сопровождения таких агентов. так как эти серверы обычно не работают на полной ёмкости, общая производительность исполняющейся на них рабочей нагрузки обычно не подвержена воздействию со стороны требовательных к ресурсам сканирований AV. {Прим. пер.: ха- ха. Смотрим как ведут себя "взрослые": RTAV в нашем переводе Полного руководства VMware Horizon 7.}

Защита вашей виртуальной среды при помощи 5nine Cloud Security

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

Так как хосты виртуализации разработаны для исполнения близкой к полной загруженности для лучшего применения ресурсов, в случае использования виртуальными машинами агентов исполнения некоторого сканирования AV (которое может приводить к 30% пикам в использовании ЦПУ), это может замедления всех имеющихся на данном хосте ВМ. В центре обработки данных с виртуализацией применяйте решения безопасности на основе хоста, которые не требуют установки агентов внутри всех ВМ, например, 5nine Cloud Security.

5nine Cloud Security от 5nine Software предоставляет единственное решение свободное от агента антивируса, межсетевого экрана и определения вторжений для Hyper-V с защитой от Bitdefender, Kaspersky Labs, или ThreatTrack. Это программное обеспечение безопасности фильтрует обмен приходящий и исходящий от ВМ через расширение виртуального коммутатора центрального Hyper-V, что предоставляет защиту на уровне хоста прежде чем угроза достигнет самой ВМ. Это означает, что безопасность управляется централизованно и всем пользователям ВМ нет необходимости беспокоиться об обновлениях или сканированиях гостевых ОС вне зависимости от того исполняют ли они Нано сервер, Сервер ядра, Полный сервер или Linux.

Для получения дополнительной информации об 5nine Cloud Security, обратитесь к http://www.5nine.com/5nine-security-forhyper-v-product.aspx.