Hyper v не удается подключиться к виртуальной машине: "Не удается подключиться к виртуальной машине."для новой виртуальной машины Hyper-V

Содержание

Доступ к консоли виртуальной машины Hyper-V с помощью RDCMan

Remote Desktop Connection Manager (RDCMan) — это официальная утилита Microsoft для удобного подключения ко множеству серверов по протоколу RDP (утилита предназначена заменить устаревшую оснастку Remote Desktops), позволяющая существенно упростить жизнь системному администратору. В RDCMan 2.7 появилась довольно интересная функция – возможность прямого подключения к консоли любой виртуальной машины, запущенной на гипервизоре Hyper-V, с помощью VMConnect. Соединение устанавливается в режиме Enhanced Session Mode, который использует для подключения шину VMBus (логический канал связи между хостом Hyper-V и виртуальными машинами).

Чтобы подключится к конкретной виртуальной машине, необходимо получить ее идентификатор (VM ID). С помощью PowerShell идентификатор конкретной ВМ можно получить так:

Get-VM -Name lon-dc01 | select ID

После того, как вы узнали идентификатор виртуальной машины, откройте RDCMan и добавьте новый сервер. В свойствах сервера проверьте, что включена опция «VM console connect». Затем в поле Server name укажите имя Hyper-V сервера, на котором запущена виртуальная машина. В поле id укажите ее идентификатор, полученный на предыдущем шаге, и сохраните настройки.

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

Совет. Даже если ваша учетка состоит в локальной группе администраторов, ее нужно непосредственно включить в группу Hyper-V Administrators.

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

Совет. На сервере Hyper-V должен разрешен доступ к порту TCP 2179.

New-NetFirewallRule -Name "Hyper-V REMOTE_DESKTOP_TCP_IN " -DisplayName "Hyper-V REMOTE_DESKTOP_TCP_IN Port 2179" -Description Inbound rule for Hyper-V to allow remote connection to the virtual machines over Network port TCP 2179. VMMS.exe listens traffic over network port 2179" -Group "Hyper-V" -Direction Inbound -Protocol TCP -LocalPort 2179 -Action Allow -Profile Public

В том случае, если вы хотите разрешить подключаться к консоли ВМ определенному пользователю (не являющемуся администратором), необходимо предоставить ему разрешения следующим образом:

Grant-VMConnectAccess -ComputerName hyper-srv-01 -VMName lon-srv-01 -UserName contoso\iaivanov2

В том случае, если при подключении к ВМ появляется ошибка «Unknown disconnection reason 3848», необходимо настроить ряд разрешений. Дело в том, что политика CredSSS (Credential Security Service Provider) на хосте Hyper-V по умолчанию не позволяет аутентифицировать удаленных пользователей.

Запустите консоль PowerShell с правами администратора и выполните следующие команды:

New-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\Credssp\PolicyDefaults\AllowFreshCredentialsDomain -Name Hyper-V -PropertyType String -Value "Microsoft Virtual Console Service/*" -Force New-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\Credssp\PolicyDefaults\AllowDefaultCredentials -Name Hyper-V -PropertyType String -Value "Microsoft Virtual Console Service/*" -Force New-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\Credssp\PolicyDefaults\AllowFreshCredentialsWhenNTLMOnlyDomain -Name Hyper-V -PropertyType String -Value "Microsoft Virtual Console Service/*" -Force ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\Credssp\PolicyDefaults\AllowDefaultCredentialsDomain -Name Hyper-V -PropertyType String -Value "Microsoft Virtual Console Service/*" -Force New-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\Credssp\PolicyDefaults\AllowFreshCredentials -Name Hyper-V -PropertyType String -Value "Microsoft Virtual Console Service/*" -Force New-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\Credssp\PolicyDefaults\AllowFreshCredentialsWhenNTLMOnly -Name Hyper-V -PropertyType String -Value "Microsoft Virtual Console Service/*" -Force New-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\Credssp\PolicyDefaults\AllowSavedCredentialsWhenNTLMOnly -Name Hyper-V -PropertyType String -Value "Microsoft Virtual Console Service/*" -Force New-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\Credssp\PolicyDefaults\AllowSavedCredentials -Name Hyper-V -PropertyType String -Value "Microsoft Virtual Console Service/*" -Force New-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\Credssp\PolicyDefaults\AllowSavedCredentialsDomain -Name Hyper-V -PropertyType String -Value "Microsoft Virtual Console Service/*" -Force

Теперь попробуйте снова подключиться. Подключение должно успешно установится.

Таким образом, с помощью RDCMan, вы можете удаленно подключаться к консоли любой виртуальной машины, работающей на хосте Hyper-V, независимо от гостевой ОС, будь то Window, Linux, MacOs или что-то еще.

Включение в Hyper V вложенной виртуализации

Вложенная виртуализация в Hyper V или Nested Virtualization доступна с редакций Windows Server 2016 и Windows 10. Грубо говоря это возможность виртуализировать Hyper V внутри Hyper V. Для настройки этой возможности нужно будет выполнить несколько команд Powershell. Кроме этого процессор должен быть Intel.

Установка ESXI на Hyper V, что тоже относится к вложенной виртуализации, у меня получалось, но ошибками и в конце концов я стал запускать Hyper V и ESXI поверх VMWare Workstation. Работать вместе Hyper V и VMWare Workstation тоже не могут. Опыт включения вложенной виртуализации для других платформ у меня отсутствует.

Первое с чем мы столкнемся при попытке включения или установки роли Hyper V во вложенном варианте это отсутствие возможности поставить галочку в GUI. Можно будет установить только консоль для управления. Эту ситуацию можно обойти установив Hyper V через Powershell, но и там мы встретим ошибку:

Не удалось запустить виртуальную машину так как не работает один из компонентов Hyper-V

Hyper-V cannot be installed: the processor does not have required virtualization capabilities

Первое что нужно сделать это выключить виртуальную машину. Я предпочитаю делать это через Powershell:


Stop-VM -Name 'Win10'
# или
Stop-Computer -ComputerName 'Win10'

Далее нам нужно включить расширение Hyper-V:


Set-VMProcessor -VMName 'Win10' -ExposeVirtualizationExtensions $true

Если у вас появится какая-то ошибка это может значить, что виртуальная машина была импортирована и имеет старую версию. В этом случае можно обновить виртуальную машину Hyper-V:


Update-VMVersion -Name 'Win10'

Для нормальной работы сети нам нужно включить MAC spoofing:


Get-VMNetworkAdapter -VMName 'Win10' | Set-VMNetworkAdapter -MacAddressSpoofing On

Либо через интерфейс:

Остальные ограничения связанные с Nested Virtualization, которые не получиться использовать:

Динамическая память

Изменение памяти работающей VM

Были проблемы с сетевыми адаптерами. При попытках настроить Docker на VM никак не работала сеть и в таких случаях помогала переустановка драйвера на сетевом адаптере основной ОС. Это происходило на Windows 10.

…

Теги:

#hyper-v

Как мигрировать одну VM на другой Hyper-V хост

Прочитано:
6 521

Что я хочу сделать:

У меня есть развернутая на одном хосте Hyper-V виртуальная машина и мне нужно переместить ее на другой хост Hyper-V, к примеру это могут быть домен контроллеры: srv-dc1 & srv-dc2

Технические условия:

srv-hyperv1 – Хост на базе Windows Server 2012 R2 Standard (RUS) имеющий в основании: Supermicro X9DR3-F, Intel Xeon ® CPU E5-2609 v2 2.50Ghz (2 процессора), RAM 128 Gb с поднятой ролью Hyper-V, диск под VM, Backup, в RAID 1 на 5Tb
srv-hyperv2 – Хоста на базе Windows Server 2012 R2 Standard (RUS) имеющий в основании: Supermicro X10Dri-T4+,Intel Xeon ® CPU E5-2630 2.20Ghz (2 процессора), RAM 128 Gb с поднятой ролью Hyper-V , диск под VM, Backup, в RAID 1 на 5Tb

Включаю на хостах (srv-hyperv[1,2]) с установленной ролью «Hyper-V» использование «Динамическая миграция»:

Win + R -> virtmgmt.msc (Диспетчер Hyper-V) — Диспетчер Hyper-V – «Подключиться к серверу» и указываю IP&DNS адрес текущей системы, затем выделяю добавленный хост и в правой части окна «Диспетчер Hyper-V» — «Параметры Hyper-V» — нахожу настройку «Динамическая миграция», отмечаю галочкой «Включить входящие и исходящие миграции», пусть пока одновременных динамических миграций будет две. Затем нажимаю на плюсик у настройки «Динамическая миграция» перехожу в «Дополнительные параметры» — и предопределяю параметры:

Использовать Kerberos: отмечаю галочкой
Параметры быстродействия: Сжатие

И нажимаю «Применить» — «ОК»

Что нужно проверить перед тем, как запустить перенос/миграция виртуальной машины с одного хоста Hyper-V на другой:

А) На хосте куда будет переносится VM нужно в предопределенном каталоге, где хранятся VM создать каталог по имени переносимой машины или по формату именования машин, которые вы используете.

Б) Выключить VM на хосте с которого будет ее переносить, а в свойствах виртуальной машины указать, что используется один виртуальный процессор дабы не было проблем и ошибок, к примеру: «на удаленном хосте не поддерживается CPU” и т.д.

Процесс переноса VM выглядит так:

На хосте с которого через оснастку «Диспетчер Hyper-V» переносится виртуальная машина нужно через правый клик мышью по VM выбрать «Переместить» — выбрать «Переместить виртуальную машину» , указываю имя конечного компьютера:

И нажимаю «Далее», тип перемещения выбирать «Переместить данные виртуальной машины в одно расположение» и нажимаю «Далее», указываю каталог на конечном компьютере:

Папка: Обзор – открывается проводник, где если обратить внимание на строку адреса указан удаленный путь до системы srv-hyperv1 (::{0907616E-F5E6-48D8-9D61-A91C3D28106D}\srv-hyperv1.polygon.local), выбираю логический диск и созданный каталог под виртуальную машину, получается: D:\w7x86 и нажимаем «Далее» — «Готово», в процессе переноса мастер сделает остановку («Не удалось найти коммутатор Ethernet “Eth2”») на именовании виртуального коммутатора на хосте Hyper-V, выбираю подходящий:

Подключение: “Нет подключения” – указываю используемый на хосте Hyper-V и нажимаю «Далее» — «Готово» и если все правило и доступно виртуальная машина произведет перемещение с одного хоста Hyper-V в другой хост Hyper-V.

Итак, виртуальная машина была успешно перемещена, возвращаю ей нужно количество виртуальных процессоров и и запускаю, кликнув по ней через правый клик мышью на элементе «Пуск»

[stextbox id=’alert’]На заметку: важно, чтобы хосты роли Hyper-V имели одинаковую версию развернутой роли Hyper-V и на всех были одинаково указаны параметры для «Динамической миграции», а также настройки виртуальных коммутаторов.[/stextbox]

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

Ошибка 0x80004005 в VirtualBox: 6 решений проблемы

При попытке запуска операционной системы Windows или Linux в виртуальной машине VirtualBox пользователь может столкнуться с ошибкой 0x80004005. Она возникает до старта ОС и препятствует любой попытке ее загрузки. Есть сразу несколько способов, помогающих устранить существующую проблему и продолжить пользоваться гостевой системой в обычном режиме.

Причины возникновения ошибки 0x80004005 в VirtualBox

Ситуаций, из-за которых не получается открыть сессию для виртуальной машины, может быть несколько. Зачастую данная ошибка возникает спонтанно: еще вчера вы спокойно работали в операционной системе на VirtualBox, а сегодня выполнить то же самое не удается из-за сбоя при запуске сессии. Но в некоторых случаях не удается выполнить первичный (установочный) запуск ОС.

Это может произойти вследствие одной из следующих причин:

Ошибка при сохранении последней сессии.
Отключенная поддержка виртуализации в BIOS.
Некорректно работающая версия VirtualBox.
Конфликт гипервизора (Hyper-V) с VirtualBox на 64-разрядных системах.
Проблемное обновление хостовой Windows.

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

Способ 1: Переименование внутренних файлов

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

Для выполнения дальнейших действий вам необходимо включить отображение расширений файлов. Это можно сделать через «Параметры папок» (в Windows 7) или «Параметры Проводника» (в Windows 10).

Откройте папку, где хранится файл, отвечающий за запуск операционной системы, т.е. сам образ. Он располагается в папке VirtualBox VMs, место сохранения которой вы выбирали при установке самой VirtualBox. Обычно она находится в корне диска (диска С или диска D, если HDD разбит на 2 раздела). Также она может располагаться в персональной папке пользователя по пути:
С:\Users\ИМЯ_ПОЛЬЗОВАТЕЛЯ\VirtualBox VMs\ИМЯ_ГОСТЕВОЙ_ОС
В папке с операционной системой, которую вы хотите запустить, должны быть следующие файлы: Name.vbox и Name.vbox-prev. Вместо Name будет имя вашей гостевой операционной системы.
Скопируйте файл Name.vbox в другое место, например, на рабочий стол.
Файл Name.vbox-prev необходимо переименовать вместо перемещенного файла Name.vbox, то есть удалить «-prev».
Эти же действия необходимо проделать и внутри другой папки, находящейся по следующему адресу:
C:\Users\ИМЯ_ПОЛЬЗОВАТЕЛЯ\.VirtualBox
Здесь вы будете менять файл VirtualBox.xml — скопируйте его в любое другое место.
У файла VirtualBox.xml-prev удалите приписку «–prev», чтобы получилось имя VirtualBox.xml.
Попробуйте запустить операционную систему. Если не сработало, восстановите все назад.

Способ 2: Включение поддержки виртуализации в BIOS

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

Чтобы осуществить запуск виртуальной машины, в БИОС достаточно включить всего лишь одну настройку, которая называется Intel Virtualization Technology.

В Award BIOS путь к этой настройке следующий: Advanced BIOS Features > Virtualization Technology (или просто Virtualization) > Enabled.
В AMI BIOS: Advanced > Intel(R) VT for Directed I/O > Enabled.
В ASUS UEFI: Advanced > Intel Virtualization Technology > Enabled.

Настройка может иметь и другой путь (например, в BIOS на ноутбуках HP или в БИОС Insyde h30 Setup Utility):

System Configuration > Virtualization Technology > Enabled;
Configuration > Intel Virtual Technology > Enabled;
Advanced > Virtualization > Enabled.

Если вы не нашли данной настройки в своей версии BIOS, то ищите ее вручную во всех пунктах меню по ключевым словам virtualization, virtual, VT. Для включения выбирайте состояние Enabled.

Способ 3: Обновление VirtualBox

Возможно, состоялось очередное обновление программы до последней версии, после чего и появилась ошибка запуска «E_FAIL 0x80004005». Есть два выхода из сложившейся ситуации:

Дождитесь выхода стабильной версии VirtualBox.
Те, кто не хочет заморачиваться с выбором рабочей версии программы, может просто дождаться обновления. Узнать о выходе новой версии можно на официальном сайте VirtualBox или через интерфейс программы:
1. Запустите Менеджер виртуальных машин.
2. Нажмите «Файл» > «Проверить обновления…».
3. Дождитесь проверки и при необходимости установите обновление.

Переустановите VirtualBox на текущую или предыдущую версию.

Если у вас есть установочный файл VirtualBox, то используйте его для переустановки. Для повторного скачивания актуальной или предыдущей версии перейдите по этой ссылке.
Нажмите на ссылку, ведущую к странице со списком всех предыдущих релизов для текущей версии VirtualBox.
Выберите подходящую для хостовой ОС сборку и скачайте ее.
Для переустановки установленной версии VirtualBox: запустите инсталлятор и в окне с типом установки выберите «Repair». Установите программу в обычном режиме.
Если вы делаете откат до предыдущей версии, то лучше сперва удалить VirtualBox через «Установку и удаление программ» в Windows.
Или через установщик VirtualBox.
Не забудьте сделать резервные копии своих папок с образами ОС.

Способ 4: Отключение Hyper-V

Hyper-V — система виртуализации для 64-разрядных систем. Иногда у нее может возникнуть конфликт с VirtualBox, что и провоцирует появление ошибки при старте сессии для виртуальной машины.

Для отключения гипервизора выполните следующее:

Запустите «Панель управления».
Включите просмотр по значкам. Выберите пункт «Программы и компоненты».
В левой части окна нажмите на ссылку «Включение или отключение компонентов Windows».
В открывшемся окне необходимо снять галочку с компонента Hyper-V, а затем нажать «ОК».
Перезагрузите компьютер (необязательно) и попробуйте запустить ОС в VirtualBox.

Способ 5: Изменение типа запуска гостевой ОС

В качестве временного решения (например, до выпуска новой версии VirtualBox) можно попробовать изменить тип запуска ОС. Этот способ помогает не во всех случаях, но, возможно, сработает у вас.

Запустите Менеджер VirtualBox.
Нажмите по проблемной операционной системе правой кнопкой мыши, наведите курсор на пункт «Запустить» и выберите вариант «Запуск в фоновом режиме с интерфейсом».

Данная функция доступна только в VirtualBox, начиная с версии 5.0.

Способ 6: Удаление/исправление обновления Windows 7

Этот способ считается устаревшим, поскольку после неудачного патча KB3004394, приводящего к прекращению работы виртуальных машин в ВиртуалБокс, была выпущена заплатка KB3024777, устраняющая данную проблему.

Тем не менее, если у вас на компьютере по каким-то причинам отсутствует фикс-патч, а проблемный присутствует, то есть смысл либо удалить KB3004394, либо установить KB3024777.

Удаление KB3004394:

Откройте «Командную строку» с правами администратора. Для этого откройте окно «Пуск», напишите cmd, правым кликом мыши выберите пункт «Запустить от имени администратора».
Пропишите команду
wusa /uninstall /kb:3004394
и нажмите Enter.
После выполнения этого действия может потребоваться перезагрузка компьютера.
Попробуйте еще раз запустить гостевую ОС в ВиртуалБоксе.

Установка KB3024777:

Перейдите по этой ссылке на сайт Microsoft.
Скачайте версию файла с учетом разрядности своей ОС.
Установите файл вручную, если необходимо, перезагрузите ПК.
Проверьте запуск виртуальной машины в VirtualBox.

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

Мы рады, что смогли помочь Вам в решении проблемы.

Опишите, что у вас не получилось.
Наши специалисты постараются ответить максимально быстро.

Помогла ли вам эта стат

Hyper v локальная сеть — Вэб-шпаргалка для интернет предпринимателей!

Технический блог специалистов ООО»Интерфейс»

Главная
Настраиваем сеть в Hyper-V.

Настраиваем сеть в Hyper-V.

Автор: Уваров А.С.
21.01.2014

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

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

За настройку сетей в Hyper-V отвечает Диспетчер виртуальных коммутаторов, если мы откроем его, то увидим следующую картину:

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

Внешняя сеть

Самый распространенный тип сети, который позволяет виртуальным машинам взаимодействовать с внешними сетями и хостом. При ее создании необходимо выбрать один из физических сетевых адаптеров, через который данная виртуальная сеть будет соединяться с внешними сетями.

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

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

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

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

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

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

Внутренняя сеть

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

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

Внутренняя сеть c NAT

Данная возможность появилась начиная с Windows Server 2016, Hyper-V Server 2016 и Windows 10. Подробнее читайте в нашей статье: Настраиваем сеть NAT в Hyper-V

Частная сеть

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

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

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

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

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

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

Архитектура Hyper-V

«Виртуальные сети» (сокращенно: «ВС») в Hyper-V называют виртуальными коммутаторами, к которым подключаются не только сетевые интерфейсы ВМ, но и физические сетевые интерфейсы сервера.

Существуют 3 вида «ВС». Схематично они представлены на рисунке ниже.

Майкрософт сравнительно недавно предусмотрела в «Windows Server 2008 R2» создание ВС «External» с изоляцией от хостовой системы. Осуществляется процесс просто. Следует убрать отметку из графы «Allow management operating system to share this network adapter».

При этом отключаются все ранее созданные подключения, и параметры прописываются для новой ВМ.

Необходимо отметить, что в Hyper-V имеется поддержка VLAN (IEEE 802.1Q).

После настройки коммутаторов, достаточно в свойствах ВМ установить отметку «Enable VLAN Identification» и указать VLAN ID.

Приятной новинкой, внедренной специалистами из Майкрософт в Виндовс Server 2008 R2, является поддержка виртуальных очередей VMQ.

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

Процедура настройки

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

Многие хорошо знакомы с работой на «Виртуал Сервер» или «Microsoft’s Virtual PC» и привыкли к тому, что они функционируют как простые программы Виндовс.

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

Это обстоятельство накладывает некоторые нюансы на процедуру настройки доступа к сети ВМ Hyper-V из сетей.

Рассмотрим процесс на конкретном примере со следующими сетевыми параметрами: главный IP-адрес: ___.189.53.206/30; доп.адрес: ___.91.26.173/32; сервер с 2-мя интерфейсами (при этом задействован лишь 1-ый, а 2-ой отключен).

Далее всю процедуру исполняем только с LAN1.

Теперь можно приступить к настройке 2-х ВМ:

1-ая ВМ получит связь с внешним миром через сетевую карту с доступом во всемирную патину, а 2-ая послужит как коммутатор корневого сервера с виртуальным хостом.

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

Установить отметки, как показано на скриншоте выше для создания 1-ой ВМ. Далее создать 2-ую, как изображено на рисунке ниже.

Подготовительные мероприятия на этом этапе завершены, но перед тем как настраивать сети, следует убедиться, что все исполнено корректно. От этого зависит успешность процедуры в целом.

Важное отступление: Во время создания 1-го ВМ будут разорваны все подключения, поэтому рекомендуется предусмотреть дополнительное соединение с сервером, например, IPMI, IP-KVM либо прямой физический доступ.

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

В параметрах коммутатора (2-ой ВМ) указать IP-адрес. В результате этот ВМ на физическом сервере станет работать как шлюз.

Уже можно констатировать приятный факт, что ввод параметров сетевых интерфейсов на корневом сервере окончен.

Затем надо произвести настройки «RRAS», чтобы обеспечить перенаправление трафика к ВМ и обратно. С этой целью в меню «Диспетчера сервера» потребуется присвоить роль для «Службы политики сети и доступа».

По умолчанию она «Остановлена» и следует ее настроить.

Отобразится мастер, указания которого требуется пошагово исполнить.

Установить отметку в графу «Особая конфигурация».

Поставить галочки в два поля, как сделано на иллюстрации выше.

Клацнуть «Готово».

Кликнуть «Запустить службу». Далее проверить корректность выполненной работы через меню диспетчера.

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

Клацнуть строчку «Новый интерфейс» и применить внешний интерфейс.

Войти в закладку «Преобразование сетевых адресов (NAT)» и поставить галочки в графах, указанных на следующем скриншоте:

Перейти в закладку «Пул адресов» и указать доп. адреса. От них запросы станут поступать на внутренние адреса ВМ.

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

В свойствах ввести параметры сети где расположен шлюз.

В результате ВМ получила выход во всемирную паутину. Чтобы удостовериться в этом, достаточно заглянуть в меню «Центра управления сетями и общим доступом».

Примечание: Если соединение с глобалкой отсутствует, то проблема быстро решается простым изменением параметров Брадмауэра на серверах.

Еще убедиться в правильности можно через любой интернет-сервис.

Задуманное успешно реализовано на практике, вот так просто можно применять несколько различных сетей на единственном реальном сервере, то есть физическом (сколько их пожелает создать администратор, столько же создается и коммутаторов).

А если требуется настроить сети на Линуксе, которая запущена под Hyper-V?

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

Сложность может быть устранена следующей «уловкой»: в Параметрах ВМ указать одну из «древних» сетевых карт. ОС такую картуувидит сразу, то есть возникшая сложность устраниться быстро.

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

Заключение

Отдельные пользователи пренебрегают этапом настроек по «Преобразованию сетевых адресов (NAT)», который описан в инструкции выше. Однако этот механизм обеспечивает доступ ВМ к сети через объединение IP основной электронно-вычислительной машины с портом через внутренний коммутатор Hyper-V. В итоге приобретаются несколько следующих преимуществ:

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

Виртуальные локальные сети (VLANs @ no__t-1 предлагают один из способов изоляции сетевого трафика. Virtual local area networks (VLANs) offer one way to isolate network traffic. Виртуальные ЛС настраиваются в коммутаторах и маршрутизаторах, поддерживающих 802.1 q. VLANs are configured in switches and routers that support 802.1q. Если вы настроили несколько виртуальных ЛС и хотите, чтобы между ними происходил обмен данными, необходимо настроить сетевые устройства, чтобы это разрешить. If you configure multiple VLANs and want communication to occur between them, you’ll need to configure the network devices to allow that.

Для настройки виртуальных ЛС потребуется следующее: You will need the following to configure VLANs:

Физический сетевой адаптер и драйвер, поддерживающие маркировку VLAN 802.1 q. A physical network adapter and driver that supports 802.1q VLAN tagging.
Физический сетевой коммутатор, поддерживающий маркировку VLAN 802.1 q. A physical network switch that supports 802.1q VLAN tagging.

На узле вы настроите виртуальный коммутатор, чтобы разрешить сетевой трафик на порте физического коммутатора. On the host, you’ll configure the virtual switch to allow network traffic on the physical switch port. Это для идентификаторов виртуальных ЛС, которые вы хотите использовать для внутренних целей с виртуальными машинами. This is for the VLAN IDs that you want to use internally with virtual machines. Затем настройте виртуальную машину, чтобы указать виртуальную ЛС, которую виртуальная машина будет использовать для всех сетевых подключений. Next, you configure the virtual machine to specify the VLAN that the virtual machine will use for all network communications.

Чтобы разрешить виртуальному коммутатору использовать виртуальную ЛС To allow a virtual switch to use a VLAN

Откройте Hyper @ no__t-0V Manager. Open Hyper-V Manager.

В меню действия выберите Диспетчер виртуальных коммутаторов. From the Actions menu, click Virtual Switch Manager.

В разделе виртуальные коммутаторывыберите виртуальный коммутатор, подключенный к физическому сетевому адаптеру, который поддерживает виртуальные ЛС. Under Virtual Switches, select a virtual switch connected to a physical network adapter that supports VLANs.

В области справа в разделе идентификатор виртуальной ЛС выберите включить идентификацию виртуальной локальной сети , а затем введите номер виртуальной ЛС. In the right pane, under VLAN ID, select Enable virtual LAN identification and then type a number for the VLAN ID.

Весь трафик, проходящий через физический сетевой адаптер, подключенный к виртуальному коммутатору, будет помечен заданным ИДЕНТИФИКАТОРом виртуальной ЛС. All traffic that goes through the physical network adapter connected to the virtual switch will be tagged with the VLAN ID you set.

Чтобы разрешить виртуальной машине использовать виртуальную ЛС To allow a virtual machine to use a VLAN

Откройте Hyper @ no__t-0V Manager. Open Hyper-V Manager.

В области результатов в разделе виртуальные машинывыберите соответствующую виртуальную машину, а затем щелкните правой кнопкой мыши Параметры. In the results pane, under Virtual Machines, select the appropriate virtual machine and then right-click Settings.

В разделе оборудованиевыберите виртуальный коммутатор, для которого настроена виртуальная ЛС. Under Hardware, select an virtual switch that’s set up with a VLAN.

В области справа выберите включить идентификацию виртуальной локальной сети, а затем введите тот же идентификатор виртуальной ЛС, который указан для виртуального коммутатора. In the right pane, select Enable virtual LAN identification, and then type the same VLAN ID as the one you specified for the virtual switch.

Если виртуальная машина должна использовать больше виртуальных ЛС, выполните одно из следующих действий. If the virtual machine needs to use more VLANs, do one of the following:

Подключите другие виртуальные сетевые адаптеры к соответствующим виртуальным коммутаторам и назначьте идентификаторы виртуальных ЛС. Connect more virtual network adapters to appropriate virtual switches and assign the VLAN IDs. Убедитесь, что правильно настроены IP-адреса и что трафик, который нужно маршрутизировать через виртуальную ЛС, также использует правильный IP-адрес. Make sure to configure the IP addresses correctly and that the traffic you want to route through the VLAN also uses the correct IP address.

Настройте адаптер Word виртуальной сети в режиме магистрали с помощью команды Set @ no__t-1VMNetworkAdapterVlan командлет. Configure the virtual network word adapter in trunk mode using the Set-VMNetworkAdapterVlan cmdlt.

Настройка виртуальных сетей в Hyper-V

Если вы уже работали с Microsoft’s Virtual PC или Virtual Server, то вы знаете что эти продукты работают как обычные приложения Windows. Они находятся поверх родительской операционной системы (host operating system) и все запросы от виртуальных машин к оборудованию сервера происходят через родительскую операционную систему, которая уже непосредственно управляет оборудованием сервера. В Hyper-V реализован совершенно другой подход к виртуализации и в частности к сетевым коммуникациям, нежели во всех предыдущих продуктах. Эта статья рассказывает о том, как работает сетевое взаимодействие в Hyper-V.

Действительно, Hyper-V отделяет от остальных продуктов виртуализации Microsoft то, что теперь виртуальные машины получили непосредственный доступ к оборудованию сервера, а не через родительскую систему. Однако возникала проблема перегрузки сетевого адаптера (NIC) одновременными пакетами от разных виртуальных машин. Нужно было решение данного вопроса и Microsoft представила концепцию «виртуальных коммутаторов» (virtual switch).

Для того что бы понять как это возможно, представьте что Hyper-V это не дополнение к Windows Server 2008, а скорее часть операционной системы. Когда вы устанавливаете роль Hyper-V, гипервизор встает как бы «прослойка» между оборудованием и операционной системой Windows 2008. Система в которой поднимается роль Hyper-V называют родительской (host operating system) и располагается она на родительском разделе (parent partition). Операционные системы виртуальных машин называют гостевыми (guest operating system) и располагаются они на отдельных дочерних разделах (child partition).

Для того чтобы сделать такую архитектуру возможной, Microsoft отвязал стек протоколов TCP/IP от серверного сетевого адаптера (NIC). Сделав это, они создали дополнительный уровень абстракции, названный — «виртуальный коммутатор» (virtual switch). В итоге «виртуальный коммутатор» (virtual switch) единственный сетевой компонент привязанный к физическому сетевому адаптеру сервера (NIC). Родительская и дочерние операционные системы используют виртуальные сетевые адаптеры (vNIC’s)? которые соединяются с «виртуальным коммутатором» (virtual switch) используя протокол — Microsoft’s Virtual Network Switch Protocol.

Возможно это довольно сложно понять, но в помощь привожу наглядную логическую схему взаимодействия. Рис. 1

Hyper-V позволяет создавать дополнительные «виртуальные коммутаторы» (virtual switch) помимо того о котором я только что рассказал. Для этого с права в консоли управления Hyper-V (Hyper-V Manager) зайдите в раздел Управление виртуальными сетями (Virtual Network Manager). Вы увидите окно Управления виртуальными сетями (Virtual Network Manager). Рис. 2.

Если вы посмотрите на Рис. 1, вы увидите что «виртуальный коммутатор» (virtual switch) привязан к моему физическому сетевому адаптеру (NIC). У вас есть возможность создать новую виртуальную сеть, для этого вам и нужно будет создать новый «виртуальный коммутатор» (virtual switch). Как видите, (Рис. 2) существуют три разных типа виртуальных сетей, которыми вы можете пользоваться.

Первый тип — «внешняя» (external) — универсальный тип, который можно использовать для связи между виртуальными машинами на том же физическом сервере, включая родительский раздел, а также внешними серверами и Internet.

Есть важный момент, который вы должны учитывать при создании «внешней виртуальной сети» (external virtual networks), она должна быть привязана к физическому сетевому адаптеру (NIC). Вдобавок, каждый физический сетевой адаптер (NIC) может быть привязан только к одной виртуальной сети. Таким образом, если вы создаете вторую «внешнюю виртуальную сеть» (external virtual networks), то вам нужен и второй физический сетевой адаптер (NIC), который вы привяжете к ней.

Второй тип — «внутренняя» (internal) — используется как механизм связи между виртуальными машинами располагающимися на одном сервере. Так же внутренняя виртуальная сеть (internal virtual network) позволяет соединяться этим виртуальным машинам с родительской операционной системой.

Третий тип — «частная» (private) — используется как механизм связи только между виртуальными машинами располагающимися на одном сервере. Частная виртуальная сеть (private virtual network) не позволяет соединения во вне, а так же соединения к родительской операционной системе.

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

Если возникли какие либо вопросы, с удовольствием постараюсь на них ответить.

Устранение неполадок Hyper-V 5 общих проблем

ВВЕДЕНИЕ

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

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

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

ПРОБЛЕМЫ, СВЯЗАННЫЕ С ХРАНЕНИЕМ

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

Низкая производительность хранилища

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

Архитектура хранилища

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

Первое, что следует проверить, — это размещение компонентов виртуальной машины. Компоненты виртуальных машин должны находиться в выделенном хранилище, где им не придется конкурировать с операционной системой за операции ввода-вывода хранилища. Microsoft рекомендует структурировать этот том как RAID 1 + 0 (иногда называемый RAID 10). RAID 1 + 0 обеспечивает производительность чередования с избыточностью зеркалирования. Хотя некоторые организации используют тома RAID 5 или RAID 6, RAID 5 и 6 — плохой выбор для виртуальных машин с интенсивной записью из-за накладных расходов, связанных с записью данных четности.

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

Тип виртуального жесткого диска

Microsoft также рекомендует использовать виртуальные жесткие диски на основе VHDX, а виртуальные жесткие диски в формате VHD должны быть преобразованы в VHDX (https: // blogs.technet.microsoft.com/ askpfeplat / 2013/03/10 / windows-server-2012-hyper-v-best-practice-in-easy-checklist-form /). Microsoft также рекомендует использовать виртуальные жесткие диски фиксированной длины (которые иногда называют виртуальными жесткими дисками фиксированного размера) в отличие от динамически расширяемых виртуальных жестких дисков (https://technet.microsoft.com/en-us/library/ mt589658.aspx).

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

Если вы создадите виртуальный жесткий диск на 100 ГБ, то объем физического дискового пространства, который будет первоначально использован, будет определяться типом виртуального жесткого диска, который был создан.Виртуальный жесткий диск фиксированной длины потребует сразу все 100 ГБ пространства. Динамически расширяющийся виртуальный жесткий диск может в конечном итоге занять 100 ГБ пространства, если диск заполнен до предела, но первоначально он будет занимать только 4 МБ пространства.

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

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

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

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

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

Откройте диспетчер Hyper-V.
Щелкните правой кнопкой мыши виртуальную машину, которую вы хотите проверить, и выберите команду «Настройки» из контекстного меню.
Выберите виртуальный жесткий диск в списке оборудования, как показано на рисунке 1.
Нажмите кнопку «Проверить».
Проверьте список Тип в диалоговом окне Свойства виртуального жесткого диска, как показано на рисунке 2.

Рисунок 1 | Выберите виртуальный жесткий диск, который вы хотите проверить.

Рисунок 2 | В диалоговом окне «Свойства виртуального жесткого диска» указан тип виртуального жесткого диска.

Если вы предпочитаете использовать PowerShell, вы можете сделать это с помощью командлета Get-VHD. Единственный параметр, который вам нужно будет указать, — это Путь. Однако может быть полезно добавить командлет Select-Object в качестве способа фильтрации выходных данных, чтобы командлет отображал только интересующую вас информацию. Например, следующая команда отображает путь к виртуальному жесткому диску, формат, и введите:

Get-VHD –Path <путь и имя файла виртуального жесткого диска> | Select-Object Path, VhdFormat, VhdType

Вы можете увидеть, как эта команда выглядит в действии на рисунке 3.

Рисунок 3 | Командлет Get-VHD можно использовать для получения информации о виртуальном жестком диске.

Преобразование виртуального жесткого диска

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

В диспетчере Hyper-V, правильно щелкните виртуальную машину, чей виртуальный жесткий диск вы хотите преобразовать, и выберите команду «Настройки» в контекстном меню.Это заставит Windows отобразить диалоговое окно Параметры для виртуальной машины.
Щелкните виртуальный жесткий диск, который вы хотите преобразовать, и щелкните кнопку Edit, показанную на рисунке 4. Это заставит Windows запустить мастер редактирования виртуального жесткого диска.

Рисунок 4 | Щелкните виртуальный жесткий диск, а затем нажмите кнопку «Изменить».

Нажмите «Далее», чтобы пропустить экран мастера «Найти виртуальный жесткий диск».
Когда вы дойдете до экрана мастера «Выбрать действие», выберите опцию «Преобразовать» и нажмите «Далее».
Выберите VHDX в качестве формата диска, если у вас нет веских причин использовать формат VHD. Щелкните Далее, чтобы продолжить.
Выберите параметр «Фиксированный размер», показанный на рисунке 5, на экране мастера преобразования виртуального жесткого диска и нажмите «Далее».

Рисунок 5 | Выберите параметр «Фиксированный размер» и нажмите «Далее».

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

ПРИМЕЧАНИЕ. Hyper-V фактически не преобразует виртуальный жесткий диск в новый формат, а создает совершенно новый виртуальный жесткий диск.Таким образом, вам нужно будет указать имя виртуального жесткого диска, которое отличается от имени, которое использовалось изначально. Обязательно обратите внимание на путь, потому что Hyper-V по умолчанию попытается разместить виртуальный жесткий диск на системном диске сервера. Также стоит отметить, что вам потребуется достаточный объем свободного физического дискового пространства для размещения обеих копий виртуального жесткого диска.

Нажмите Далее.
Нажмите Готово.
После завершения преобразования виртуального жесткого диска вы вернетесь в диалоговое окно «Настройки».Виртуальная машина по-прежнему будет использовать исходный виртуальный жесткий диск, поэтому вам придется вручную настроить виртуальную машину для использования нового виртуального жесткого диска.
Вы можете переключиться на новый виртуальный жесткий диск, нажав кнопку «Обзор», выбрав виртуальный жесткий диск, который вы хотите использовать, и нажав «Открыть».
Нажмите ОК, чтобы завершить процесс.
Включите виртуальную машину и убедитесь, что она работает нормально. Когда вы закончите тестирование виртуальной машины, не забудьте удалить старый виртуальный жесткий диск.

ПРИМЕЧАНИЕ. Рекомендуется выключить виртуальную машину, прежде чем пытаться выполнить этот процесс.

При желании вы можете использовать Windows PowerShell для преобразования динамически расширяемого виртуального жесткого диска в виртуальный жесткий диск фиксированной длины. Для этого вам необходимо знать путь и имя файла, используемые исходным виртуальным жестким диском. Вам также необходимо будет указать путь и имя файла для нового виртуального жесткого диска. Для преобразования виртуального жесткого диска используется командлет Convert-VHD.Синтаксис:

Convert-VHD –Path <путь и имя файла виртуального жесткого диска, который нужно заменить> -DestinationPath <путь и имя файла нового виртуального жесткого диска> -VHDType Fixed

Вы можете увидеть пример такого преобразование на рисунке 6.

Рисунок 6 | Вы можете использовать командлет Convert-VHD для преобразования виртуального жесткого диска.

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

Этот процесс требует, чтобы вы знали тип контроллера виртуального жесткого диска, номер контроллера и расположение контроллера, поэтому вам придется искать эту информацию как часть процесса. При этом используются следующие команды:

Stop-VM –Name <имя виртуальной машины>
Convert-VHD –Path <путь и имя файла виртуального жесткого диска, который необходимо заменить> -DestinationPath <путь и имя файла нового виртуального жесткого диска disk> -VHDType Fixed
Get-VMHardDiskDrive –VMName <имя виртуальной машины>
Remove-VMHardDiskDrive -VMName <имя виртуальной машины> –ControllerType -ControllerNumber <номер контроллера диска> -ControllerLocation <расположение виртуальных жестких дисков на контроллер>
Get-VMHardDiskDrive –VMName <имя виртуальной машины>
ADD-VMHardDiskDrive -VMName <имя виртуальной машины> -Path <путь и имя файла виртуального жесткого диска>
Get-VMHardDiskDrive –VMName <имя виртуальной машины>

Вы можете увидеть весь процесс в действии на рисунке 7:

Рисунок 7 | Вы можете использовать PowerShell для преобразования и замены виртуального жесткого диска.

Контрольные точки

Наличие контрольных точек также влияет на производительность виртуального жесткого диска. Кроме того, Microsoft не рекомендует использовать контрольные точки в производственной среде до выпуска Windows Server 2016, в котором будет реализована функция производственной контрольной точки. Причина этого в том, что до выпуска Windows Server 2016 функция контрольной точки Hyper-V (или функция моментальных снимков, как она была известна в Windows Server 2008 и 2008 R2) не поддерживала работу приложений.Таким образом, создание и последующее применение контрольной точки на сервере приложений могло вызвать повреждение или потерю данных. Функция производственной контрольной точки Windows Server 2016 будет использовать службы теневого копирования томов (VSS) как часть процесса контрольной точки, чтобы гарантировать, что приложения, поддерживающие VSS, могут безопасно проверяться. VSS — это тот же механизм, который используют приложения резервного копирования для безопасного резервного копирования серверов приложений Microsoft.

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

Откройте диспетчер Hyper-V.
Выберите виртуальную машину, чьи контрольные точки вы хотите удалить.
Щелкните правой кнопкой мыши контрольную точку, которую вы собираетесь удалить.
Выберите команду «Удалить контрольную точку» или «Удалить поддерево контрольной точки» из контекстного меню, как показано на рисунке 8.

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

Также можно удалить нежелательную контрольную точку виртуальной машины с помощью PowerShell.Для этого вам нужно будет использовать командлет Remove-VMSnapshot. До выпуска Windows Server 2012 контрольные точки назывались снимками, отсюда и ссылка на снимки в командлете.

Если вы не знаете имя контрольной точки, которую хотите удалить, вам нужно будет получить список контрольных точек с сервера. Вы можете выполнить эту задачу, используя командлет GetVMSnapshot и используя переключатель –VMName, чтобы указать имя виртуальной машины, которую вы хотите проверить.Для получения списка контрольных точек и последующего удаления конкретной контрольной точки используются следующие команды:

Get-VMSnapshot –VMName <имя виртуальной машины>
Get-VMSnapshot –VMName <имя виртуальной машины> –Name <имя контрольной точки> | Remove-VMSnapshot
Get-VMSnapshot –VMName <имя виртуальной машины>

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

Рисунок 9 | Для удаления контрольной точки можно использовать PowerShell.

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

iSCSI Multi-Path не работает должным образом

iSCSI Storage — популярный выбор для предприятий малого и среднего бизнеса, которые хотят создать общий том кластера без затрат или сложностей Fibre Channel.Хотя процесс настройки iSCSI имеет тенденцию быть относительно простым, есть несколько распространенных ошибок, которые могут привести к неправильной работе iSCSI multipath.

Microsoft Multi-Path I / O

Операционная система Windows Server имеет встроенную поддержку многопутевого ввода-вывода для обеспечения высокой доступности. Многопутевый ввод-вывод работает путем включения нескольких подключений (сеансов) к массиву хранения. Это позволяет каждому узлу отказоустойчивого кластера Windows иметь собственное подключение к оборудованию хранения, на котором размещен общий том кластера.Таким образом, каждый узел в кластере имеет доступ к одним и тем же ресурсам хранения.

Хотя в этой книге многопутевый ввод-вывод рассматривается с точки зрения iSCSI, важно понимать, что многопутевый ввод-вывод не является уникальным для iSCSI. Реализация многопутевого ввода-вывода Microsoft поддерживает использование iSCSI, Fibre Channel и Serial Attached Storage (SAS).

Функция многопутевого ввода-вывода Microsoft использует модуль для конкретного устройства (DSM), чтобы обеспечить поддержку массивов хранения, которые изначально поддерживают модель доступа к асимметричным логическим модулям (ALUA), как определено в SPC-3.Также поддерживаются аппаратные массивы, соответствующие модели контроллера Active / Active. Функция многопутевого ввода-вывода Microsoft также позволяет выполнять аппаратно-независимый многопутевый ввод-вывод на уровне iSCSI.

Проверка многопутевого ввода-вывода

Первым шагом в устранении любой проблемы, связанной с многопутевым вводом-выводом, является проверка того, что на сервере включен многопутевой ввод-вывод. Самый простой способ добиться этого — использовать Windows PowerShell. Для этого откройте окно PowerShell с повышенными привилегиями и введите следующую команду:

Get-WindowsFeature –Name ‘Multipath-IO’

Как вы можете видеть на рисунке 10, эта команда покажет вам состояние установки для MultiPath I. / O особенность.

Рисунок 10 | Вы можете использовать командлет Get-WindowsFeature, чтобы проверить, установлена ли функция многопутевого ввода-вывода.

Если вы определили, что функция Multi-Path I / O не установлена, вы можете легко установить ее из PowerShell. Имейте в виду, что функция многопутевого ввода-вывода должна быть установлена на каждом сервере, которому потребуется многопутевый доступ к массиву хранения. Для установки функции многопутевого ввода-вывода используется следующая команда:

Enable-WindowsOptionalFeature –Online –FeatureName MultiPathIO

На рисунке 11 показан этот процесс.

Рисунок 11 | Вы можете использовать PowerShell для включения многопутевого ввода-вывода

Панель управления многопутевым вводом-выводом

Установка функции многопутевого ввода-вывода приводит к установке модуля Microsoft Device Specific Module (DSM). Кроме того, Windows также устанавливает панель управления MPIO, которая позволяет администраторам настраивать функции MPIO, создавать отчеты о конфигурации MPIO и устанавливать дополнительные DSM (для поддержки дополнительных продуктов хранения). Вы можете получить доступ к панели управления MPIO, перейдя через панель управления Windows в раздел Система и безопасность \ Администрирование \ MPIO.

ПРИМЕЧАНИЕ. В среде Server Core вы можете запустить панель управления MPIO, выполнив команду MPIOCPL.EXE.

Панель управления MPIO, которую вы видите на рис. 12, разделена на четыре вкладки — «Устройства MPIO», «Обнаружение нескольких путей», «Установка DSM» и «Снимок конфигурации».

Рисунок 12 | Это панель управления MPIO.

Вкладка MPIO Devices позволяет администраторам добавлять поддержку для новых устройств хранения. Просто нажмите кнопку «Добавить» и введите идентификаторы поставщика и продукта.Идентификатор поставщика представляет собой строку из восьми символов, а идентификатор продукта — строку из шестнадцати символов. Если вам нужно добавить несколько устройств, вы можете сделать это, разделив их точкой с запятой.

Вкладка Discover Multi-Paths может использоваться для добавления идентификаторов устройств Fibre Channel, использующих Microsoft DSM. Эта вкладка также может использоваться для определения того, действительно ли несколько экземпляров указывают на общий номер логического устройства (LUN).

Вкладка DSM Install используется для добавления поддержки устройств хранения, которые не поддерживают архитектуру MPIO.Большинство массивов, совместимых с SPC-3, будут работать с DSM, предоставляемым Microsoft, но некоторые поставщики оборудования предоставляют свои собственные DSM. Вы можете добавить сторонний DSM, используя кнопку «Обзор», чтобы найти соответствующий файл .INF, а затем нажав кнопку «Установить».

Вкладка «Снимок конфигурации» существует в первую очередь для устранения неполадок. Используя эту вкладку, администраторы могут сохранить конфигурацию MPIO в текстовый файл для просмотра. Вы можете увидеть эту вкладку и снимок конфигурации (взятый из системы без подключенного хранилища) на рисунке 13.

Рисунок 13 | На вкладке Configuration Snapshot создается отчет с подробным описанием зарегистрированных DSM, устройств и политик балансировки нагрузки.

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

Проблемы конфигурации iSCSI Multipath

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

Как отмечалось ранее, шаги настройки iSCSI различаются в зависимости от используемого решения поставщика. Предполагая, что вы используете инициатор iSCSI Windows Server 2012 R2 и цель iSCSI, вы можете проверить разрешения, необходимые для работы с несколькими путями, выполнив следующие действия:

Откройте окно инициатора iSCSI и выберите вкладку Конфигурация.
Задокументируйте имя инициатора, как показано на рисунке 14.
Повторите шаги 1 и 2 для каждого узла, который будет подключаться к цели iSCSI

Рисунок 14 | Задокументируйте имя каждого имитатора iSCSI.

Откройте диспетчер сервера и щелкните контейнер файловых служб и служб хранения.
Щелкните контейнер iSCSI.
Запишите IQN цели, чтобы вы могли подключиться к ней.
Щелкните правой кнопкой мыши цель iSCSI и выберите в контекстном меню команду «Свойства».
Выберите контейнер «Инициаторы».
Добавьте IQN для каждого инициатора iSCSI, который будет подключаться к цели, как показано на рисунке 15. Каждый узел кластера должен иметь свой собственный инициатор.

Рисунок 15 | Каждый инициатор должен иметь разрешение на подключение к цели.

Щелкните вкладку «Безопасность» и проверьте, включен ли протокол CHAP. В таком случае вам необходимо знать имя пользователя и пароль CHAP.
Откройте инициатор iSCSI на одном из узлов кластера.
Если используется протокол CHAP, перейдите на вкладку конфигурации инициатора, нажмите кнопку CHAP и введите учетные данные CHAP (также известные как секрет CHAP).
Перейдите на вкладку «Обнаружение».
Нажмите кнопку «Обнаружить портал».
Введите имя хоста DNS или IP-адрес сервера, который действует как цель iSCSI.
Убедитесь, что номер порта установлен на 3260 и что этот порт открыт на вашем брандмауэре.
Нажмите ОК.
Перейдите на вкладку Цели инициатора.
Убедитесь, что ваша цель iSCSI указана среди обнаруженных целей.
Выберите цель iSCSI и нажмите «Подключиться».
Когда Windows отобразит диалоговое окно «Подключиться к цели», установите флажок «Включить многопутевый режим», как показано на рисунке 16.
Нажмите «ОК».
Повторите шаги с 11 по 22 для каждого оставшегося узла кластера.

Рисунок 16 | Вы должны установить флажок Enable Multi Path.

Ужасно медленное копирование файлов

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

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

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

Проверьте отсутствие исправлений

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

VMQ необходимо отключить

Другой распространенной причиной чрезвычайно медленного копирования файлов является неправильно настроенный сетевой адаптер. В некоторых ситуациях очередь виртуальных машин (VMQ) может быть включена по умолчанию. Когда функция VMQ включена, Hyper-V создает выделенную очередь на физическом сетевом адаптере для каждого виртуального сетевого адаптера, который запрашивает очередь (https: // technet. Microsoft.com/en-us/library/gg162704(v=ws .10) .aspx).

По данным Microsoft (https: // technet.microsoft.com/en-us/library/gg162704(v=ws.10).aspx), очереди виртуальных машин должны быть включены только для виртуальных машин, которые испытывают большие объемы входящего трафика. Что еще более важно, Microsoft рекомендует отключить VMQ для сетевых адаптеров Ethernet 1 гигабит. Сетевые карты Gigabit Ethernet не могут получить каких-либо существенных преимуществ от VMQ, и использование VMQ на таких сетевых адаптерах иногда вызывает проблемы с производительностью и доступностью (https://www.petri.com/hyper-v-network-issues-1-gbe -никс).

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

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

Откройте диспетчер устройств на хост-сервере Hyper-V.
Разверните контейнер «Сетевые адаптеры».
Щелкните правой кнопкой мыши сетевой адаптер и выберите команду «Свойства» в контекстном меню, как показано на рисунке 17. Если хост содержит несколько сетевых адаптеров, вам нужно будет повторить этот процесс для каждого адаптера.
Когда Windows отобразит страницу свойств адаптера, перейдите на вкладку «Дополнительно».
Найдите параметр для очереди виртуальной машины, как показано на рисунке 18, и убедитесь, что он отключен.

Рисунок 17 | Найдите проблемный сетевой адаптер в диспетчере устройств.

Рисунок 18 | Найдите и отключите очередь виртуальных машин.

Если вы предпочитаете использовать PowerShell, вы можете проверить, включен ли VMQ на ваших сетевых адаптерах, введя следующую команду:

Get-NetAdapterVMQ

Этот командлет отобразит состояние VMQ для каждого сетевого адаптера, как показано на рисунке 19.

Рисунок 19 | Командлет Get-NetAdapterVMQ отображает состояние VMQ для каждого сетевого адаптера.

Если PowerShell обнаруживает, что VMQ включен для определенного сетевого адаптера, и вы хотите отключить VMQ, вы можете сделать это с помощью следующей команды:

Disable-NetAdapterVMQ –Name <имя сетевого адаптера>

. обратите внимание, что эта команда требует указать имя сетевого адаптера. Имя каждого сетевого адаптера раскрывается при вводе командлета Get-NetAdapterVMQ.Например, сетевой адаптер, показанный на предыдущем рисунке, использует имя MyNICTeam, и это имя, которое вы использовали бы, если бы вы отключили VMQ для этого конкретного сетевого адаптера. На рисунке 20 показано, как выглядит этот процесс. В этом случае VMQ уже отключен, но вы все равно можете увидеть, как использовать различные команды.

Рисунок 20 | Командлет Disable-NetAdapterVMQ можно использовать для отключения VMQ для указанного сетевого адаптера.

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

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

Рисунок 21 | Виртуальные машины не могут быть включены.

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

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

В этом конкретном примере проблема была вызвана отключенным виртуальным диском в дисковых пространствах Windows (а не самим Hyper-V). Однако имейте в виду, что та же проблема может возникнуть, даже если вы не используете дисковые пространства. Виртуальные машины, использующие хранилище с прямым подключением (DAS), iSCSI, Fibre Channel и т. Д., Могут столкнуться с одной и той же проблемой в случае отказа массива хранения или подключения к этому массиву.

Если вы используете дисковые пространства Windows, то диспетчер сервера часто покажет вам причину проблемы.Если вы посмотрите, например, на рисунок 22, вы увидите, что виртуальный диск отображает предупреждение, и что щелчок правой кнопкой мыши по диску дает возможность подключить виртуальный диск.

Рисунок 22 | Командлет Disable-NetAdapterVMQ можно использовать для отключения VMQ для указанного сетевого адаптера. Виртуальный диск, который Hyper-V использует для хранения виртуальной машины, отключается.

Стоит отметить, что, хотя виртуальный диск можно подключить в течение нескольких секунд, виртуальные машины Hyper-V не становятся доступными сразу.Windows может занять минуту или две, чтобы восстановить сопоставление дисков для недавно подключенного виртуального диска. Hyper-V в конечном итоге распознает изменение и сделает виртуальные машины доступными (это может занять до пяти минут), но вы можете ускорить процесс, используя кнопки «Обновить» в диспетчере серверов и диспетчере Hyper-V. Аналогичного поведения можно ожидать при повторном подключении других форм хранения, даже если дисковые пространства Windows не используются. Hyper-V может потребоваться несколько минут, чтобы подтвердить, что проблема устранена.

ПРОБЛЕМЫ РАЗРЕШЕНИЙ

Часто проблемы, возникающие в Hyper-V, можно отнести к проблемам с разрешениями. Эти проблемы могут привести к ошибкам «Доступ запрещен» и множеству других сообщений об ошибках. Фактически, существует слишком много различных типов ошибок, связанных с разрешениями, чтобы можно было перечислить их все здесь. Тем не менее, подавляющее большинство этих ошибок можно отнести к одной из двух причин:

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

Произошла ошибка при попытке подключения к серверу

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

Рисунок 23 | Диспетчер Hyper-V не может подключиться к Hyper-V.

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

Сначала убедитесь, что разрешение имен DNS работает для сервера Hyper-V.Клиентский компьютер, на котором запущен диспетчер Hyper-V, должен иметь возможность разрешать удаленный сервер Hyper-V по его полному доменному имени.
Во-вторых, убедитесь, что нет правил брандмауэра, препятствующих использованию Hyper-V Manager или System Center Virtual Machine Manager. Список портов представлен в следующем разделе.
В-третьих, убедитесь, что служба управления виртуальными машинами Hyper-V работает на сервере Hyper-V. Вы можете проверить статус этой услуги, введя Services.msc в командной строке сервера. Вы можете увидеть, как это выглядит на рисунке 24.

Рисунок 24 | Убедитесь, что служба управления виртуальными машинами Hyper-V запущена.

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

Get-Service VMMS

Если вы обнаружите, что служба должна быть остановлена, вы можете запустить службу, введя эту команду :

Start-Service VMMS

Эти команды используются на рисунке 25.

Рисунок 25 | Вы можете использовать PowerShell для запуска службы управления виртуальными машинами Hyper-V.

Порты межсетевого экрана

Как упоминалось ранее, неправильно настроенный межсетевой экран может сделать невозможным удаленное управление хостом Hyper-V. Требуемые порты брандмауэра различаются в зависимости от того, используете ли вы Hyper-V Manager или System Center Virtual Machine Manager. В разделах ниже перечислены необходимые порты межсетевого экрана.

Порты Hyper-V: Hyper-V использует следующие порты межсетевого экрана:

905

WMI (TCP-In)

Любой

TCP-прослушиватель

Hyper-V WMI (Async-In TCP)	Любая
Hyper-V WMI (DCOM-In)	TCP	135
Hyper-V WMI	Любой
Hyper-V (MIG-TCP-In)	TCP	6600
Hyper-V (REMOTE_DESK418 Hyper-V (TCP0005 9_DESKTOP) 2179
Hyper-V (RPC)	TCP	Динамические порты RPC
Hyp er-V (RPC-EPMAP)	TCP	RPC Endpoint Mapper
Клиенты управления Hyper-V — WMI (Async-In)	TCP
Клиенты управления Hyper-V — WMI (DCOM-In)	TCP	135
Клиенты управления Hyper-V — WMI (TCP-In)		905 TCP	Любой
HTTP-приемник реплики Hyper-V (TCP-In)	TCP	80
HT- In)				TCP	443

Вы можете увидеть список правил брандмауэра Microsoft для Hyper-V на рисунке 26.

Рисунок 26 | Это правила брандмауэра, связанные с Hyper-V, которые существуют в Windows Server 2012 R2.

Порты диспетчера виртуальных машин System Center: Корпорация Майкрософт определяет отдельный список портов брандмауэра для использования с диспетчером виртуальных машин System Center 2012 R2. Эти порты описаны в статье TechNet по адресу: https://technet.microsoft.com/en-us/library/cc764268.aspx
Необходимые порты:

Веб-сервер VM

Сервер библиотеки VMM

на хост виртуального сервера

905 903 903

Решение проблем с разрешениями

Предполагая, что разрешение имен DNS настроено правильно, правильные порты брандмауэра открыты и запущена служба управления виртуальными машинами Hyper-V, то проблемы с доступом к Hyper-V из диспетчера Hyper-V, вероятно, будут быть связанными с разрешениями.Чтобы устранить проблему (в среде, не относящейся к домену), вам потребуется использовать инструмент Component Services (Dcomcnfg.exe). Причина, по которой вам потребуется использовать этот инструмент, заключается в том, что разрешения применяются на уровне модели компонентных объектов (COM), а инструмент «Службы компонентов» позволяет изменять разрешения на уровне COM.

Вы можете изменить разрешения COM, выполнив следующие действия:

Закройте диспетчер Hyper-V.
На клиентском компьютере откройте проводник и перейдите в папку C: \ Windows \ System32.
Щелкните правой кнопкой мыши файл Dcomcnfg.exe и выберите в контекстном меню команду «Запуск от имени администратора». Помните, что расширения файлов по умолчанию скрыты, поэтому не используйте файл Dcomcnfg.exe.mui случайно. При необходимости укажите учетные данные администратора.
Когда Windows запускает окно «Службы компонентов», дважды щелкните контейнер «Компьютер», чтобы открыть контейнер «Мой компьютер» под ним.
Щелкните правой кнопкой мыши «Мой компьютер», как показано на рисунке 27, и выберите команду «Свойства» из контекстного меню.

Рисунок 27 | Щелкните правой кнопкой мыши контейнер «Мой компьютер».

Выберите вкладку Безопасность COM.
Найдите раздел «Права доступа» и нажмите кнопку «Изменить пределы», как показано на рисунке 28.

Рисунок 28 | Найдите раздел «Права доступа» и нажмите кнопку «Изменить ограничения».

Проверьте, существует ли в настоящее время анонимный вход в списке безопасности по умолчанию. Если он не существует, нажмите кнопку «Добавить», введите «Анонимный» и нажмите «ОК».
Установите флажок «Включить удаленный доступ для анонимного входа в систему», как показано на рисунке 29.
Нажмите Применить, а затем ОК.

Рисунок 29 | Включите анонимный удаленный доступ.

Стоит отметить, что, хотя этот метод работает, он снижает безопасность. По возможности лучше избегать использования этой техники. Например, вместо запуска диспетчера Hyper-V с рабочей станции, не присоединенной к домену (на которой, скорее всего, потребуется это исправление), администратор может вместо этого использовать рабочую станцию, присоединенную к домену, или установить сеанс RDP для Hyper-V. -V Server и запустите диспетчер Hyper-V оттуда.

Неадекватные разрешения для запуска от имени

Если вы используете System Center Virtual Machine Manager для управления Hyper-V, то ошибки отказа в доступе иногда могут возникать в результате того, что учетная запись запуска от имени была удалена, отключена или не имеет соответствующих разрешений. Когда администратор выполняет действие в System Center Virtual Machine Manager, сервер рассматривает это действие как запланированное задание, даже если действие должно произойти немедленно. Таким образом, многие действия требуют использования учетной записи RunAs.Разрешения этой учетной записи используются вместо разрешений администратора. Вы можете проверить наличие учетной записи RunAs, выполнив следующие действия:

Откройте консоль Virtual Machine Manager.
Выберите рабочее пространство «Настройки».
Выберите контейнер «Учетные записи запуска от имени».
Убедитесь, что ваша учетная запись запуска от имени указана в списке, как показано на рисунке 30. Если учетной записи нет в списке, щелкните значок «Создать учетную запись запуска от имени», расположенный на панели инструментов, и следуйте инструкциям, чтобы выбрать учетную запись Active Directory, которая будет используется как учетная запись RunAs.Если ваша учетная запись RunAs уже указана в списке, но не работает должным образом, вы можете попробовать удалить ее из списка учетных записей RunAs, а затем добавить ее обратно.

Рисунок 30 | Убедитесь, что ваша учетная запись RunAs присутствует в списке учетных записей RunAs.

ОШИБКА ЖИВОЙ МИГРАЦИИ

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

Отсутствующие разрешения
Неправильный протокол аутентификации
Смешанные согласованные конфигурации

Отсутствующие разрешения

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

Откройте диспетчер Hyper-V на принимающем узле.
Щелкните правой кнопкой мыши имя сервера (в дереве консоли) и выберите команду «Параметры Hyper-V» в появившемся контекстном меню.
Когда Windows отображает диалоговое окно «Параметры Hyper-V», выберите контейнер Live Migrations, показанный на рисунке 31.
Убедитесь, что установлен флажок «Enable Incoming and Outgoing Live Migrations».
Убедитесь, что для числа одновременных динамических миграций установлен соответствующий уровень и что динамические миграции не завершаются ошибкой просто потому, что выполняется слишком много одновременных динамических миграций.
Проверьте список входящих динамических миграций на наличие ограничений, которые могут привести к сбою динамических миграций.
Повторите процесс для хоста, содержащего виртуальную машину, которую необходимо переместить.

Рисунок 31 | Убедитесь, что включена живая миграция.

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

(Get-VMHost <имя виртуальной машины>). VirtualMachineMigrationEnabled

Если включена живая миграция, эта команда должна вернуть значение True, как показано на рисунке 32.

Рисунок 32 | Вы можете использовать PowerShell, чтобы проверить, включена ли живая миграция для хоста.

Если вам нужно включить динамическую миграцию, вы можете сделать это с помощью командлета Enable-VMMigration.Обычно вам также потребуется настроить сеть миграции и протокол миграции (протокол миграции будет обсуждаться в следующем разделе). Для этих шагов используются следующие команды:

Enable-VMMigration
Set-VMMigrationNetwork <сетевой IP>
Set-VMHost –VirtualMachineMigrationAuthenticationType <протокол аутентификации>

Неправильный протокол аутентификации

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

Hyper-V предлагает два варианта протокола аутентификации — CredSSP и Kerberos. Протокол CredSSP имеет ограничение на количество переходов, равное единице. Это ограничение означает, что если используется протокол CredSSP, вы должны инициировать динамическую миграцию локально на сервере Hyper-V, который содержит виртуальную машину, которую вы хотите перенести в реальном времени. Если вы используете CredSSP и инициируете динамическую миграцию с другого хоста, живая миграция завершится ошибкой.

Протокол Kerberos гораздо более гибкий и безопасный. Однако Microsoft рекомендует включить ограниченное делегирование, если вы собираетесь использовать Kerberos.

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

Откройте диспетчер Hyper-V.
Щелкните правой кнопкой мыши сервер Hyper-V в дереве консоли и выберите команду «Параметры Hyper-V».
Когда Windows откроет диалоговое окно «Параметры Hyper-V», выберите развернуть контейнер Live Migrations.
Выберите контейнер Advanced Features, как показано на рисунке 33.
Обратите внимание на протокол аутентификации, который используется, и при необходимости измените протокол.

Рисунок 33 | Параметры протокола проверки подлинности существуют в контейнере дополнительных функций.

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

(Get-VMHost <имя виртуальной машины>).VirtualMachineMigrationAuthenticationType

Как вы можете видеть на Рисунке 34, эта команда вызывает отображение протокола аутентификации.

Рисунок 34 | PowerShell может сказать вам, какой протокол проверки подлинности используется для динамической миграции.

Если вам нужно переключиться на другой протокол аутентификации, вы можете сделать это с помощью следующей команды:

Set-VMHost –VirtualMachineMigrationAuthenticationType <протокол аутентификации>

На рисунке 35 показан процесс переключения с аутентификации CredSSP на аутентификацию Kerberos. .

Рисунок 35 | Вы можете использовать PowerShell, чтобы изменить тип проверки подлинности при динамической миграции.

Несоответствующие конфигурации

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

Несоответствие ЦП

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

Вы можете отключить расширенные функции ЦП виртуальной машины, выполнив следующие действия:

Откройте диспетчер Hyper-V.
Щелкните виртуальную машину правой кнопкой мыши и выберите в контекстном меню команду «Настройки».
Разверните контейнер процессора.
Выберите контейнер совместимости.
Установите флажок «Мигрировать на физический компьютер с другой версией процессора», как показано на Рис. 36

Рис. 36 | Установите флажок «Перенести на физический компьютер с другой версией процессора», чтобы отключить дополнительные функции процессора.

Несоответствие виртуальных коммутаторов

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

Откройте диспетчер Hyper-V.
Щелкните виртуальную машину правой кнопкой мыши и выберите в контекстном меню команду «Настройки».
Выберите вкладку «Сетевой адаптер», показанную на рисунке 37.
Запишите имя виртуального коммутатора.
При необходимости создайте виртуальный коммутатор с таким же именем на целевом хосте.

Рисунок 37 | Запишите имя виртуального коммутатора и при необходимости создайте виртуальный коммутатор с таким же именем на целевом узле.

Если вы предпочитаете использовать PowerShell, вы можете использовать командлет Compare-VM для проверки пригодности хоста Hyper-V для приема конкретной виртуальной машины. Этот командлет требует, чтобы вы указали имя виртуальной машины и имя целевого хоста. Синтаксис этой команды:

Compare-VM –Name <имя виртуальной машины> -DestinationHost <имя целевого хост-сервера Hyper-V>

На рисунке 38 показан пример использования этой команды.

Рисунок 38 | Вы можете использовать командлет Compare-VM, чтобы проверить способность Hyper-V выполнять миграцию виртуальной машины в реальном времени.

Как видно на рисунке выше, Compare-VM сообщил о некоторых ошибках, но эти ошибки имеют числовую форму и требуют дальнейшего объяснения. Чтобы получить объяснение возможных ошибок, введите следующие команды:

$ Report = Compare-VM –Name <имя виртуальной машины> -DestinationHost
$ Report.Несовместимость | Format-Table –AutoSize

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

Рисунок 39 | Так выглядит отчет о несовместимости.

ПРОБЛЕМЫ, СВЯЗАННЫЕ С РЕЗЕРВНЫМ КОПИРОВАНИЕМ

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

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

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

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

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

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

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

На виртуальной машине должна быть запущена служба интеграции резервного копирования (контрольная точка тома).Службы Integration Services — это набор драйверов, которые позволяют виртуальной машине взаимодействовать с гипервизором. Службы Integration Services можно включать и отключать по отдельности, как показано на рисунке 40.

Рисунок 40 | Должна быть включена служба интеграции резервного копирования (контрольная точка тома).

Виртуальная машина должна быть настроена для хранения контрольных точек на том же физическом томе, что и виртуальный жесткий диск виртуальной машины. Как вы можете видеть на предыдущем рисунке, диалоговое окно «Параметры» каждой виртуальной машины включает контейнер «Расположение файла контрольной точки».Вы можете сравнить расположение этого контейнера с положением виртуального жесткого диска виртуальной машины.
Виртуальная машина должна быть настроена так, чтобы ее хранилище обрабатывалось как базовые диски, а не как динамические. Виртуальные жесткие диски виртуальной машины также должны быть отформатированы с использованием файловой системы, такой как NTFS, которая поддерживает использование контрольных точек. Это требование не относится к динамическим дискам или тонкому предоставлению, а скорее к способу использования виртуального жесткого диска гостевой операционной системой.Если вы введете команду DiskMgmt.msc в приглашении «Выполнить» гостевой операционной системы, Windows откроет консоль управления дисками. Эта консоль показывает, настроен ли каждый диск как базовый или динамический, как показано на рисунке 41. Как вы можете видеть на рисунке, консоль управления дисками также показывает файловую систему, которая используется на каждом томе.
Виртуальная машина должна находиться в рабочем состоянии. Если виртуальная машина приостановлена или выключена, будет создана резервная копия сохраненного состояния.

Рисунок 41 | Консоль управления дисками покажет вам конфигурацию хранилища гостевой операционной системы.

Анатомия службы теневого копирования тома

Служба теневого копирования тома (VSS), которая является механизмом, используемым для создания резервных копий моментальных снимков дочерних виртуальных машин, состоит из трех основных частей. Эти части включают:

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

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

Рисунок 42 | Это основные компоненты VSS.

Устранение неполадок службы теневого копирования томов:

Основным инструментом для диагностики проблем VSS является инструмент командной строки под названием VSSAdmin.Например, вы можете использовать команду VSSAdmin List Writers, чтобы убедиться, что каждый из модулей записи стабилен и не находится в состоянии ошибки. Вы можете увидеть пример этого на рисунке 43. Вы можете увидеть другие параметры командной строки VSSAdmin, введя VSSAdmin /? команда.

Рисунок 43 | Вы можете использовать команду VSSAdmin List Writers для проверки работоспособности модуля записи.

Надеюсь, ваши писатели в исправном состоянии и об ошибках не сообщается. Если, однако, отображаются ошибки, Dell предоставляет рекомендации по устранению проблемы по адресу: https: // support.программного обеспечения. dell.com/kb/117647

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

Откройте диспетчер Hyper-V.
Щелкните правой кнопкой мыши виртуальную машину, для которой возникают проблемы с резервным копированием, и выберите команду «Параметры» в появившемся контекстном меню.
Когда Windows отобразит диалоговое окно «Параметры», выберите контейнер служб Integration Services.
Убедитесь, что службы интеграции резервного копирования (Volume Checkpoint) включены, как показано на рисунке 44.

Рисунок 44 | Убедитесь, что служба интеграции резервного копирования (Volume Checkpoint) включена.

Если вы хотите использовать PowerShell для проверки, включена ли служба интеграции резервного копирования (Volume Checkpoint), вы можете сделать это, введя следующую команду:

Get-VM –Name <имя виртуальной машины> | Get-VMIntegrationService –Name VSS

Вы можете увидеть, как выглядит эта команда на рисунке 45.В этом случае в столбце «Включено» отображается значение «Истина», указывающее на то, что служба интеграции резервного копирования (контрольная точка тома) включена.

Рисунок 45 | Вы можете использовать PowerShell, чтобы проверить, включена ли служба интеграции резервного копирования (контрольная точка тома).

Одна из приятных особенностей PowerShell заключается в том, что она упрощает проверку существования службы интеграции Backup (Volume Checkpoint) на большом количестве виртуальных машин. Если, например, вы хотите проверить состояние службы интеграции резервного копирования (Volume Checkpoint) для каждой виртуальной машины на определенном хосте, вы можете сделать это с помощью следующей команды:

Get-VM | Get-VMIntegrationService –Name VSS

Вывод команды показан на рисунке 46.

Рисунок 46 | Вы можете проверить службы интеграции на нескольких виртуальных машинах.

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

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

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

Чтобы понять, почему возникает эта проблема и как работает исправление, необходимо понимать, как контрольные точки используются в процессе резервного копирования. Контрольная точка — это не что иное, как разностный диск, имеющий отношения родитель / потомок с виртуальной машиной.При резервном копировании виртуальной машины Hyper-V может (в зависимости от типа создаваемой резервной копии) создать разностный диск. Этот разностный диск перехватывает любые операции записи, которые могут произойти в процессе резервного копирования. Таким образом, Hyper-V не нужно беспокоиться об изменении содержимого виртуального жесткого диска во время процесса резервного копирования. После завершения процесса резервного копирования содержимое разностного диска объединяется с основным виртуальным жестким диском, а разностный диск удаляется.По крайней мере, так должен работать процесс. Если резервное копирование не удается, контрольная точка может остаться на месте.

К сожалению, нет простого способа удалить эту контрольную точку. В большинстве случаев единственный реальный вариант — это углубиться в PowerShell.

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

Откройте административное окно PowerShell на сервере Hyper-V, которое содержит виртуальную машину, на которой возникла проблема.
Введите командлет Get-VM.Это заставляет PowerShell создать список виртуальных машин, находящихся на сервере. Этот шаг важен, потому что вам нужно знать имя виртуальной машины виртуальной машины, которое может отличаться от имени ее компьютера. Вы можете увидеть пример такого списка на рисунке 47.

Рисунок 47 | Командлет Get-VM отображает список виртуальных машин, существующих на узле.

Введите следующую команду: Get-VMSnapshot –VMName <имя виртуальной машины> | FL Эта команда вернет информацию о контрольной точке, как показано на рисунке 48.Стоит отметить, что на этом рисунке показана стандартная контрольная точка, а не контрольная точка из неудачного резервного копирования. Однако общие концепции остаются прежними.

Рисунок 48 | PowerShell возвращает информацию о снимке.

Введите следующую команду: Get-VMSnapshot –VMName <имя виртуальной машины> | Remove-VMSnapshot Эта команда удаляет контрольную точку.
Убедитесь, что контрольная точка была удалена, выполнив следующую команду: GetVMSnapshot –VMName <имя виртуальной машины> | FL Контрольная точка больше не должна существовать, как показано на рисунке 49.

Рисунок 49 | КПП больше не существует.

ПРОБЛЕМЫ ВЫСОКОЙ ДОСТУПНОСТИ

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

Виртуальные машины не переключаются на другой узел кластера

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

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

Виртуальная машина не определена как кластерная роль

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

Откройте диспетчер отказоустойчивого кластера.
Разверните список для своего кластера и выберите контейнер Roles.
Убедитесь, что ваши виртуальные машины перечислены как кластерные роли, как показано на рисунке 50.

Рисунок 50 | Убедитесь, что ваши виртуальные машины указаны как кластерные роли.

Если вы обнаружите, что ваши виртуальные машины отсутствуют в списке, вы можете щелкнуть ссылку «Настроить роль» на панели «Действия» консоли. Это заставит Windows запустить мастер высокой доступности.Теперь вы должны просто следовать подсказкам мастера и выбрать виртуальную машину в качестве типа роли, а затем выбрать виртуальную машину, которую вы хотите сделать высокодоступной.

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

Недостаточные ресурсы

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

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

Один из способов проверить это условие — проверить четные записи журнала хоста. Windows Server хранит записи журнала, связанные с высокой доступностью виртуальных машин, в журнале событий Microsoft-Windows-HyperV-High-Availability. Вы можете получить доступ к этому журналу событий, открыв средство просмотра событий и перейдя в Журналы приложений и служб \ Microsoft \ Windows \ Hyper-V-High-Availability.

Одно событие, на которое следует обратить внимание:

Идентификатор события: 21502
Источник: Microsoft-Windows-Hyper-V-High-Availability
Тип: Ошибка
Описание: Виртуальная машина <имя виртуальной машины> не выполнялась живая миграция добиться успеха у источника.Перенос не удался.

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

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

Чтобы настроить приоритет виртуальной машины, выполните следующие действия:

Откройте диспетчер отказоустойчивого кластера.
Выберите контейнер «Роли».
Щелкните правой кнопкой мыши виртуальную машину, которой вы хотите назначить приоритет, а затем выберите команду «Свойства» в контекстном меню.
Выберите приоритет для виртуальной машины, как показано на рисунке 51.
Нажмите OK.

Рисунок 51 | Установите приоритет виртуальной машины и нажмите ОК.

Виртуальным машинам также можно назначить приоритеты с помощью консоли Virtual Machine Manager. Для этого выполните следующие действия:

Откройте консоль диспетчера виртуальных машин.
Выберите рабочую область виртуальных машин и служб.
Щелкните правой кнопкой мыши виртуальную машину, которой вы хотите изменить приоритет, и выберите команду «Свойства» в контекстном меню.
Когда откроется диалоговое окно «Свойства» виртуальной машины, выберите контейнер «Доступность».
Выберите приоритет, который вы хотите назначить виртуальной машине, как показано на рисунке 52. Вы можете назначать приоритеты только высокодоступным виртуальным машинам, поэтому приоритеты на рисунке неактивны.

Рисунок 52 | Вы можете настроить приоритеты виртуальных машин через консоль Virtual Machine Manager.

ЗАКЛЮЧЕНИЕ

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

Если у вас возникли проблемы с Hyper-V, которые не обсуждались в этой книге, вы можете рассмотреть возможность поиска ресурсов Microsoft Hyper-V в TechNet: https://technet.microsoft.com/ en-us / library / mt169373 ( v = ws.11) .aspx. В случае более серьезных проблем вы можете обратиться в службу поддержки Microsoft (https://technet.microsoft.com/en-us/windowsserver/hh553005.aspx).

Об авторе: Брайен М. Поузи

Брайен Поузи — 14-кратный MVP Microsoft с более чем двадцатилетним опытом работы в ИТ. До того, как стать фрилансером, Брайен работал ИТ-директором в национальной сети больниц и медицинских учреждений. Он также работал сетевым инженером в Министерстве обороны США в Форт-Ноксе и сетевым администратором в некоторых из крупнейших страховых компаний страны. Помимо работы в сфере информационных технологий, Брайен в настоящее время тренируется на гражданского астронавта.Для получения дополнительной информации посетите brienposey.com или twitter.com/BrienPosey

Об Altaro

Altaro Software (www.altaro.com) — быстрорастущий разработчик простых в использовании решений для резервного копирования, которые используют более 30 000 клиентов для резервного копирования и восстановления обоих Виртуальные машины на базе Hyper-V и VMware, созданные специально для малого и среднего бизнеса, с количеством хост-серверов до 50. Компания Altaro гордится своим программным обеспечением и высоким уровнем персонального обслуживания и поддержки клиентов, и это видно; Основанная в 2009 году, компания Altaro уже обслуживает более 30 000 довольных клиентов по всему миру и является золотым партнером Microsoft по разработке приложений и технологическим партнером VMware.

Машине Hyper-V не удалось изменить состояние (решено)

Если вы используете супервизор Hyper-V для создания виртуальных машин и управления ими, скорее всего, рано или поздно вы столкнетесь с этой ошибкой: «Машине не удалось изменить состояние». Иногда появляется сообщение «Не удалось запустить».

Полное сообщение об ошибке:

Приложение обнаружило ошибку при попытке изменить состояние машины A.
Машине A не удалось изменить состояние.

Получаете ли вы ошибку «Хэш изображения без подписи не разрешен (БД)» при использовании Hyper-V? Вот как это исправить.

Как устранить ошибку «машина не смогла изменить состояние»

Есть несколько возможных причин этой проблемы:

Недостаточно места на диске для запуска машины
Сетевой адаптер машины имеет проблему (Источник)
Антивирусное программное обеспечение блокирует доступ к файлам ВМ (Источник)

Чтобы определить основную причину :

Перейдите в средство просмотра событий
Разверните «Журналы приложений и служб> Microsoft> Windows> Hyper-V-Worker»
Нажмите «Администратор».Затем проверьте события, помеченные как «Ошибка».

В моем случае проблема заключалась в дисковом пространстве.

Идентификатор события 3326:
Не удалось запустить виртуальную машину Windows Server 2016 Standard (базовая копия) из-за нехватки места на диске. Системе не удалось создать файл содержимого памяти на «C: \ ProgramData \ Microsoft \ Windows \ Hyper-V \ Virtual Machines \ ABC.VMRS» размером 4096 МБ. Задайте путь к диску с большим объемом памяти или удалите ненужные файлы с диска и повторите попытку.
Код события 12030:
Не удалось запустить Windows Server 2016 Standard (базовая копия). (Идентификатор виртуальной машины ABC)
Идентификатор события 3050:
Не удалось найти описание для события с кодом 3050 из источника Microsoft-Windows-Hyper-V-Worker. Либо компонент, вызывающий это событие, не установлен на вашем локальном компьютере, либо установка повреждена. Вы можете установить или восстановить компонент на локальном компьютере.
Если событие возникло на другом компьютере, отображаемую информацию нужно было сохранить вместе с событием.
В событии была включена следующая информация: Windows Server 2016 Standard (базовая копия)
0x80070070
Отсутствует конкретный ресурс локали для нужного сообщения

Если у вас есть ошибка с идентификатором события 3326, освобождение места в вашей системе должно решить проблему. Кроме того, вы можете удалить сохраненное состояние, чтобы освободить место.

Удалить сохраненное состояние виртуальной машины

Ищете способы клонировать виртуальные машины Hyper-V? Посмотрите этот пост!

Страница не найдена

Документы

Моя библиотека

раз

- Моя библиотека
«»
×
×
Настройки файлов cookie
Как установить роль Hyper-V в виртуальной машине Windows 10 под VMWare ESXi
Одна из тестовых задач, необходимых для установки роли виртуализации Hyper-V на виртуальной машине Windows 10 (также применимой к Windows Server 2016), запущенной на хосте VMWare ESXi.Это означало, что мне нужно обеспечить вложенную виртуализацию Hyper-V на VMWare ESXi.
Прежде всего, пару слов о вложенной виртуализации. Вложенная виртуализация позволяет запускать гипервизор внутри виртуальной машины, работающей на другом гипервизоре. В Hyper-V полная поддержка вложенной виртуализации появилась в Windows Server 2016 / Windows 10 Anniversary Update. В VMWare эта технология работает давно (появилась в ESXi 5.0).
У меня VMWare ESXi 6.0 хост виртуализации под управлением виртуальной машины Windows 10 1709.
При попытке установить роль гипервизора Hyper-V (компонент называется Hyper-V Hypervisor ) из Панели управления -> Программы и компоненты -> Включить или выключить функции Windows, этот параметр оказался неактивным. Причина следующая:
Hyper-V не может быть установлен: процессор не имеет необходимых возможностей виртуализации
Чтобы включить вложенную виртуализацию для этой виртуальной машины с гостевой ОС Windows 10, откройте настройки виртуальной машины с помощью веб-клиента vSphere (виртуальная машина должна быть выключена).В разделе ЦП установите флажок « Предоставить виртуализацию с аппаратной поддержкой для гостевой ОС » (этот параметр недоступен в тонком клиенте vCenter C #).

Примечание . В предыдущих версиях ESXi, которые не имели этой опции, и в настольной VMWare Workstation вы можете включить вложенную виртуализацию, добавив следующие опции в файл конфигурации виртуальной машины (* .vmx).
hypervisor.cpuid.v0 = «ЛОЖЬ» mce.enable = «ИСТИНА» vhv.enable = «ИСТИНА»
В клиенте VMware vSphere эти параметры могут быть добавлены в настройки виртуальной машины: Параметры -> Общие -> Параметры конфигурации . Добавьте две новые строки с такими же параметрами ( Добавить строку ).
Запустите виртуальную машину Windows 10 и попробуйте снова установить роль Hyper-V. Теперь Windows не определяет, что она работает внутри другого гипервизора, но появляется новая ошибка:
Hyper-V не может быть установлен: процессор не поддерживает преобразование адресов второго уровня (SLAT).
Это означает, что помимо поддержки виртуализации, процессор ВМ должен поддерживать технологию SLAT , т.е. е. виртуализация страниц памяти и прямое управление ими гостевой ОС. В терминах Intel эта функция называется Extended Page Tables ( EPT ), а AMD называет ее Rapid Virtualization Indexing ( RVI ).
Убедитесь, что процессор (vCPU) поддерживает SLAT, используя следующую команду:
системная информация
Команда в разделе требований Hyper-V должна возвратить, что нет поддержки SLAT:
Трансляция адресов второго уровня: №
В этом случае вам необходимо изменить параметры процессора виртуальной машины.В разделе виртуализации ЦП / MMU веб-клиента vSphere выберите аппаратный ЦП и MMU .
В тонком клиенте vSphere такая же опция находится в разделе CPU / MMU Virtualization на вкладке Options и называется ‘ Use Intel VT-x / AMD-V for command virtualization and Intel EPT / AMD RVI для виртуализации MMU ‘.
Запустите виртуальную машину Windows 10 и убедитесь, что ее процессор теперь поддерживает SLAT.Затем вы можете установить все компоненты роли Hyper-V и запускать другие виртуальные машины внутри этой виртуальной машины Windows 10.
Управление виртуальными машинами, застрявшими в состоянии «Запуск» или «Остановка» в Hyper-V
Время от времени виртуальные машины Hyper-V по разным причинам решают, что они не хотят запускаться или останавливаться правильно, и застревают в состоянии «Запуск» или «Остановка».
Это немного неудобно, и последнее, что мы хотим сделать как администратор, — это перенести все другие виртуальные машины для перезагрузки хоста Hyper-V.Особенно, если хост управляет большим количеством работающих машин или не является частью кластера, а миграция других работающих машин может занять некоторое время или каким-либо образом повлиять на их работу.
Один из способов убить эту зависшую виртуальную машину — открыть диспетчер задач и завершить задачу, отвечающую за эту машину. К сожалению, это не так просто, потому что рабочий процесс Virtual Machine Worker Process , который отвечает за запуск виртуальной машины, появляется несколько раз, по одному разу для каждой запущенной гостевой машины!
Итак, как мы их различим?
1.Сначала нам нужно открыть диспетчер задач и просмотреть вкладку процесса
2. Затем щелкните правой кнопкой мыши заголовки столбцов и добавьте в командную строку столбец
.
3. Разверните столбец Командная строка , чтобы просмотреть полную команду, включая GUID машины в конце каждой строки
4. Перейдите в папку, где хранятся виртуальные машины, и откройте папку виртуальной машины, которая в данный момент зависла. Отсюда мы можем найти файл конфигурации машины и записать GUID для этой машины
5.Теперь мы знаем, какой GUID относится к виртуальной машине, которую мы хотим остановить. Вернитесь к диспетчеру задач , щелкните правой кнопкой мыши нужный процесс и Завершите процесс

ПРИМЕЧАНИЕ: этот процесс следует использовать только в крайнем случае, поскольку он может вызвать повреждение виртуальной машины!
Другой способ найти GUID машин, работающих на сервере, — использовать PowerShell для вывода имен машин и связанного GUID
Get-VM | Выберите имя, Id
Существуют различные способы определения того, какая виртуальная машина представляет собой Рабочий процесс виртуальной машины в диспетчере задач.
В диспетчере задач также можно добавить столбец ID процесса , а также командную строку и затем определить, какой процесс к какой виртуальной машине подключен.
Я не признаюсь, что являюсь лучшим в составлении команд PowerShell, но строка ниже извлекает список имен виртуальных машин и идентификаторов GUID, а затем сравнивает его со списком идентификаторов GUID в командной строке запущенных процессов и возвращает имена виртуальных машин с связанный идентификатор процесса.
No related posts.
Share :
Навигация по записям
Previous: Настройка proxy: «Проверить настройки прокси-сервера и брандмауэра»: значение предупреждения
Next: Shell experience host windows 10 что это: Приложения Microsoft.Windows.ShellExperienceHost и Microsoft.Windows.Cortana должны быть установлены правильно
Related Post
Книги тестирование программного обеспечения: 15 книг по тестированию программного обеспечения
Эмулятор терминала linux: Лучшие эмуляторы терминала Linux | Losst
Как на клавиатуре поставить пи: Число Пи на клавиатуре и в Word
Добавить комментарий Отменить ответ
Ваш адрес email не будет опубликован. Обязательные поля помечены *
Комментарий *
Имя *
Email *
Сайт
Рубрики
- Jquery
- Mysql
- Php
- Для чайников
- Разное
- Сервер
- Советы
- Установка

Тип подключения	Протокол	Порт по умолчанию
Сервер VMM к агенту VMM на хосте на базе Windows Server (контроль)	WS-Management
Сервер VMM агенту VMM на хосте под управлением Windows Server (передача файлов)	HTTPS (с использованием BITS)	443 (максимальное значение: 32768)
Сервер VMM на удаленный Microsoft SQL База данных сервера	TDS	1433
Сервер VMM для агента источника P2V 9051 8	DCOM	135
Консоль администратора VMM на сервере VMM	WCF	8100

Сервисный сервер VMM 905 WCF	8100
Портал самообслуживания VMM для веб-сервера самообслуживания VMM	HTTPS	443
BITS	443 (максимальное значение: 32768)
VMM передача файлов между хостами	BITS	443 (максимальное значение: 32768 VM) 75
VMRC	5900
VMConnect (RDP) для хостов Hyper-V	RDP	2179
Удаленный рабочий стол для виртуальных машин
9 905 905 905	Обмен данными с веб-службами VMware	HTTPS	443
Передача файлов SFTP с сервера VMWare ESX 3.0 и хосты VMware ESX Server 3.5	SFTP	22
Передача файлов SFTP с сервера VMM на хосты VMWare ESX Server 3i	HTTPS