Vsphere client базовое соединение закрыто непредвиденная ошибка при передаче

Обновлено 23.05.2019

Добрый день! Уважаемые читатели и гости IT блога Pyatilistnik.org. В прошлый раз мы с вами научились устанавливать гипервизор Vmware ESXI 6.5. Сегодня я покажу, как решается ошибка vsphere client could not connect to vcenter server при попытке соединиться с vCenter. Вот согласитесь, что всегда испытываешь некий дискомфорт, когда какая-то консоль управления серверами или кластерами у тебя не запускается, понятное дело, что простые хосты продолжают работать, но в такие моменты вы теряете кучу функционала, который может потребоваться в любой момент.

Данная ошибка в большинстве случаев выскакивает из за, того что у вас банально не запущена служба vCenter.

vsphere client could not connect to vcenter server при попытке соединиться с vCenter.

Зайдя в Администрирование-Службы запустите ее и все будет огонь:). Служба называется «VMware VirtualCenter Server», кстати очень легко, это сделать и через командлеты PowerShell Get-Service vcenter | Restart-Service.

vmware vcenter service restart

Еще возможные причины:

Убедитесь, что вы используете ту же версию VMWare ESXi Server & Client. Версия VMware vCenter Server и VSphere Client должны совпадать.
Требуется последняя версия Microsoft .Net Framework или версия .Net Framework, вызывающая проблему.
Проверьте настройки прокси (если установлены), сброс настроек вызывает проблемы в соединении.
Перезагрузите компьютер, на котором установлен Vsphere Client
Убедитесь, что вы подключаетесь с правильным именем пользователя и паролем. Часто указывается неправильное имя пользователя или пароль, что приводит к сбою входа в систему с ошибкой: не удается завершить вход в систему из-за неверного имени пользователя или пароля.
Убедитесь, что вы подключаетесь к правильному имени хоста или IP-адресу для вашего vCenter Server. Не удалось установить соединение, поскольку из-за неверной информации о сервере проблема может показаться более сложной, чем она есть. Исправьте все неправильные имена и попробуйте подключиться к vCenter Server с помощью клиента vSphere. Если соединение не удается с использованием имени хоста, но успешно с IP-адресом, вероятно, это ошибка DNS, которую необходимо починить.

В большинстве случаев помогает. Материал сайта Pyatilistnik.org

Май 23, 2019 23:47

Источник

Remove From My Forums

Вопрос
При настройке WAP возникает ошибка: Базовое соединение закрыто: При попытке установления отношений доверия со службой федерации произошла
ошибка. Ошибка: Базовое соединение закрыто: Непредвиденная ошибка при передаче.. ADFS установлен и настроен. Сертификат был импортирован с закрытым ключом и содержит 3 имени (имя сервера wap, adfs и имя службы ADFS). Все
имена серверов используется внутренние. Трафик между хостами полностью разрешен. Может
кто сталкивался?

Ответы

- Помечено в качестве ответа
  
  6 февраля 2017 г. 7:31
1. Для имени AD FS при установке WAP нужно использовать msk-i-ca-adfs.internet.lan — именно это значение прописано в хостовой части URL, идентифицирующего ферму AD FS (Identifier). Хотя, если SNI при связи WAP-AD FS не используется
(как посмотреть это, я не знаю), может пройти и adfs.internet.lan.

2. Сертификат Service Communication у вас выглядит сомнительно. Чтобы сертификат был действительным для нескольких имён DNS, они должны быть добавлены в расширение Subject Alternative Name (к сожалению, его в выдаче не видно) ,
а в Subject Name в части CN=… (Common Name) должно быть указано только одно, основное имя.

3. Сертификат SSL на сервере AD FS я вообще не увидел. Обычно он совпадает с Service Communication Certificate, но у вас почему-то не так (Thumbprint не совпадает). Так что смотрите на него сами (certutil -dump файл_сертификата). Требования
там по именам те же: «основное» имя DNS в Common Name из Subject Name, а все остальные (можно — вместе с основным) — в Subject Alternate Name.

Слава России!
- Помечено в качестве ответа
  Petko KrushevMicrosoft contingent staff, Moderator
  6 февраля 2017 г. 7:31

Источник

Ошибка при конфигурации сервера через мастер конфигурации: Базовое соединение закрыто. Непредвиденная ошибка при передаче/приеме. Взаимодействие клиента и сервера невозможно, т.к. у них разный алгоритм работы.

Проблема встречается, если принудительно отключить протоколы старых версий SSL, TLS, например через GPO.

Варианты ошибок:

Решение:

Включение TLS1.0, TLS1.1, TLS1.2 и настройка strong cryptography для .NET Framework: https://docs.microsoft.com/en-us/mem/configmgr/core/plan-design/security/enable-tls-1-2-server#bkmk_net

Добавление веток реестра:

[HKEY_LOCAL_MACHINESOFTWAREMicrosoft.NETFrameworkv2.0.50727]
«SystemDefaultTlsVersions» = dword:00000001
«SchUseStrongCrypto» = dword:00000001

[HKEY_LOCAL_MACHINESOFTWAREMicrosoft.NETFrameworkv4.0.30319]
«SystemDefaultTlsVersions» = dword:00000001
«SchUseStrongCrypto» = dword:00000001

[HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoft.NETFrameworkv2.0.50727]
«SystemDefaultTlsVersions» = dword:00000001
«SchUseStrongCrypto» = dword:00000001

[HKEY_LOCAL_MACHINESOFTWAREWOW6432NodeMicrosoft.NETFrameworkv4.0.30319]
«SystemDefaultTlsVersions» = dword:00000001
«SchUseStrongCrypto» = dword:00000001

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.0Client]
«Enabled»=dword:ffffffff
«DisabledByDefault»=dword:00000000

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.0Server]
«Enabled»=dword:ffffffff
«DisabledByDefault»=dword:00000000

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.1Client]
«Enabled»=dword:ffffffff
«DisabledByDefault»=dword:00000000

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.1Server]
«Enabled»=dword:ffffffff
«DisabledByDefault»=dword:00000000

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.2Client]
«Enabled»=dword:ffffffff
«DisabledByDefault»=dword:00000000

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.2Server]
«Enabled»=dword:ffffffff
«DisabledByDefault»=dword:00000000

Примечание: Данные настройки могут быть сброшены GPO!

Источник

Блог посвященный системному администрированию

27 сент. 2012 г.

vSphere Client не может подключиться к ESXi

Вы вводите заведомо валидные данные, и после паузы выпрыгивает ошибка типа такой:

The server ‘my.host.name’ could not interpret the client’s request. (The remote server returned an error: (503) Server Unavailable
Call «ServiceInstance.RetrieveContent» for object «ServiceInstance» on Server «my.host.name» failed.

При это с помощью SSH нормально можно зайти на хост. Точнее, нужно зайти и выполнить команду:

После завершения всех действий команды (когда вы опять увидите приглашение командной строки) можно будет снова зайти на ESXi гипервизор с помощью vSphere Client.

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

«vSphere Client не удалось подключиться к» IP-адресу «. Произошла неизвестная ошибка подключения. (Клиент не смог отправить полный запрос на сервер. (Основное соединение было закрыто: при отправке произошла непредвиденная ошибка.))

Я думаю, что это может иметь какое-то отношение к несовместимости версии, но я не уверен. Может кто-то пролил свет?

5 ответов

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

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

Я отключил эту проверку (полагаясь вместо этого на pings), и эта проблема не вернулась уже почти год.

Я предполагаю, что есть параметр безопасности где-то под капотом ESXi 4.x, который сообщает системе прекратить отвечать после указанного количества запросов, но я не смог найти это.

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

Я попробовал обновление до самых последних версий ESXi, но это не решило проблему.

vSphere client перестал коннектиться к ESXi 5.5. Текст ошибки:

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

Сервер с гипервизором пингуется. Делал telnet 443. Результат — черное окно командной строки.

Все виртуальные машины работают, пингуются и доступны по портам ssh, 443, 80, rdp.

Источник

Раздел: Советы
Написано: 26.06.2014

Автор: Antonio

Давно хотел описать решение проблемы — клиент VMware vSphere Client на Windows XP не подключается к ESXi 5.5, происходит ошибка.

vSphere Client not connect

Оказывается старые операционные системы Windows XP, Windows 2003 не поддерживают необходимые алгоритмы шифрования.

Для Windows 2003 сделали патчи, которые создают возможности подключения, а вот для Windows XP в VMware vSphere® 5.5 Release Notes пишут что решение ошибки подключения — это обновить ОС хотя бы до Windows Vista и выше.

На просторах инета умельцы нашли решение — оно простое и эффективное (хотя конечно давно пора использовать Windows 7 :-) ) — нужно лишь немного подправить конфиг гипервизора.