Vpxd за что отвечает

#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 была такая проблема, когда один или несколько хостов 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:

Источник

Виртуализация vSphere, Hyper-V, Xen и Red Hat

Более 5550 заметок о виртуализации, виртуальных машинах VMware, Microsoft и Xen, а также Kubernetes

На блоге vSphere появилась отличная статья о сервисах семейства vCenter Server Watchdog, которые обеспечивают мониторинг состояния различных компонентов vCenter, а также их восстановление в случае сбоев. Более подробно о них также можно прочитать в VMware vCenter Server 6.0 Availability Guide.

Итак, сервисы Watchdog бывают двух типов:

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

PID Watchdog

Вот какие сервисы PID Watchdog бывают:

vmware-watchdog

Это шелл-скрипт (/usr/bin/watchdog), который располагается на виртуальном модуле VCSA. Давайте посмотрим на его запущенные процессы:

В понятном виде это можно представить так:

Давайте разберем эти параметры на примере наиболее важной службы VPXD:

-a
-s vpxd
-u 3600
-q 2

Полный список параметров представлен ниже:

-d = DAEMONIZE
-n = QUIET
-b = BG_PROC-s = START
-k = STOP
-r = QUERY
-a = REBOOT_FLAG
-u = MIN_UPTIME
-q = MAX_QUICK_FAILURES
-t = MAX_TOTAL_FAILURES
-i = IMMORTAL
-c = CLEANUP_CMD
-f = EXIT_CLEANUP_CMD

Java Service Wrapper

Он основан на Tanuki Java Service Wrapper и нужен, чтобы обнаруживать сбои в Java-службах vCenter (как обычного, так и виртуального модуля vCSA). Вот какие службы мониторятся:

Если Java-приложение или JVM (Java Virtual Machine) падает, то перезапускается JVM и приложение.

Likewise Service Manager

Это сторонние средства Likewise Open stack от компании BeyondTrust, которые мониторят доступность следующих служб, относящихся к Platform Services среды vCenter:

Likewise Service Manager следит за этими сервисами и перезапускает их в случае сбоя или если они вываливаются.

Вместо параметра list можно также использовать start и stop, которые помогут в случае, если одна из этих служб начнет подглючивать. Вот полный список параметров Likewise Service Manager:

А вот таким образом можно узнать детальную информацию об одном из сервисов:

Помните также, что Likewise Service Manager отслеживает связи служб и гасит/поднимает связанные службы в случае необходимости.

API Watchdog

Эти службы инициализируются только после первой загрузки после развертывания или обновления сервисов vCenter. Затем каждые 5 минут через vSphere API происходит аутентификация и опрос свойства rootFolder для корневой папки в окружении vCenter.

Далее работает следующий алгоритм обработки отказов:

Перед рестартом сервиса VPXD, а также перед перезагрузкой виртуальной машины, служба API Watchdog генерирует лог, который можно исследовать для решения проблем:

mgmt01vc01.sddc.local:/ # cat /etc/vmware/iiad.json
<
«requestTimeout»: 20,
«hysteresisCount»: 4,
«remediatedHysteresisCount»: 6,
«rebootShellCmd»: null,
«restartShellCmd»: null,
«maxTotalFailures»: 50,
«needShellOnWin»: true,
«watchdogDisabled»: false,
«vpxd.watchdogDisabled»: false,
«createSupportBundle»: true,
«automaticServiceRestart»: true,
«automaticSystemReboot»: false,
«maxSingleRestarts»: 3,
«maxSingleFailures»: 2
>

Вот что это значит:

Также сервис IIAD перед перезапуском сервисов или виртуальной машины генерирует лог по адресу:

Вот такой небольшой deep dive в службы доступности сервисов vCenter:)

Источник

Немного о vpxuser

Общая информация

Вот то, что известно всем: vpxuser – учетная запись, используемая vCenter`ом для управления ESXi хостами (опрос гипервизора, отправка задачи), которые в него включены. Т.е. учетная запись root (ESXi) не имеет отношения к связи vCenter – ESXi (за исключением того нюанса, что она нужна для включения ESXi в vCenter).

Vpxuser имеет права администратора ESXi. Таким образом, администратор vCenter`а может выполнять практически все те же самые манипуляции с хостом, что и root (ESXi), кроме создания/удаления/изменения локальных пользователей и групп самого ESXi хоста.
Управлять учетной записью vpxuser с помощью службы каталогов AD нельзя.

Пароль vpxuser хранится в зашифрованном виде и на ESXi и в базе vCenter (логично, не правда ли?) и для каждого ESXi этот пароль уникален.

Подключение к ESXi с помощью VPXUSER

В некоторых источниках я видел утверждения вроде этого: «Знание пароля от vpxuser Вам ничего не даст, использовать эту комбинацию для подключения к хосту и любых других целей невозможно». Однако, зная пароль vpxuser, можно подключиться к ESXi и управлять им (опробовано на Standalone ESXi 5.5 u1 и на ESXi 5.5 u1 под управлением vCenter 5.5, и не только на них).

Изменение пароля VPXUSER

В документации можно обнаружить предупреждение, которое в вольном (моем) переводе выглядит так:

ВНИМАНИЕ: проводите манипуляции с учетной записью vpxuser на свой страх и риск, это может повлечь за собой нарушение связи vCenter – ESXi. При включенном lockdown mode на хосте, управление хостом может быть потеряно безвозвратно.

Это действительно так. Опробовав в лаборатории, могу сказать, что после смены пароля vpxuser на ESXi, vCenter теряет с ним связь. НО не сразу. В моем случае это произошло через 18-20 часов. Самое интересное то, что после смены пароля vpxuser на ESXi, я сразу перезагрузил vCenter Service (но не машину, на которой этот сервис развернут), т.е. установленная сессия должна была дропнуться, и креденшиалы, гипотетически бывшие в кэше (а может и не бывшие, а может и не в кэше), должны были очиститься. Но этого не произошло. Тех. поддержка VMware никак не прокомментировала такое поведение, сказав, что не отвечает на вопросы по архитектурным особенностям платформы.

Интересно и другое: далее в этой статье есть информация о политике паролей vpxuser, и по умолчанию длина его пароля 32 символа. Если менять его пароль вручную на ESXi, например с помощью “passwd”, то можно задать пароль намного короче. Видимо, связано это с тем, что политику паролей поддерживает vCenter, а поскольку меняется пароль vpxuser тоже vCenter`ом, то, как говорится «Я своей смешною рожей сам себя и веселю». Т.е. сменить-то пароль можно, и задать его несоответствующим политике можно, но связь с ESXi в итоге будет утеряна.

Потеря связи вполне логична, ведь при ручной смене пароля vpxuser, его пароль в базе vCenter`а не меняется.

Вывод: не меняйте пароль на vpxuser сами, пусть этим занимается vCenter. Если вы изменили пароль vpxuser руками, то с вероятностю 99% рано или поздно vCenter потеряет связь с ESXi. 1% я оставляю на магическое вмешательство.

Устранение проблем

Если все-таки изменения в vpxuser были внесены (например, изменен пароль) и это повлекло недоступность ESXi из vCenter (обычно сопровождается ошибкой: «Call «ServiceInstance.RetrieveContent» for object «ServiceInstance» on Server «ip_address» failed«), то можно поступить следующим образом (если lockdown mode не включен и есть доступ к хосту по SSH):

Здесь стоит обратить внимание на фразу «если не включен lockdown mode». Если пароль vpxuser был изменен и vCenter потерял связь с ESXi и при этом lockdown mode включен, т.е. доступ к хосту ESXi запрещен всем кроме vCenter, то официальная позиция VMware на этот счет однозначна: «переустанавливайте ESXi».

Политика паролей для vpxuser

Время действия пароля

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

1. В vSphere Client → Administration.
2. vCenter Server Settings… → Advanced Settings.
3. Выбрать параметр VirtualCenter.VimPasswordExpirationInDays, установить нужное значение.
4. Перезагрузить службу vCenter.

Изменять этот параметр VMware не рекомендует. VMware вообще много чего не рекомендует делать, жить вредно, от этого умирают.

Сложность пароля

@-<> и др.), цифры (1-9), большие буквы (латиница) и строчные буквы (латиница).
В документации указано, что для изменения длины пароля vpxuser можно изменить значение параметра vpxd.hostPasswordLength в файле конфигурации на vCenter:

Т.е. внутрь vpxd, но не внутрь какого-либо другого вложенного тега.

Вывод: зачем вообще менять политику паролей для vpxuser? Да незачем, VMware не рекомендует заниматься подобной ерундой.

Источник

Виртуализация vSphere, Hyper-V, Xen и Red Hat

Более 5550 заметок о виртуализации, виртуальных машинах VMware, Microsoft и Xen, а также Kubernetes

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

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

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

С точки зрения логирования процесса vMotion, он устроен следующим образом:

VPXD-лог на vCenter Server позволит найти opID. Для этого залогиньтесь на VCSA (vCenter Server Appliance) и выполните команду:

grep «relocate» /var/log/vmware/vpxd/vpxd-*.log | grep BEGIN

В выводе команды вы найдете нужный opID:

Далее, зная opID, вы можете найти Migration ID в hostd-логах на соответствующих хостах ESXi. Делается это следующей командой:

Исходный хост ESXi

Целевой хост ESXi

На стороне VMkernel вы можете найти информацию о неудачной миграции следующей командой:

grep VMotion /var/log/vmkernel*

Исходный хост ESXi:

Целевой хост ESXi:

В выводе вы можете увидеть такие интересные вещи, как, например, средняя скорость (average bandwidth), которая была получена при передаче данных (см. вывод).

В папке с виртуальной машиной находится файл vmware.log, в котором также можно найти информацию о неудавшемся vMotion с учетом исходного и целевого IP-адресов хостов 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:

Источник