Установка Hyper‑V R2 в режи­ме Core

С 19 авгу­ста ком­па­нии, обла­да­ю­щие лицен­зи­я­ми Software Assurance (SA), а с 1 сен­тяб­ря все осталь­ные, уже нача­ли поти­хонь­ку пере­хо­дить на Windows Server 2008 R2. Те кто еще не начал, уже об этом заду­мы­ва­ют­ся. Многие, конеч­но, пока подо­ждут, но гото­вить­ся уже поти­хонь­ку начинают.

В вер­сии R2 теперь роль Hyper‑V доступ­на во всех редак­ци­ях Windows Server 2008 R2, а так же появи­лась спе­ци­аль­ная, бес­плат­ная редак­ция: Hyper‑V Server 2008 R2. Но мно­гие пред­по­чи­та­ют поку­пать Windows Server Enterprise 2008 R2 или самую стар­шую вер­сию Datacenter. Связано это преж­де все­го с вопро­са­ми лицен­зи­ро­ва­ния. Под “кор­по­ра­тив­ной” вер­си­ей мож­но запу­стить до четы­рех “стан­дарт­ных” или “кор­по­ра­тив­ных” вир­ту­аль­ных сер­ве­ров бес­плат­но, под стар­шей вер­си­ей это чис­ло не огра­ни­че­но. Но даже поку­па­те­ли Windows Server Standart 2008 R2 будут исполь­зо­вать Hyper‑V, так как лицен­зия поз­во­ля­ет запус­кать один вир­ту­аль­ный сер­вер бес­плат­но, но при этом откры­ва­ют­ся все пре­иму­ще­ства вир­ту­а­ли­за­ции. И никто не меша­ет поста­вить на тот же сер­вер Linux или WEB сер­вер. Но есть и огра­ни­че­ния, пер­вое R2 редак­ции теперь доступ­ны толь­ко для x64 плат­фор­мы, и для полу­че­ния мак­си­маль­но­го кол­ли­че­ства бес­плат­ных лицен­зий для вир­ту­аль­ных сер­ве­ров необ­хо­ди­мо что­бы исполь­зу­е­мая на желе­зе Windows Server 2008 исполь­зо­ва­лась толь­ко для целей вир­ту­а­ли­за­ции. Поэтому основ­ная роль, кото­рые будут ста­вить пер­вый поль­зо­ва­те­ли R2 это Hyper‑V.

Так как сер­вер будет уста­нав­ли­вать­ся с огра­ни­цен­ным чис­лом ролей, и к нему предъ­яв­ля­ют­ся более жест­кие тре­бо­ва­ния по без­опас­но­сти и обслу­жи­ва­нию, то сам сер­вер сле­ду­ет уста­нав­ли­вать в режи­ме Core. Установка сер­ве­ра в раз­лич­ных редак­ци­ях мало чем отли­ча­ет­ся, но для ясно­сти все при­ве­ден­ное в ста­тье отно­стит­ся к Windows Server Enterprise 2008 R2 Core, буду рас­смат­ри­вать рус­скую редак­цию сер­ве­ра (с комен­та­ри­я­ми для английской).

Итак, какие эта­пы нуж­но выпол­нить в про­из­вод­ствен­ной сре­де для уста­нов­ки сер­ве­ра Hyper‑V. Первый этап под­го­то­ви­тель­ный, вто­рой соб­ствен­но уста­нов­ка сер­ве­ра, тре­тий настрой­ка уда­лен­но­го управ­ле­ния сер­ве­ром, тре­тий под­ня­тие роли Hyper‑V.

На пер­вом эта­пе важ­но про­ве­рить, что­бы обо­ру­до­ва­ние было сов­ме­сти­мо с тех­но­ло­ги­ей Hyper‑V, про­ду­мать какие будут уста­нав­ли­вать­ся вир­ту­аль­ные маши­ны, куда они будут “смот­реть”, сколь­ко нуж­но сете­вых карт. Желательно (но не обя­за­тель­но) преду­смот­реть допол­ни­тель­ную сете­вую кар­ту, кото­рая будет исполь­зо­вать­ся исклю­чи­тель­но в целях управ­ле­ния сервером.
Второй этап очень прост. Сама уста­нов­ка зани­ма­ет доволь­но мало вре­ме­ни, и очень про­ста. Тут есть сле­ду­ю­щие осо­бен­но­сти. Во-пер­вых, если у вас спе­ци­фи­че­ское обо­ру­до­ва­ние, то на пер­вом эта­пе вы уже под­го­то­ви­ли драй­ве­ра для уста­нов­ки. Во-вто­рых, при уста­нов­ке лока­ли­зо­ван­ных вер­сий сле­ду­ет выби­рать язык вво­да с кла­ви­а­ту­ры (самый ниж­ний ComboBox) “США” (для англий­ский вер­сий оста­вить выбор по умол­ча­нию “USA”) осталь­ной выбор сде­лать в соот­вет­ствии с реги­о­ном. Ну и не забыть вве­сти пароль адми­ни­стра­то­ра (хотя не задать его не получится).

А вот после­ду­ю­щие эта­пы рас­смот­рим попо­дроб­нее и поша­го­во, так как они вызы­ва­ют мно­же­ство проблем.

Сначала, так как рабо­тать непо­сред­ствен­но на сер­ве­ре не очень удоб­но, настро­им уда­лен­ный доступ через служ­бу RDP. И имен­но через уда­лен­ный рабо­чий стол смо­жем выпол­нять прак­ти­че­ски все осталь­ные операции.
Для это­го после вхо­да на рабо­чий стол (соб­ствен­но это и не стол прак­ти­че­ски, одна команд­ная стро­ка), выпол­ним сле­ду­ю­щие команды:
cscript //h:cscript<br />
scregedit /ar /0<br />
scregedit /cs /0<br />
scregedit /im /1<br />
ipconfig<br />
Первая коман­да поз­во­лит выпол­нять после­ду­ю­щие коман­ды без вво­да допол­ни­тель­ных букв, и пере­хо­дов в нуж­ные ката­ло­ги, уста­но­вив по умол­ча­нию cscript.exe для запус­ка скрип­тов. Вторая коман­да раз­ре­ша­ет уда­лен­ные под­клю­че­ния к рабо­че­му сто­лу с помо­щью служ­бы RDP. Третья раз­ре­ша­ет исполь­зо­вать кли­ен­ты RDP преды­ду­щих вер­сий (если даль­ней­шую уста­нов­ку Вы буде­те про­из­во­дить, исполь­зуя сер­вер R2 или Windows 7, то эту коман­ду выпол­нять не обя­за­тель­но). Четвертая коман­да на дан­ном эта­пе не совсем нуж­на, она поз­во­ля­ет уда­лен­но управ­лять IPSEC. Впрочем после вво­да сер­ве­ра в домен при­ме­нят­ся поли­ти­ки без­опас­но­сти доме­на, и если они до это­го не были зада­ны, то нуж­но все эти пра­мет­ры задать для все­го доме­на в поли­ти­ках. Крайняя коман­да пока­жет IP адре­са кото­рые при­сво­е­ны всем сете­вым интер­фей­сам, запом­ни­те любой адрес кото­рый под­хо­дит для управ­ле­ния, и исполь­зуй­те его для вхо­да уда­лен­ным рабо­чим сто­лом. На этом эта­пе я реко­мен­дую пере­за­гру­зить ком­пью­тер (хоть это и не обя­за­тель­но), так как это пер­вая загруз­ка, и, воз­мож­но, опе­ра­ци­он­ной систе­ме тре­бу­ет­ся доуста­но­вить драй­ве­ра к спе­ци­фи­че­ско­му оборудованию.

Теперь мож­но вой­ти в сите­му с помо­щью уда­лен­но­го рабо­че­го сто­ла. И пер­вым делом поста­вим недо­ста­ю­щее обо­ру­до­ва­ние (ну а если не была най­де­на ни одна сете­вая кар­та, то обо­ру­до­ва­ние при­дет­ся достав­лять за кон­со­лью сер­ве­ра). Для уста­нов­ки обо­ру­до­ва­ния на сер­ве­ре core есть несколь­ко спо­со­бов. Иногда хва­та­ет про­сто запус­ка уста­но­воч­но­го фай­ла типа setup.exe, или запус­ком его в “тихом” режи­ме. Можно исполь­зо­вать коман­ду Pnputil:
Pnputil -i -a <Inf-файл>
Например сле­ду­ю­щей коман­дой мож­но доба­вить все драй­ве­ра, пред­ва­ри­тель­но загру­жен­ные на сер­вер, для плат Intel:
Pnputil -i -a c:\Data\intel\All\*.inf<br />
При уста­нов­ке будет выда­но сооб­ще­ние об успеш­ной или неуспеш­ной уста­нов­ке (напри­мер, не най­де­но обо­ру­до­ва­ние для это­го драй­ве­ра) и может быть выда­но окно пре­ду­пре­жде­ния о том что драй­вер не под­пи­сан. Именно пото­му, что при выпол­не­нии неко­то­рых опе­ра­ций воз­ни­ка­ют окна с вопро­са­ми и уве­дом­ле­ни­я­ми, уста­нов­ку нуж­но про­из­во­дить либо через кон­соль, либо через уда­лен­ный рабо­чий стол, хотя есть и дру­гие спо­со­бы (часть из кото­рых будет рас­смот­ре­на ниже).

После уста­нов­ки драй­ве­ров, не пере­за­гру­жа­ясь сме­ним имя компьютера.
netdom renamecomputer %COMPUTERNAME% /NewName:НОВОЕ-ИМЯ-СЕРВЕРА<br />
shutdown /r /f /t 0
Первая коман­да уста­нав­ли­ва­ет новое имя ком­пью­те­ра, посмот­реть преды­ду­щее, при необ­хо­ди­мо­сти мож­но мно­же­ством спо­со­бов, напри­мер коман­дой hostname. Вторая коман­да при­во­дит к неза­мед­ли­тель­ной при­ну­ди­тель­ной пере­за­груз­ке ком­пью­те­ра. Настоятельно реко­мен­дую для сер­ве­ров исполь­зо­вать имен­но эту коман­ду с клю­чем /f (в том чис­ле и с гра­фи­че­ским интер­фей­сом), хотя на новом, толь­ко уста­нов­лен­ном сер­ве­ре этот клю­чик совер­шен­но не обязателен.

После пере­за­груз­ки, до вво­да ком­пью­те­ра в домен, необ­хо­ди­мо настро­ить все сете­вые интер­фей­сы, и задать началь­ные пара­мет­ры системы.
Настроим сете­вые интерфейсы:
ipconfig /all<br />
netsh interface ipv4 show interfaces<br />
netsh interface set interface name="Подключение по локальной сети" newname="DMZ"
netsh interface set interface name="Подключение по локальной сети 3" newname="LAN"
netsh interface set interface name="Подключение по локальной сети 2" newname="Control"
netsh interface ipv4 set address name="Control" source=static address=172.19.25.101 mask=255.255.0.0 gateway=172.19.25.1 gwmetric=1
netsh interface ipv4 add dnsserver name="Control" address="172.19.22.2" index=1
netsh interface ipv4 add dnsserver name="control" address="172.19.12.1" index=2
ipconfig /all
Первые две коман­ды пока­жут суще­ству­ю­щие интер­фе­сы. Следующими тре­мя, пере­име­ну­ем их в более корот­кую фор­му, но глав­ное, несу­щий смысл (да и что­бы самим потом не запу­тать­ся), ста­рое имя интер­фей­са пока­жут обе преды­ду­щие коман­ды. Нужно отме­тить, что это выпол­нять совсем не обя­за­тель­но, и в коман­дах изме­не­ния сете­вых настро­ек вполне мож­но вме­сто име­ни исполь­зо­вать номер, выво­ди­мый вто­рой коман­дой. Шестая коман­да задаст ста­ти­че­ский адрес и шлюз по умол­ча­нию. Следующие две адре­са сер­ве­ров ДНС. В этих трех коман­дах, вме­сто име­ни интер­фей­са мож­но исполь­зо­вать его номер, но с номе­ра­ми мож­но лег­ко запу­тать­ся. Нужно уста­но­вить адре­са толь­ко для интер­фей­са управ­ле­ния, так как все интер­фей­сы, исполь­зу­е­мые в даль­ней­шем для вир­ту­а­ли­за­ции все рав­но будут иззме­не­ны. Также совер­шен­но не обя­за­тель­но изме­нять адре­са на ста­ти­че­ские, мож­но исполь­зо­вать и дина­ми­че­ские, выда­ва­е­мые DHCP сер­ве­ром, но во избе­жа­нии про­блем при обслу­жи­ва­нии, луч­ше выдать ста­ти­че­ский адрес. Имена луч­ше зада­вать латин­ски­ми бук­ва­ми, несмот­ря на то, что кири­ли­ца пол­но­стью под­дер­жи­ва­ет­ся. Если у Вас одна сете­вая кар­та, или у Вас нет отдель­но­го сете­во­го адап­те­ра для управ­ле­ния, то адре­са пока мож­но не зада­вать. Последней коман­дой посмот­рим пра­виль­но ли при­ме­ни­лись изме­не­ния. Сделать это нуж­но обя­за­тель­но, так как при вво­де команд, мож­но лег­ко ошибиться.

Перезагружаться на этом эта­пе нет смыс­ла, так как все изме­не­ния всту­па­ют в силу немед­лен­но. Также если вы изме­ня­е­те сете­вой интер­фейс через кото­рый зашли на сер­вер через уда­лен­ный рабо­чий стол, то воз­мож­но при­дет­ся пере­зай­ти сно­ва (ника­кие дан­ные не поте­ря­ют­ся) по ново­му IP адре­су (но если в коман­де была допу­ще­на ошиб­ка, то при­дет­ся топать к консоли).
Далее выпол­ним коман­ду: control intl.cpl, что поз­во­лит настро­ить рас­клад­ку кла­ви­а­ту­ры, сме­ну соче­та­ния кла­виш для всех поль­зо­ва­те­лей в домене. Также выста­вим дату и вре­мя (про­ще все­го сде­лать коман­да­ми date и time, хотя сохра­ни­лась и панель control timedate.cpl).
Теперь все гото­во для вво­да сер­ве­ра в домен. Этот этап мож­но выпол­нить позд­нее, или вооб­ще не вво­дить ком­пью­тер в домен, но пра­виль­нее что­бы он был в домене, пра­виль­но под все такие сер­ве­ра заве­сти отдель­ное под­раз­де­ле­ние в поли­ти­ке доме­на и очень акку­рат­но и жест­ко ее настро­ить. Также для ком­пью­те­ров в домене упро­ща­ет­ся управ­ле­ние и обслуживание.
NETDOM JOIN %COMPUTERNAME% /Domain:ДОМЕН /UserD:Administrator /PasswordD:ПАРОЛЬ_АДМИНИСТРАТОРА_ДОМЕНА<br />
shutdown /r /f /t 0<br />
Первая коман­да добав­ля­ет сер­вер в домен, нуж­но ука­зать имя поль­зо­ва­те­ля и пароль в домене, име­ю­ще­го пра­во на добав­ле­ние ком­пью­те­ров в домен. Также в этой коман­де мож­но сра­зу ука­зать под­раз­де­ле­ние и дру­гие пара­мет­ры. Вторая, уже зна­ко­мая коман­да, пере­за­гру­жа­ет сервер.

После пере­за­груз­ки настро­им уда­лен­ное управ­ле­ние. Этот этап вызы­ва­ет мно­же­ство про­блем, в основ­ном из-за при­ме­не­ния новых тех­но­ло­гий, поэто­му попро­бую опи­сать все вари­ан­ты настройки.
winrm quickconfig -quiet
netsh advfirewall set allprofiles settings remotemanagement enable
netsh advfirewall firewall set rule group="Удаленное администрирование" new enable=yes
netsh advfirewall firewall set rule group="Remote Administration" new enable=yes
netsh advfirewall firewall show rule name=all
Третья и чет­вер­тая коман­ды это одна и таже коман­да но для раз­ных лока­ли­за­ций опе­ра­ци­он­ной систе­мы. Если задать наиме­но­ва­ние груп­пы на лру­гом язы­ке, то ниче­го страш­но­го не про­изой­дет про­сто не най­дет­ся ни одно­го пра­ви­ла. Первая коман­да настра­и­ва­ет служ­бу WinRM, осталь­ные вклю­ча­ют пра­ви­ла во встро­ен­ном фарье­во­ле для раз­ре­ше­ния уда­лен­но­го управ­ле­ния. Вполне воз­мож­но что у Вас эти пра­ви­ла уже настро­е­ны поли­ти­кой доме­на, и ниче­го вклю­чать не при­дет­ся, но выпол­нить их не поме­ша­ет. Крайняя коман­да инфор­ма­ци­он­ная, она пока­жет все пра­ви­ла фарье­во­ла и в каком они состо­я­нии находятся.

После это­го нуж­но настро­ить кли­ент с кото­ро­го сер­вер будет управ­лять­ся (вни­ма­ние! кли­ент, а не сер­вер) Пусть для при­ме­ра это будет Windows 7. Если это будет дру­гая опе­ра­ци­он­ная систе­ма, то, воз­мож­но, Вам при­дет­ся доста­вить под­держ­ку WinRM.
winrm quickconfig -quiet
winrm set winrm/config/client @{TrustedHosts="172.19.25.101,*.clevelus.ru"}
winrs -r:<remotesystemnameoraddress> [-u:<username>] <command>
winrs -r:172.19.25.101 cmd
cd /
dir
Первая коман­да уже зна­ко­ма, она настра­и­ва­ет служ­бу WinRM на кли­ен­те, так же как и на сер­ве­ре. Второй вы раз­ре­ша­е­те кли­ен­ту уда­лен­но управ­лять сер­ве­ра­ми, и через запя­тую долж­ны ука­зать либо IP адре­са, либо име­на ком­пью­те­ров, кото­ры­ми мож­но управ­лять. Можно поста­вить и звез­доч­ку, но луч­ше в целях без­опас­но­сти ука­зы­вать кон­крет­ные IP адре­са или име­на. После выпол­не­ния вто­рой коман­ды вы уже може­те управ­лять уда­лен­ным сер­ве­ром с команд­ной стро­ки с помо­щью коман­ды WinRS (тре­тья коман­да). Четвертая коман­да яркий при­мер исполь­зо­ва­ния, выпол­ни­те ее для вхо­да на сер­вер. Выполнив край­ние две коман­ды, убе­ди­тесь, что вы “нахо­ди­тесь” на сервере.

Теперь уста­но­вим необ­хо­ди­мые роли на сер­вер. Выполним после­до­ва­тель­но коман­ды, луч­ше выпол­нять их через уда­лен­ный рабо­чий стол (если Вы еще не отклю­чи­ли его убе­див­шись в про­сто­те и мощи WinRS).
oclist<br />
start /w ocsetup NetFx2-ServerCore<br />
start /w ocsetup MicrosoftWindowsPowerShell<br />
start /w ocsetup BestPractices-PSH-Cmdlets<br />
start /w ocsetup ServerManager-PSH-Cmdlets<br />
start /w ocsetup Microsoft-Hyper-V<br />
Первая коман­да пока­жет спи­сок всех ролей сер­ве­ра и их состо­я­ние. Подобная коман­да из PowerShell(PS) име­ет более дру­же­люб­ный вид, да и вооб­ще воз­мож­но Вам при­дет­ся управ­лять сер­ве­ром имен­но через PS. Также на этом эта­пе уста­но­вим и роль Hyper‑V. После выпол­не­ния всех команд пере­за­гру­зим­ся (сер­вер сам дол­жен Вас об этом “попро­сить”. Префикс “start /w” нужен для того, что­бы дождать­ся окон­ча­ния выпол­не­ния преды­ду­щей коман­ды, ина­че тяже­ло выяс­нить, закон­чи­лась уста­нов­ка роли или нет (при исполь­зо­ва­нии WinRS и всплы­ва­ю­щем окне, коман­да может “нико­гда” не закон­чить­ся, поэто­му под “чистой” команд­ной стро­кой луч­ше не использовать).

После пере­за­груз­ки вве­дем коман­ду: powershell. И все даль­ней­шие дей­ствия мож­но выпол­нять под кон­со­лью PS (или мож­но запусть вто­рую консоль).
Следующие три коман­ды, выпол­нен­ные из под PS, пока­зы­ва­ют как мож­но управ­лять роля­ми несколь­ко более эффек­тив­но, пер­вая из кото­рых добав­ля­ет нуж­ный функционал.
Import-Module Servermanager <br />
Get-WindowsFeature<br />
Add-WindowsFeature
Выполните их после­до­ва­тель­но без пара­мет­ров, что­бы ознакомиться.

Далее выпол­ним из под PS три коман­ды, на чем закон­чим кон­фи­гу­ри­ро­вать уда­лен­ный доступ:
Enable-PSRemoting ‑force
Set-PSSessionConfiguration Microsoft.Powershell ‑ShowSecurityDescriptorUI
Get-Help about_Remote_Troubleshootingаа
Первая коман­да дона­стра­и­ва­ет уда­лен­ный доступ. Ее мож­но запус­кать сколь­ко угод­но раз, ниче­го страш­но­го не слу­чит­ся. При выпол­не­нии вто­рой коман­ды появит­ся окош­ко зада­ния раз­ре­ше­ний, добавь­те туда поль­зо­ва­те­лей, кото­рые будут уда­лен­но управ­лять этим сер­ве­ром. Третья коман­да выве­дет лока­ли­зо­ван­ную справ­ку по про­бле­мам и спо­со­бам реше­ний при уда­лен­ном досту­пе. Также есть заме­ча­тель­ная ути­лит­ка hvremote.wsf, кото­рая может помочь настро­ить уда­лен­ный доступ как на сер­ве­ре так и на кли­ен­те, если ниче­го не полу­ча­ет­ся. Но поль­зо­вать­ся ей нуж­но акку­рат­но, но если ниче­го не полу­ча­ет­ся, она может очень помочь.

Теперь нуж­но дона­стро­ить кли­ент, если поль­зо­ва­тель и ком­пью­тер нахо­дят­ся не в домене. Хотя все-таки сам ком­пью­тер реко­мен­дую в домен доба­вить неко­то­рые вопро­сы управ­ле­ния могут быть сра­зу сня­ты (при этом не обя­за­тель­но вхо­дить в него под учет­ной запи­сью доме­на). Для это­го в “Панель управления\Все эле­мен­ты пане­ли управления\Диспетчер учет­ных дан­ных” добавь­те запись для досту­па к ресур­су с учет­ной поли­ти­кой поль­зо­ва­те­ля доме­на, име­ю­ще­го пра­во на управ­ле­ние сервером.

Теперь мож­но запус­кать сред­ства управ­ле­ния сер­ве­ром с локаль­ной маши­ны, и самое инте­рес­ное для нас в этой настрой­ке: “Диспетчер Hyper‑V”. Если вы еще не уста­но­ви­ли на локаль­ный ком­пью­тер “Средства уда­лен­но­го адми­ни­стри­ро­ва­ния сер­ве­ра”, то в самый раз это сде­лать, или мож­но управ­лять с дру­го­го сер­ве­ра 2008 R2, уста­нов­лен­но­го, напри­мер в вир­ту­аль­ной машине. Для Windows 7 сред­ства мож­но взять тут.
Для того что­бы созда­вать и управ­лять вир­ту­аль­ны­ми маши­на­ми нам оста­лось дона­стро­ить Hyper‑V и, воз­мож­но, дона­стро­ить сете­вые на на сервере.

Запускаем оснаст­ку, под­клю­ча­ем­ся к выбран­но­му сер­ве­ру по пол­но­му име­ни. Если не полу­чи­лось под­клю­чить­ся, топро­верь­те, все ли преды­ду­щие шаги выпол­не­ны. Если Вы рабо­та­е­те не под учет­ной запи­сью поль­зо­ва­те­ля доме­на, но на ком­пью­те­ре вклю­чен­ном в домен, воз­мож­но удоб­нее будет запу­стить оснаст­ку сле­ду­ю­щим образом:
runas /noprofile /user:ДОМЕН\ПОЛЬЗОВАТЕЛЬ cmd<br />
mmc %SystemRoot%\system32\ServerManager.msc
но это не обя­за­тель­но. В настрой­ке роли Hyper‑V выбе­рем (под­клю­чим) сер­вер. Вначале выбе­рем “Параметры Hyper‑V” и зада­дим пути по умол­ча­нию для вир­ту­аль­ных машин и дис­ков. Далее запу­стим дис­пет­чер вир­ту­аль­ной сети. Предварительно на сер­ве­ре выпол­ним коман­ду ipconfig /all, что­бы вни­ма­тель­но посмот­реть на все интерфейсы.

Если назва­ния сете­вых карт будут сов­па­дать, то воз­ник­нут слож­но­сти. Галочку “Разрешить сов­мест­ное исполь­зо­ва­ние ” нуж­но ста­вить в том слу­чае, если Вы хоти­те что­бы был создан вир­ту­аль­ный адап­тер на сер­ве­ре на этом интер­фей­се. Сам интер­фейс после того как будет исполь­зо­ван Hyper‑V будет отлу­чен от локаль­ной сети, о чем Вам будет выда­но предупреждение.

Если у Вас выде­лен спе­ци­аль­ный адап­тер для управ­ле­ния сер­ве­ром, то мож­но снять эту галоч­ку. Если сете­вая кар­та у Вас един­ствен­ная, то остав­ляй­те обя­за­тель­но, ина­че не будет уда­лен­но­го досту­па к сер­ве­ру для управ­ле­ния. После того как Вы доба­ви­ли все интер­фей­сы, коорые будут исполь­зо­ва­ны в Hyper‑V сер­вер нуж­но перезагрузить.
После пере­за­груз­ки с помо­щью команд netsh, расмот­рен­ные выше, очень реко­мен­дую на сер­ве­ре посмот­реть все сете­вые интер­фей­сы и пере­име­но­вать их (для вир­ту­аль­ных доба­вив Virtual) для даль­ней­ше­го использования.
Все теперь мож­но созда­вать вир­ту­аль­ные машины.