Произошла ошибка при подключении к серверу hyper v

@yousufctec

Unable to access Hyper V Manager after the Windows Update 1809. Getting the following error.

image

Hyper-V Virtual Machine Management service is running properly.

image

User is a part of Hyper-V Administrators.

image

All Hyper-V features are turned on as well.

image

Hardware virtualization is enabled. Desktop is running with high end specifications with 32gb of RAM.

Thanks!

Regards,
Yousuf.

@alexandrev

@henkyprayoga

Any updates? I’m encountering the very same issue too

@shellwhale

@KedarDande

Any resolution found for this issue?

@henskjold73

Guessing this is still not resolved…

@henskjold73

This worked for me.

  1. Open «Window Security«
  2. Open «App & Browser control«
  3. Click «Exploit protection settings» at the bottom
  4. Switch to «Program settings» tab
  5. Locate «C:\WINDOWS\System32\vmcompute.exe» in the list and expand it
  6. Click «Edit«
  7. Scroll down to «Code flow guard (CFG)» and uncheck «Override system settings«
  8. Start vmcompute from powershell as administrator net start vmcompute
  9. Restart

Start Hyper-V Manager as administrator

wilka, vinothsundararajan, happylmnop, uosjead, On-The-Offensive, yousufctec, smx-smx, menasbeshay, Tehami, Kushagra8888, and 8 more reacted with thumbs up emoji
vinothsundararajan reacted with laugh emoji
prafful-panwar reacted with hooray emoji
prafful-panwar reacted with heart emoji
prafful-panwar, riccardocastana, and rosywaruku reacted with rocket emoji

@vinothsundararajan

@henskjold73 Your solution which is worked for me thanks for the step by step procedure.

@happylmnop

Worked for me as well. Thank you:)

@ttaitt

Worked for me too!!!
Thank you, Morgan Henskjold

@jamiet147

I had to run ‘MOFCOMP %SYSTEMROOT%\System32\WindowsVirtualization.V2.mof’ from Command Prompt to fix this…..

Seemed to happen after I installed the HPE ProLiant Support Pack!

AquinoN, TheTsoo, fagnercarvalho, moesoha, Isaurio07, yardenshafir, FireEmerald, jebrossard, mfld-fr, jinendrapatel, and 7 more reacted with thumbs up emoji
moesoha and jebrossard reacted with hooray emoji

@AquinoN

I had to run ‘MOFCOMP %SYSTEMROOT%\System32\WindowsVirtualization.V2.mof’ from Command Prompt to fix this…..

Seemed to happen after I installed the HPE ProLiant Support Pack!

Worked for me, too. The code flow guard fix did not. THanks for the mofcomp solution.
Running Windows 10 1809 — not sure what changed since friday, but I come in on Monday and no-go for Hyper-V. I’m back — thanks. Need to get some testing done.

@pbolduc

I had to run ‘MOFCOMP %SYSTEMROOT%\System32\WindowsVirtualization.V2.mof’ from Command Prompt to fix this…..

I ran into this error today too. I am also not sure what changed on my machine to cause this, but the MOFCOMP command resolved the issue. Code flow guard did not fix it for me.

@pbolduc

I had to run ‘MOFCOMP %SYSTEMROOT%\System32\WindowsVirtualization.V2.mof’ from Command Prompt to fix this…..

I ran into this error today too. I am also not sure what changed on my machine to cause this, but the MOFCOMP command resolved the issue. Code flow guard did not fix it for me.

Not sure if it is related or not. But once my Hyper-V was working, my docker in my WSL2 distro stopped working. Even though it is configured in docker desktop settings it says it is not activated any more. It was working fine yesterday,

$ docker images

The command 'docker' could not be found in this WSL 2 distro.
We recommend to activate the WSL integration in Docker Desktop settings.

See https://docs.docker.com/docker-for-windows/wsl/ for details.

I have tried cycling the enable integration in for the distro to no avail.

@pbolduc

I had to run ‘MOFCOMP %SYSTEMROOT%\System32\WindowsVirtualization.V2.mof’ from Command Prompt to fix this…..

I ran into this error today too. I am also not sure what changed on my machine to cause this, but the MOFCOMP command resolved the issue. Code flow guard did not fix it for me.

Not sure if it is related or not. But once my Hyper-V was working, my docker in my WSL2 distro stopped working. Even though it is configured in docker desktop settings it says it is not activated any more. It was working fine yesterday,

$ docker images

The command 'docker' could not be found in this WSL 2 distro.
We recommend to activate the WSL integration in Docker Desktop settings.

See https://docs.docker.com/docker-for-windows/wsl/ for details.

I have tried cycling the enable integration in for the distro to no avail.

Finally what worked for me is I had to disable the WSL 2 based engine, wait for docker desktop to recreate/mount the DockerDesktopVM. Once what was done, I re-enabled the WSL 2 based engine, and enabled in my distro and I am back to normal.

Hopefully this helps anyone else that runs into this issue.

@pkarakal

None of the above solutions work for me. I haven’t been able to use Hyper-V since an inside build from summer 2019. How can this still be an issue? Is anyone working on it on Microsoft or have any official roadmap to fixing this?

@gwata

@pkarakal

TL;DR
In Hyper-V manager, connect to ‘server.local’ instead of ‘server’

Verbose
Randomly this problem pops up on me after updates, and the same fix rarely seems to fix it.

I’m running Hyper-V manager on Win10 1607, connecting to Hyper-V Core 1607 without a domain, with a configured workgroup.

It used to work fine but as of an update, many months ago, on every workstation it has stopped connecting to the server.

After reading through the MS Support document section related to my setup I decided to confirm connectivity, you know Layer-1 foils and all.

While pinging the hyper-v server, for no particular reason I pinged both ‘server’ and ‘server.local’. I noticed that ‘server’ returned an IPv4 response and ‘server.local’ returned an IPv6 response.

After modifying the power shell commands with every combination, the Hyper-V manager still wouldn’t connect.

For kicks and grins, I tried connecting to ‘server.local’ and, why look at that, it comes right up.

Final config:
power shell commands use ‘server’
Hyper-v connects to ‘server.local’

If anyone has any insight as to why hyper-v requires ipv6 all of a sudden, I’d love to read about it.

@giggio

@gwata Thanks for the insight! I had just enabled an IPv6 network at home, and did not connect that to the Hyper-v problem.

I’m not sure if that was the problem (or the only problem), because I also have another one: a long hostname. I named the machine a long hostname when it was first created, and Windows also created another one, truncated at 15 characters. I’m not sure why Windows sometimes uses one, and sometimes the other. Probably some legacy stuff.

In my case, it would not connect. My hostname, returned by the hostname command, was resolving to an ipv6 address. And localhost also was. Hyper-v was trying to connect to the hostname that was truncated when I named the machine. So, I added an entry to my hosts file (C:\Windows\System32\drivers\etc\hosts), pointing to 127.0.0.1. After I did that it was working again.

This also solved the issue on PowerShell. I was getting Get-VM: The computer '<REDACTED>' could not be resolved. Make sure you typed the machine name correctly and that you have network access.. The redacted part was the truncated hostname.

Docker was working fine before, and is still working fine now. But I was already using WSL2.

I hope this helps someone.

@Isaurio07

I had to run ‘MOFCOMP %SYSTEMROOT%\System32\WindowsVirtualization.V2.mof’ from Command Prompt to fix this…..

Seemed to happen after I installed the HPE ProLiant Support Pack!

This worked for me from upgrading from server 2012 R2 to 2019. I guess best option is to upgrade to 2016 them to 2019 so it wont break hyperv management

@Rae1991

This worked for me.

  1. Open «Window Security«
  2. Open «App & Browser control«
  3. Click «Exploit protection settings» at the bottom
  4. Switch to «Program settings» tab
  5. Locate «C:\WINDOWS\System32\vmcompute.exe» in the list and expand it
  6. Click «Edit«
  7. Scroll down to «Code flow guard (CFG)» and uncheck «Override system settings«
  8. Start vmcompute from powershell as administrator net start vmcompute
  9. Restart

Start Hyper-V Manager as administrator

Thank you! Worked for me!

@jiaozh8

This worked for me.

1. Open "_Window Security_"

2. Open "_App & Browser control_"

3. Click "_Exploit protection settings_" at the bottom

4. Switch to "_Program settings_" tab

5. Locate "_C:\WINDOWS\System32\vmcompute.exe_" in the list and expand it

6. Click "_Edit_"

7. Scroll down to "_Code flow guard (CFG)_" and **uncheck** "_Override system settings_"

8. Start vmcompute from powershell as administrator `net start vmcompute`

9. Restart

Start Hyper-V Manager as administrator

谢谢,非常管用。

@ghost

This worked for me.

  1. Open «Window Security«
  2. Open «App & Browser control«
  3. Click «Exploit protection settings» at the bottom
  4. Switch to «Program settings» tab
  5. Locate «C:\WINDOWS\System32\vmcompute.exe» in the list and expand it
  6. Click «Edit«
  7. Scroll down to «Code flow guard (CFG)» and uncheck «Override system settings«
  8. Start vmcompute from powershell as administrator net start vmcompute
  9. Restart

Start Hyper-V Manager as administrator

Thanks you
You just save my day of i3 gen 1 laptop

@RefriZaddo

This worked for me.

  1. Open «Window Security«
  2. Open «App & Browser control«
  3. Click «Exploit protection settings» at the bottom
  4. Switch to «Program settings» tab
  5. Locate «C:\WINDOWS\System32\vmcompute.exe» in the list and expand it
  6. Click «Edit«
  7. Scroll down to «Code flow guard (CFG)» and uncheck «Override system settings«
  8. Start vmcompute from powershell as administrator net start vmcompute
  9. Restart

Start Hyper-V Manager as administrator

did not work for me :(

@jacimo

I tried everything under the sun. What finally worked was restoring WINRM to default — Type -> winrm invoke Restore winrm/config

@mfld-fr

I had to run ‘MOFCOMP %SYSTEMROOT%\System32\WindowsVirtualization.V2.mof’ from Command Prompt to fix this…..

Seemed to happen after I installed the HPE ProLiant Support Pack!

Worked for me after the broken KB5009624. Thanks @jamiet147 !

@tvongsaly4592

I had to run ‘MOFCOMP %SYSTEMROOT%\System32\WindowsVirtualization.V2.mof’ from Command Prompt to fix this…..
Seemed to happen after I installed the HPE ProLiant Support Pack!

Worked for me after the broken KB5009624. Thanks @jamiet147 !

did not work for me :(

@JorgeCarousel

I’m having the same problem, only I’m trying to connect o a Hyper-V Server 2019 from a Windows 11 22H2, the first solution didn’t work because there is no vmcompute in the list and for the second solution I get WindowsVirtualization.V2.mof doesn’t exist, it was working properly before I updated Windows 11 to version 22H2, I even re-installed the Hyper-V Management Tools, but the service to manage Hyper-V Servers is not in services anymore.

Any ideas?

@ParveenKumar87

Worked for me as well :) 👍

@Vazelin117

@henskjold73

@cacafaca

I had to run ‘MOFCOMP %SYSTEMROOT%\System32\WindowsVirtualization.V2.mof’ from Command Prompt to fix this…..

Seemed to happen after I installed the HPE ProLiant Support Pack!

Confirming cause and solution! 👏👏👏 Fixed on HP ProLiant DL385p Gen8 / Windows Server 2022. 👍

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

Роль стоит на нем, диспетчер запускается там же, но при подключении получаем ошибку:

Произошла ошибка при попытке подключения к серверу «SERVER-HV». Убедитесь, что служба управления виртуальной машиной запущена и у вас есть необходимые полномочия для подключения к серверу.

Произошла ошибка Hyper-V при попытке доступа к объекту на компьютере «SERVER-HV», так как объект не найден. Возможно, он удален. Убедитесь, что на компьютере запущена служба управления виртуальными машинами.

Проверил, служба запущена. Та же ошибка возникает при попытке получить список виртуальных машин через powershell.

При этом виртуальные машины работают исправно.

В логах нашлось только два предупреждения:

Имя журнала:   Microsoft-Windows-Hyper-V-Hypervisor-Operational
Источник:      Microsoft-Windows-Hyper-V-Hypervisor
Код события:   12550
Описание:
Hyper-V detected access to a restricted MSR (Msr: 0x1B2, IsWrite: 0x0, MsrValue: 0x0, AccessStatus: 0x0, Pc: 0xFFFFF8039A35160C, ImageBase: 0xFFFFF8039A350000, ImageChecksum: 0x1A895, ImageTimestamp: 0x577D3625, ImageName: ALSysIO64.sys).

Имя журнала:   Microsoft-Windows-Hyper-V-VMMS-Admin
Источник:      Microsoft-Windows-Hyper-V-VMMS
Код события:   14090
Описание:
Служба управления виртуальными машинами завершает работу, в то время как некоторые виртуальные машины начинают работу. Все запущенные виртуальные машины продолжат работу без доступа на управление.

Куда копать, как восстанавливать работу? 

Сервер боевой, можно ли переустановить службу Hyper-V без потерь (виртуальные машины, настройки виртуального коммутатора)? 

Сегодня при попытке подключиться Диспетчером Hyper-V к хосту Hyper-V получил ошибку: 

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

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

Погуглив немного, так и не нашел решения данной странной проблемы: две Hyper-V машины в домене AD, один хост Hyper-V принимает подключение под учеткой администратора домена, когда учетные данные администратора домена вводятся непосредственно при коннекте к Hyper-V серверу, другой — не дает подключиться. Предлагаются различные решения: проверить настройки брандмауера, перезагрузить службу удаленного управления управления Windows (WinRM) — но ни одно не помогает. К тому же когда я пытаюсь подключиться к несговорчивому хосту Hyper-V, используя 5-nine Manager, коннект проходит. Мне функционал 5-nine Manager-а не достаточен, так как пользуюсь его бесплатной версией, а она не умеет делать перемещения виртуальных машин. Microsoft в своем продукте диспетчер Hyper-V за подобный функционал не просит денег.

Решение было найдено следующее. Сделал все гораздо проще. Запускаю FAR от администратора домена (runas …). Far-ом пользуюсь потому, что он хранит историю введенных команд — это удобно, когда ситуации и решения повторяются. Вбиваю в командную строку в Far-е команду для запуска Диспетчера Hyper-V:

%windir%\System32\mmc.exe «%windir%\System32\virtmgmt.msc»

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

Проблема решена!



Автор:

Marcus Baldwin


Дата создания:

19 Июнь 2021


Дата обновления:

16 Сентябрь 2023


Работа с Hyper-V в Windows Server 2019 Core (Work with Hyper-V in Windows Server 2019 Core)

Видео: Работа с Hyper-V в Windows Server 2019 Core (Work with Hyper-V in Windows Server 2019 Core)

Успешно развернутой инфраструктурой Hyper-V можно управлять с помощью Hyper-V Manager или Windows Admin Center. Это можно сделать локально или удаленно, но во многих случаях удаленное управление является более эффективным способом, особенно если у нас больше серверов. Начиная с Windows 8, Microsoft интегрировала клиент Hyper-V в редакции операционной системы Professional и Enterprise (Windows 8, Windows 8.1 и Windows 10). Это дает дополнительную гибкость, поскольку вам как ИТ-администратору нужно делать это не с Windows Server, а с вашего клиентского компьютера Windows.

Процедура подключения к удаленному серверу Hyper-V проста. Все, что нам нужно, это открыть диспетчер Hyper-V и подключиться к удаленному серверу виртуализации, нажав на Подключиться к серверу… в правой части консоли Hyper-V Manager.

Некоторые ИТ-администраторы испытывают проблемы при подключении с клиента Windows к удаленному серверу Hyper-V. Эта проблема может возникнуть по разным причинам, но в этой статье мы поговорим об отсутствии доверия между исходной и целевой машиной. Ошибка известна как: «Произошла ошибка при попытке подключиться к серверу «ServerName». Убедитесь, что служба управления виртуальными машинами запущена и что у вас есть права на подключение к серверу. Не удалось подключиться к удаленному серверу: клиент WinRM не может обработать запрос. Компьютерная политика не позволяет делегировать учетные данные пользователя на целевой компьютер… » как показано на скриншоте ниже.

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

Разрешить делегирование новых учетных данных с аутентификацией сервера только NTLM

Включение доверия на клиентском компьютере Windows может быть выполнено через графический интерфейс или Powershell. В этой статье мы сделаем это с помощью редактора локальной групповой политики (GUI). Политика называется Разрешить делегирование новых учетных данных с аутентификацией сервера только NTLM. Этот параметр политики применяется к приложениям, использующим компонент Cred SSP (например, подключение к удаленному рабочему столу). Протокол поставщика поддержки безопасности учетных данных (CredSSP) — это провайдер аутентификации, который обрабатывает запросы аутентификации для других приложений. Если вы включите этот параметр политики, вы можете указать серверы, на которые могут быть делегированы новые учетные данные пользователя (новые учетные данные — это те, которые вам предлагается ввести при запуске приложения). Если вы не настроили (по умолчанию) этот параметр политики, после надлежащей взаимной аутентификации делегирование новых учетных данных разрешено узлу сеанса удаленного рабочего стола, запущенному на любом компьютере (TERMSRV / *). Если вы отключите этот параметр политики, делегирование новых учетных данных не разрешено ни одному компьютеру. В нашем примере мы включим политику на исходном компьютере Windows, с которого мы подключаемся к удаленному серверу Hyper-V. Итак, начнем.

  1. Щелкните правой кнопкой мыши на Стартовое меню и найдите редактор групповой политики, набрав gpedit
  2. открыто Изменить групповую политику
  3. Перейдите к Настройки компьютера> Административные шаблоны> Система> Делегирование учетных данных
  4. Дважды щелкните на Разрешить делегирование новых учетных данных с аутентификацией сервера только NTLM
  5. Активируйте политику, нажав на включить
  6. Нажмите Шоу… следующий на Добавить серверы в список
  7. Щелкните поле и введите имя сервера WSMAN / Hyper-V. В нашем примере сервер называется hyperv01, поэтому мы введем wsman / hyperv01.
  8. Нажмите хорошо чтобы подтвердить
  9. Нажмите Подать заявление а потом хорошо

По умолчанию групповая политика компьютера обновляется в фоновом режиме каждые 90 минут со случайным смещением от 0 до 30 минут. Поскольку мы не хотим этого ждать, мы принудительно выполним обновление с помощью CMD или Powershell. Пожалуйста, следуйте приведенной ниже процедуре. Также мы можем изменить интервал обновления для групповой политики, начиная с 0 минут до 31 дня.

  1. Щелкните правой кнопкой мыши на Стартовое меню и открыть Windows PowerShell (администратор) или Командная строка (администратор)
  2. Нажмите да к Подтвердить открытие в качестве администратора
  3. Тип gpupdate / force и нажмите. Политика будет обновлена ​​через несколько секунд.
  4. открыто Диспетчер Hyper-V на клиентской машине Windows
  5. Нажмите на Подключиться к серверу… в правой части консоли Hyper-V Manager
  6. Введите имя сервера Hyper-V 2019 в поле Другой компьютер, Выбрать Подключитесь как другой пользователь. а затем нажмите на Установить пользователя…. В нашем примере мы подключаемся к удаленному серверу Hyper-V, который называется hyperv01
  7. Введите имя пользователя и пароль. Имя пользователя должно быть в формате или . В нашем примере мы используем имя сервера hyperv01 Администратор.
  8. Нажмите хорошо а потом хорошо очередной раз
  9. Вы успешно подключились к удаленному серверу Hyper-V
  10. Наслаждайтесь игрой со своими виртуальными машинами

После обновления Windows 10 (в моём случае до 10.0.16299.64), при попытке подключиться к серверам виртуализации через Диспетчер Hyper-V я стал получать ошибку «RPC сервер недоступен. Не удается установить соединение…». Решение оказалось каким-то неочевидным и неожиданным — виноват был брандмауэр. Для исправления следует сделать следующее:
Параметры — Сеть и Интернет — Брандмауэр Windows — Дополнительные параметры; в отрывшемся окне «Монитор брандмауэра Защитника Windows» в разделе «Правила для входящих подключений» надо включить правило «Инструментарий управления Windows (асинхронный — входящий трафик)» для соответствующего профиля (в моём случае — «Домен»).
После этой манипуляции всё заработало. Что примечательно — после отключения этого правила, работоспособность диспетчера Hyper-V сохранилась. Глубоко копать не хватило времени и мотивации, но подозреваю, что входящее подключение нужно было для обновления каких-то параметров оснастки диспетчера.
UPD 2018-04-10: на самом деле через какое-то время (пара недель) после отключения правила, оснастка опять стала выдавать ту же ошибку — видимо, предполагаемое обновление (и разрешающее правило) нужно достаточно часто.

Понравилась статья? Поделить с друзьями:
  • Произошла ошибка при подключении к серверам albion online
  • Произошла ошибка при подключении к сеансу гта 5
  • Произошла ошибка при подключении к сборщику glpi
  • Произошла ошибка при подключении к менеджеру лицензий 1с
  • Произошла ошибка при подключении к кластеру