Vpxa vmware что это
ИТ База знаний
Полезно
— Онлайн генератор устойчивых паролей
— Онлайн калькулятор подсетей
— Руководство администратора FreePBX на русском языке
— Руководство администратора Cisco UCM/CME на русском языке
— Руководство администратора по Linux/Unix
Навигация
Серверные решения
Телефония
FreePBX и Asterisk
Настройка программных телефонов
Корпоративные сети
Протоколы и стандарты
Рестарт Management Agents в ESXi
Сегодня в статье мы расскажем как перезапустить Агентов Управления (Management agents) в ESXi.
Интенсив по Виртуализации VMware vSphere 7
Самое важное про виртуализацию и VMware vSphere 7 в 2-х часовом онлайн-интесиве от тренера с 30 летним стажем. Для тех, кто начинает знакомство с виртуализацией и хочет быстро погрузиться в предметную область и решения на базе VMware
Это может быть необходимо в случае если невозможно подключение напрямую к хосту ESXi или управление с помощью vCenter Server или если vCenter Server отображает сообщение об ошибке: Virtual machine creation may fail because agent is unable to retrieve VM creation options from the host (создание ВМ может потерпеть неудачу, из-за невозможности получения параметров создания виртуальных машин с хоста).
Решение
Для устранения неполадок с подключением ESXi перезапустите Агентов Управления на хосте ESXi
Предупреждение: если LACP настроен на сеть VSAN не перезагружайте Агентов Управления при хостах ESXi под управлением vSAN.
Перезапустите Агентов Управления ESXi используя Direct Console User Interface (DCUI)
Примечание: Вы можете также перезапустить службы с помощью Host Client. В Host Client выберите Host>> Manage>> Services и Restart (Хост >> Управление >> Услуги) и выберите услугу перезапуска.
Перезапуск Агентов Управления с помощью ESXi Using ESXi Shell или Secure Shell (SSH)
Интенсив по Виртуализации VMware vSphere 7
Самое важное про виртуализацию и VMware vSphere 7 в 2-х часовом онлайн-интесиве от тренера с 30 летним стажем. Для тех, кто начинает знакомство с виртуализацией и хочет быстро погрузиться в предметную область и решения на базе VMware
Виртуализация vSphere, Hyper-V, Xen и Red Hat
Более 5550 заметок о виртуализации, виртуальных машинах VMware, Microsoft и Xen, а также Kubernetes
Хотя бы раз у каждого администратора VMware vSphere была такая проблема, когда один или несколько хостов VMware ESXi в консоли vSphere Client на сервере vCenter отображались в статусе Not Responding. Причин для этого может быть масса, сегодня мы постараемся разобрать наиболее частые из них.
1. Прежде всего, надо убедиться, что хост ESXi находится во включенном состоянии.
Желательно убедиться в этом как физически (сервер включен в стойке), так и взглянуть на его консоль (например, через iLO/iDRAC). Ситуация может быть такой, что хост выпал в PSOD (Purple Screen of Death, он же Purple Diagnostic Screen).
В этом случае с хостом надо разбираться в соответствии со статьей KB 1004250 и повторно добавлять его к серверу vCenter, когда он успешно загрузится.
2. Если хост ESXi включен, но все еще находится в статусе Not Responding, надо попробовать перезапустить там Management agents (операция Restart Management Network).
Они включают в себя сервисы по коммуникации между сервером vCenter и хостом ESXi. Делается это в соответствии со статьей KB 1003490.
Казалось бы очевидный шаг, который не все выполняют первым при первичной диагностике. Просто сделайте пинг хоста ESXi со стороны сервера vCenter:
4. Убедитесь, что со стороны сервера ESXi также виден сервер vCenter.
Дело в том, что vCenter ожидает регулярных хартбитов со стороны хостов ESXi, чтобы считать их подключенными. Если в течение 60 секунд он не получает таких хартбитов, то он объявляет хост ESXi Not Responding, а в конечном итоге и Disconnected.
Иногда такое состояние возникает, когда сервер vCenter спрятан за NAT относительно хостов ESXi:
В этом случае серверы ESXi не смогут достучаться до сервера vCenter. Более того, такая конфигурация вообще не поддерживается со стороны VMware (см. статью KB 1010652), несмотря на то, что для нее существует workaround.
Проверить коммуникацию по порту 902 можно с помощью Telnet.
Также тут вам могут помочь следующие статьи базы знаний VMware:
Кстати, таймаут в 60 секунд для хартбитов можно увеличить, например, до 120 секунд, если у вас большие задержки в сети. Для этого нужно изменить значение параметра config.vpxd.heartbeat.notrespondingtimeout в расширенных настройках сервера vCenter, как описано в статье KB 1005757.
5. Попробуйте убрать хост ESXi из инвентори vCenter и добавить его снова.
Делается это в соответствии со статьей KB 1003480. Просто выберите для хост ESXi в контекстном меню vSphere Client опцию Disconnect:
Потом просто добавьте хост ESXi в окружение vCenter снова.
В первую очередь надо посмотреть в лог агента vpxa ( /var/log/vpxa.log ), как описано в статье KB 1006128. Например, причиной того, что агент vpxa не стартует может оказаться нехватка памяти, выделенной для сервисов ESXi. Тогда в логе vpxa будет что-то вроде этого:
[2007-07-28 17:57:25.416 ‘Memory checker’ 5458864 error] Current value 143700 exceeds hard limit 128000. Shutting down process.
[2007-07-28 17:57:25.420 ‘Memory checker’ 3076453280 info] Resource checker stopped.
Также нужно убедиться, что процесс hostd работает и отвечает на команды. Для этого можно заглянуть в лог hostd ( /var/log/vmware/hostd.log ), как описано в KB 1002849. Например, там может быть вот такая ошибка:
2014-06-27T19:57:41.000Z [282DFB70 info ‘Vimsvc.ha-eventmgr’] Event 8002 : Issue detected on sg-pgh-srv2-esx10.sg-pgh.idealcloud.local in ha-datacenter: hostd detected to be non-responsive
Если все остальное уже посмотрели, то нужно обязательно отработать вариант с неполадками хранилища на хосте ESXi. Основные рекомендации по этому случаю даны в KB 1003659. Диаграмма траблшутинга в этом случае выглядит следующим образом (кликабельно):
Вывод
Если ваш хост ESXi перешел в статус Not Responding или Disconnected, попробуйте сначала такие простые действия, как проверка включенности самого ESXi, пинг хостов vCenter и ESXi в обе стороны (не забыв также порт 902), рестарт Management agents, передобавление хоста ESXi в инвентори. Потом посмотрите более сложные варианты, такие как работоспособность агента vpxa и сервиса hostd. Ну а потом уже проверяйте работу хранилищ на ESXi, где может быть много всякого рода проблем.
Вебинары VMC о виртуализации:
Постер VMware vSphere PowerCLI 6.3: 
Постер VMware ESXi 5.1: 
Постер VMware Hands-on Labs 2015: 
Постер VMware Platform Services Controller 6.0: 
Постер VMware vCloud Networking: 
Постер VMware NSX (референсный): 
Постер VMware vCloud SDK: 
Постер VMware vCloud Suite: 
Постер VMware vCenter Server Appliance: 
Порты и соединения VMware vSphere 6:
Порты и соединения VMware Horizon 7: 
Порты и соединения VMware NSX: 
Управление памятью в VMware vSphere 5:
Как работает кластер VMware High Availability: 
Постер VMware vSphere 5.5 ESXTOP (обзорный): 
Постер Veeam Backup & Replication v8 for VMware: 
Постер Microsoft Windows Server 2012 Hyper-V R2: 
#mytweets
Top Clicks
an IT blog.. and an occasional rant
hostd is an app that runs in the Service Console that is responsible for managing most of the operations on the ESX machine. It knows about all the VMs that are registered on that host, the luns/vmfs volumes visible by the host, what the VMs are doing, etc. Most all commands or operations come down from VC through it. i.e, powering on a VM, VM vMotion, VM creation, etc.
vpxa also runs on the Service Console and talks to VC. I believe it acts as an intermediary between VC and hostd. I think it also does some housekeeping on the ESX host, but not as much as hostd.
Vmware hostd and vpxa on ESXi 5.X
The vmware-hostd management service is the main communication channel between ESX/ESXi hosts and VMkernel. If vmware-hostd fails, ESX/ESXi hosts disconnects from vCenter Server/VirtualCenter and cannot be managed, even if you try to connect to the ESX/ESXi host directly. It knows about all the VMs that are registered on that host, the luns/vmfs volumes visible by the host, what the VMs are doing, etc. Most all commands or operations come down from VC through it. i.e, powering on a VM, VM vMotion, VM creation, etc.
Restart the vpxa service
VPXD-It is Vcenter Server Service. If this service is stopped then we will not able to connect to Vcenter Server via Vsphere client.
VPXA-It is the agent of Vcenter server. also known as mini vcenter server which is installed on the each esx server which is managed by Vcenter server. What are the management action we are performing on top of the vcenter server. (Like:- Increasing/Decreasing RAM & HDD, Making any type of changes in cluster, doing vmotion. This agent collects all information from the vcenter server and pass this information to the kernal of the esx server.
HOSTD- This is the agent of ESX server, here VPXA pass the information to the HOSTD and hostd pass the information to ESX server.
In ESX, you have only hostd and (if you have vCenter) vpxa.
These are daemon (services) for remote management:
hostd is the daemon for direct VIC connection (when you use Virtual Infra Client (VIC) to connect to your ESX).
Виртуализация vSphere, Hyper-V, Xen и Red Hat
Более 5550 заметок о виртуализации, виртуальных машинах VMware, Microsoft и Xen, а также Kubernetes
Виртуализация VMware vSphere / ESX / ESXi, VMware View, VMware Workstation и др.
Давайте посмотрим, что нового появилось в мобильном клиенте за последнее время:
Скачать обновленный vSphere Mobile Client 1.9.1 можно по этим ссылкам:
Также не забудьте посмотреть инструкцию о развертывании Notification Service (он доступен как Docker-контейнер), чтобы включить Push-уведомления на своих устройствах.
Недавно компания Microsoft объявила о том, что мартовские обновления Windows в этом году затронут поведение серверов Microsoft LDAP (доменных контроллеров), которые являются частью сервисов Active Directory. Эти изменения заключаются в том, что теперь механизмы LDAP channel binding и LDAP signing будут включаться по умолчанию, а для уже существующих инсталляций дефолтные настройки изменятся. На это обратил внимание один из наших читателей, который дал ссылку на соответствующую статью коллег из компании VMware.
Это, конечно же, затрагивает и платформу VMware vSphere, компоненты которой могут использовать как обычный протокол LDAP (ldap://), так и защищенный LDAPS (ldaps://) для соединения со службами Active Directory. Также VMware vSphere поддерживает и механизм аутентификации Integrated Windows Authentication (IWA), который не затрагивают грядущие изменения.
Если вы уже настроили ваш vCenter Server для доступа к Active Directory через LDAP с TLS (LDAPS) или через механизм IWA, то вам не стоит бояться обновлений (если эти соединения идут не через балансировщики или прокси-серверы).
Как мы видим из трех источников идентификации по ldap только один использует TLS и будет работать после апдейтов, а вот первые два источника требуют перенастройки.
После мартовских обновлений при логине в vSphere Client через аккаунты Active Directory вы можете получить вот такую ошибку:
Invalid Credentials
При попытке добавить или изменить Identity Source в vCenter вы получите вот такую ошибку:
Check the network settings to make sure you have network access to the identity source
Поэтому попытаться сделать нужные настройки (хотя бы в изолированной от производственного окружения среде) нужно уже сейчас. Тем более, что vCenter позволяет одновременно использовать несколько Identity Sources.
Для того, чтобы настроить и протестировать LDAP Channel Binding & Signing можно использовать следующие материалы:
Надо понимать, что обновление этих политик затронет не только инфраструктуру VMware vSphere, но и все остальные сервисы, использующие LDAP, поэтому процесс этот нужно тщательно спланировать. Кстати, если вы это будете делать для виртуальных машин с контроллерами домена в тестовой конфигурации, то можно сделать снапшот всего тестового окружения перед изменением конфигурации, чтобы откатиться к ним в случае, если вы что-то не предусмотрели (для производственной среды снапшоты контроллеров домена делать не стоит).
Чтобы проверить, что политики применились, можно использовать встроенную утилиту Windows ldp.exe. Запустите ее на контроллере домена и укажите адрес localhost и порт 389:
Дальше идите в меню Connection утилиты и выберите там пункт Bind, где нужно ввести креды доменного администратора и выбрать вариант Simple bind:
После этого вы должны увидеть ошибку » Error 0x2028 A more secure authentication method is required for this server «, которая говорит о том, что вы корректно отключили все небезопасные байндинги LDAP:
Если вы не получили такой ошибки, то значит настройки у вас еще не применились, и их надо проверить.
Далее скопируйте все данные между «—–BEGIN CERTIFICATE—» и «—–END CERTIFICATE—–», после чего сохраните это в текстовый файл.
Хотя бы раз у каждого администратора VMware vSphere была такая проблема, когда один или несколько хостов VMware ESXi в консоли vSphere Client на сервере vCenter отображались в статусе Not Responding. Причин для этого может быть масса, сегодня мы постараемся разобрать наиболее частые из них.
1. Прежде всего, надо убедиться, что хост ESXi находится во включенном состоянии.
Желательно убедиться в этом как физически (сервер включен в стойке), так и взглянуть на его консоль (например, через iLO/iDRAC). Ситуация может быть такой, что хост выпал в PSOD (Purple Screen of Death, он же Purple Diagnostic Screen).
В этом случае с хостом надо разбираться в соответствии со статьей KB 1004250 и повторно добавлять его к серверу vCenter, когда он успешно загрузится.
2. Если хост ESXi включен, но все еще находится в статусе Not Responding, надо попробовать перезапустить там Management agents (операция Restart Management Network).
Они включают в себя сервисы по коммуникации между сервером vCenter и хостом ESXi. Делается это в соответствии со статьей KB 1003490.
Казалось бы очевидный шаг, который не все выполняют первым при первичной диагностике. Просто сделайте пинг хоста ESXi со стороны сервера vCenter:
4. Убедитесь, что со стороны сервера ESXi также виден сервер vCenter.
Дело в том, что vCenter ожидает регулярных хартбитов со стороны хостов ESXi, чтобы считать их подключенными. Если в течение 60 секунд он не получает таких хартбитов, то он объявляет хост ESXi Not Responding, а в конечном итоге и Disconnected.
Иногда такое состояние возникает, когда сервер vCenter спрятан за NAT относительно хостов ESXi:
В этом случае серверы ESXi не смогут достучаться до сервера vCenter. Более того, такая конфигурация вообще не поддерживается со стороны VMware (см. статью KB 1010652), несмотря на то, что для нее существует workaround.
Проверить коммуникацию по порту 902 можно с помощью Telnet.
Также тут вам могут помочь следующие статьи базы знаний VMware:
Кстати, таймаут в 60 секунд для хартбитов можно увеличить, например, до 120 секунд, если у вас большие задержки в сети. Для этого нужно изменить значение параметра config.vpxd.heartbeat.notrespondingtimeout в расширенных настройках сервера vCenter, как описано в статье KB 1005757.
5. Попробуйте убрать хост ESXi из инвентори vCenter и добавить его снова.
Делается это в соответствии со статьей KB 1003480. Просто выберите для хост ESXi в контекстном меню vSphere Client опцию Disconnect:
Потом просто добавьте хост ESXi в окружение vCenter снова.
В первую очередь надо посмотреть в лог агента vpxa ( /var/log/vpxa.log ), как описано в статье KB 1006128. Например, причиной того, что агент vpxa не стартует может оказаться нехватка памяти, выделенной для сервисов ESXi. Тогда в логе vpxa будет что-то вроде этого:
[2007-07-28 17:57:25.416 ‘Memory checker’ 5458864 error] Current value 143700 exceeds hard limit 128000. Shutting down process.
[2007-07-28 17:57:25.420 ‘Memory checker’ 3076453280 info] Resource checker stopped.
Также нужно убедиться, что процесс hostd работает и отвечает на команды. Для этого можно заглянуть в лог hostd ( /var/log/vmware/hostd.log ), как описано в KB 1002849. Например, там может быть вот такая ошибка:
2014-06-27T19:57:41.000Z [282DFB70 info ‘Vimsvc.ha-eventmgr’] Event 8002 : Issue detected on sg-pgh-srv2-esx10.sg-pgh.idealcloud.local in ha-datacenter: hostd detected to be non-responsive
Если все остальное уже посмотрели, то нужно обязательно отработать вариант с неполадками хранилища на хосте ESXi. Основные рекомендации по этому случаю даны в KB 1003659. Диаграмма траблшутинга в этом случае выглядит следующим образом (кликабельно):
Вывод
Если ваш хост ESXi перешел в статус Not Responding или Disconnected, попробуйте сначала такие простые действия, как проверка включенности самого ESXi, пинг хостов vCenter и ESXi в обе стороны (не забыв также порт 902), рестарт Management agents, передобавление хоста ESXi в инвентори. Потом посмотрите более сложные варианты, такие как работоспособность агента vpxa и сервиса hostd. Ну а потом уже проверяйте работу хранилищ на ESXi, где может быть много всякого рода проблем.
Недавно мы писали о том, что компания VMware выпустила новую превью-версию настольной платформы виртуализации VMware Workstation Tech Preview 20H1. Одновременно с этим было выпущено превью платформы и для Mac OS VMware Fusion Tech Preview 20H1, которое получило новую функциональность работы с контейнерами с кодовым названием Project Nautilus.
Также бинарники, документация и ассеты переезжают на GitHub, где теперь есть удобный портал для скачивания продукта и получения дополнительной информации.
Давайте взглянем на основные новые возможности Fusion 2020 года:
Скачать VMware Fusion Tech Preview 20H1 по прямой ссылке можно отсюда. Портал со всеми материалами находится тут.
На VMware Labs вышло обновление Cross vCenter Workload Migration Utility версии 3.1
Давайте посмотрим на новые возможности утилиты:
Также появилась парочка багофиксов:
Напомним, что утилитой можно пользоваться через плагин в составе vSphere Client с интерфейсом на базе технологии HTML5, так и в отдельном графическом интерфейсе.
Скачать Cross vCenter Workload Migration Utility 3.1 можно по этой ссылке.
Компания VMware выпустила обновленное технологическое превью настольной платформы виртуализации VMware Workstation Tech Preview 20H1 (первая половина 2020 года). Это первый релиз в этом году, который, как правило, выходит в GA через 2-3 месяца после выхода превью.
Для того, чтобы Workstation работала на Windows 10 с этими фичами, потребуется следующее:
VMware предлагает на таких хостах потестировать пользователям включение/выключение виртуальной машины и базовые операции с ней, а также проверить запуск машин с предыдущих версий Workstation.
Скачать VMware Workstation Tech Preview 20H1 можно по этой ссылке. Также можно обсудить свой опыт работы с новой версией в специальном комьюнити. Кроме того, есть еще вот такой обзорный документ по новой версии (там есть информация об известных проблемах).
Новые постеры vRealize Network Insight Search Poster для SD-WAN & VeloCloud и Kubernetes
В конце ноября прошлого года мы писали о постерах, посвященных решению vRealize Network Insight и его очень широким возможностям поиска. Эти возможности позволяют находить нужные сущности и объекты в инфраструктуре VMware vSphere, NSX и прочих компонентах.
Вышедший в начале января постер vRealize Network Insight Search Poster for SD-WAN & VeloCloud показывает, какие поисковые шаблоны можно использовать для платформы SD-WAN (это технология купленной компании VeloCloud, которая реализует концепцию Software-Defined Networking в рамках WAN-сетей). Как некоторые из вас помнят, интеграция с решениями VeloCloud появилась в vRNI пятой версии.
Собственно, сам постер:
Итого все постеры по функциям поиска в решении vRNI вы можете скачать по этим ссылкам:
What’s new in VMware vRealize Log Insight 8.0
Очень полезная штука на VMware Labs: vSphere Software Asset Management (vSAM)
Утилита забирает все данные по API и генерирует отчет об использовании лицензий виртуальной инфраструктуре в формате PDF, который могут использовать администраторы, менеджеры и консультанты для целей отчетности, планирования и любых других.
Сама утилита vSAM представляет собой легковесное Java-приложение, которое может работать под Windows, Linux или Mac OS. Давайте посмотрим на его возможности:
Вот примеры сгенерированных отчетов:
Скачать утилиту VMware vSphere Software Asset Management Tool можно по этой ссылке.
Вчера мы писали про выпуск новой версии решения VMware App Volumes 4, предназначенного для распространения готовых к использованию приложений VMware ThinApp посредством подключаемых виртуальных дисков к машинам.
Одновременно с релизом этой платформы, на сайте проекта VMware Labs появилась новая утилита App Volumes Migration Utility, которая дополняет средства App Volumes по облегчению жизни администраторов, занимающихся обслуживанием решения.
Эта утилита позволяет смигрировать старые объекты AppStacks, в которых распространялись приложения в VMware App Volumes 2.18, на новый формат VMware App Volumes 4.0, который реализует концепцию приложений и пакетов. С помощью App Volumes Migration Utility можно сделать так, чтобы не потребовалось повторное развертывание приложений в среде App Volumes после миграции основного продукта.
Работать с утилитой просто. Вводим данные для входа:
Выбираем выходную файловую шару для пакетов:
Отмечаем доступные для миграции AppStacks и нажимаем кнопку Migrate:
Скачать App Volumes Migration Utility можно по этой ссылке.
Компания VMware выпустила новую версию решения App Volumes 4. Напомним, что решение App Volumes предназначено для распространения готовых к использованию приложений VMware ThinApp посредством подключаемых виртуальных дисков к машинам. О бета-версии четвертого поколения технологии App Volumes мы писали вот тут, а на днях вышел ее финальный релиз.
Давайте посмотрим, что там появилось интересного:
1. Новые возможности упрощенного управления приложениями
Теперь вместо объектов AppStacks, как это было в App Volumes 2.x, пользователи работают со следующими объектами:
Такая архитектура дает большую гибкость и гранулярность при управлении приложениями:
Например, при выходе новой версии приложения, вы можете добавить нужный Package в уже существующий объект Application и доставлять его нужным пользователям.
С другой стороны, такая модель позволяет управлять приложениями на уровне иерархии организации. Например, можно создать Application для отделов маркетинга, где будут отдельные пакеты для каждого отдела. А уже на уровне отдела сделать сборки (Program) для каждого из случаев (например, роль пользователя на уровне отдела):
2. Новая функция сосуществования приложений старых версий
Приложения версии 2.x, сделанные как App Stacks, могут сосуществовать с новыми приложениями версии 4.x (Applications/Packages) в рамках административной консоли App Volumes 4. Для этого в консоли сделана специальная вкладка для 2.x приложений, которые вы можете постепенно перетаскивать на новую версию платформы.
3. Дополнительные функции
В этой категории появились следующие улучшения:
Жизненный цикл распространяемого через App Volumes 4.0 приложения теперь выглядит следующим образом:
Также по всем функциям App Volumes 4 можно пройтись в рамках интерактивного walk-through:
Более подробно об App Volumes 4 можно узнать на этой странице. Release Notes доступны тут.
Осенью прошлого года компания VMware выпустила VMware Cloud Foundation 3.9. Напомним, что это комплексное программное решение, которое включает в себя компоненты VMware vRealize Suite, VMware vSphere Integrated Containers, VMware Integrated OpenStack, VMware Horizon, NSX и другие, работающие в онпремизной, облачной или гибридной инфраструктуре предприятия под управлением SDDC Manager.
На днях было выпущено небольшое обновление архитектуры VCF 3.9.1, где появилось несколько небольших новых возможностей.