Failed to connect pipe to virtual machine не удается найти указанный файл

Обновлено: 07.07.2024

mr_orangeV прислал заметку о решение проблемы с VMDB transport.

После обновления ESXi до версии 6.7 сборка 17499825 и вывода хоста из режима обслуживания, виртуальные машины не мигрировали обратно на хост с ошибкой:

Поиск корневых причин привёл к нескольким вариантам:

Как найти реальную причину?

Для начала прочитать все, что написано в комьюнити и БЗ: ссылка 01 и ссылка 02 kb 50113127.

В моём случае эти команды не показали ничего, а команды ls -l /bin/vmx в kb нет.

Подключаемся к хосту по SSH и GUI, смотрим:

В моем случае, это оказался неудаленный полностью Unlocker.

Шаги решения

cd /bin
ls -l /bin/vmx и посмотреть куда он ведет
cd /куда ведет симлинк и
ls посмотреть на наличие vmx и unlocker
cd /bin
rm vmx – удалилить симлинк
cp /откуда)/vmx /bin

Материалы для внеклассного чтения

ESXi host becomes unresponsive when attempting a vMotion migration or a configuration change (2040707)

Powering on or migrating a virtual machine fails with error: Transport (VMDB) error -45: Failed to connect to peer process. (50113127)

Почитать про аналогичные случаи и как их пытались решать в комьюнити

Transport (VMDB) error -45: Failed to connect to peer process

Transport (VMDB) error -45: Failed to connect to peer process.

Мораль для тех, кто дочитал

Проверяйте IPMI и SSH доступ к хосту до начала работ. В том числе, что есть KVM, а ISO монтируется. Это не всегда так для старых серверов.

Планируйте время с запасом.

Планируйте запасной вариант и план отката, на случай, если что-то пойдет не так.

Учитывайте, что откат обновления у VMware крайне интересен (и прочитайте еще раз про IPMI).

Добавить комментарий Отменить ответ

Я не расист. но после того как VMware стала упралвяться и поддерживаться индусами, стабильность продукта сдохла как бобик.

Перейти с Порше на Жигули - такое себе решение!

Мысли в слух " а может перейти на proxmox " Что-то в последняя время ESXi не стабильно стал по обновлениям.…

Сегодня вылезла ошибка «Unable to connect to the MKS: Could not connect to pipe .pipevmware-authdpipe within retry period.» при попытке подключиться к консоли виртуальной машины VMware.

В моем случае причина была в том, что на хосте Esxi неправильно указан шлюз по умолчанию на интерфейсе VMkernel. Увидеть это можно, перейдя по вкладкам «Configuration»>>»Networking» проблемного хоста и выбрать свойства виртуального свича, на котором настроен интерфейс Management Network.

Вводим правильный адрес нашего шлюза и закрываем окна нажатием «Ок».

После этого доступ к консоли появился.

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

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

Также, ошибка возможна, если закрыт порт 902 или если есть проблемы с разрешением имен ДНС.

mr_orangeV прислал заметку о решение проблемы с VMDB transport.

Поиск корневых причин привёл к нескольким вариантам:

Как найти реальную причину?

Для начала прочитать все, что написано в комьюнити и БЗ: ссылка 01 и ссылка 02 kb 50113127.

В моём случае эти команды не показали ничего, а команды ls -l /bin/vmx в kb нет.

Подключаемся к хосту по SSH и GUI, смотрим:

В моем случае, это оказался неудаленный полностью Unlocker.

Шаги решения

cd /bin
ls -l /bin/vmx и посмотреть куда он ведет
cd /куда ведет симлинк и
ls посмотреть на наличие vmx и unlocker
cd /bin
rm vmx – удалилить симлинк
cp /откуда)/vmx /bin

Материалы для внеклассного чтения

ESXi host becomes unresponsive when attempting a vMotion migration or a configuration change (2040707)

Powering on or migrating a virtual machine fails with error: Transport (VMDB) error -45: Failed to connect to peer process. (50113127)

Почитать про аналогичные случаи и как их пытались решать в комьюнити

Transport (VMDB) error -45: Failed to connect to peer process

Transport (VMDB) error -45: Failed to connect to peer process.

Мораль для тех, кто дочитал

Планируйте время с запасом.

Планируйте запасной вариант и план отката, на случай, если что-то пойдет не так.

Учитывайте, что откат обновления у VMware крайне интересен (и прочитайте еще раз про IPMI).

Добавить комментарий Отменить ответ

Перейти с Порше на Жигули - такое себе решение!

Мысли в слух " а может перейти на proxmox " Что-то в последняя время ESXi не стабильно стал по обновлениям.…

Почему это происходит? Это может произойти, если у вас внезапно отключилось электричество или ваша виртуальная машина не выключилась. Не только это, как выясняется, в некоторых случаях проблема также может быть сгенерирована после того, как ваша виртуальная машина выйдет из строя, и вы попытаетесь снова включить ее. Возникает вопрос: почему виртуальная машина заблокирована или заблокирована? Чтобы пролить свет на это, давайте более подробно рассмотрим, как работают виртуальные машины VMware, а затем перейдем к решению ошибки.

Файлы блокировки VMware

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

VMware

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

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

Удаление файлов блокировки VMware вручную

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

Прежде всего, убедитесь, что ваша виртуальная машина выключена. Если это не так, выключите его, щелкнув виртуальную машину правой кнопкой мыши и выбрав Power> Power Off.
Как только вы это сделаете, нам нужно будет перейти в каталог, в котором находится виртуальная машина. Для этого снова щелкните виртуальную машину правой кнопкой мыши и выберите параметр «Открыть каталог виртуальной машины».Открытие каталога виртуальной машины
Это приведет вас в каталог, в котором существует виртуальная машина, а также избавит вас от необходимости искать ее вручную через проводник Windows.
Внутри каталога удалите папки с расширением .lck. Вы также можете просто переименовать их во что-то другое или переместить из этого пункта назначения в другое место.Файлы блокировки VMware
Как только вы это сделаете, снова откройте VMware и попробуйте включить виртуальную машину.
Теперь ваша виртуальная машина должна включиться без каких-либо проблем.

Читайте также: