Troubleshooting – vmik.net

Quick fix: VMware. Some of the disks of the virtual machine failed to load.

Столкнулся с данной проблемой у одной из запущенных VM под управлением VMware ESXi, 7.0.3, 20328353.

Симптомы:

1. VM запущена и работает. Жалоб от пользователей не поступает;

2. При попытке выполнить vMotion появлется ошибка:

The object or item referred to could not be found.

3. Далее в hostd.log можно увидеть записи следующего характера:

Failed to find file size for /vmfs/volumes/.../VM_NAME.nvram: No such file or directory

4. В vCenter UI статус виртуальной машины отображает следующее:

Some of the disks of the virtual machine VM_NAME failed to load. The information present for them in the virtual machine configuration may be incomple

5. На уровне хранения нет никаких проблем. Все файлы виртуальной машины находятся на datastore;

6. С другими виртуальными машинами на том же хосте\хранилище проблем нет;

7. Рекоммендации по типу “Rescan Datastore” не работают.

Решение.

Прежде, чем продолжить, убедитесь что есть резервная копия.

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

Останавливаем виртуальную машину;
После этого VM будет отображаться как inaccessible;
Удаляем машину из vCenter inventory;
Переходим в datastore, находим виртуальную машину и файл vmx;
Выделяем файл, клик по Register VM;
После того, как машина вновь появилась в Inventory, включаем.

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

При развертывании кластера Nutanix CE 2.0 на VMware vSphere, не запускается служба Medusa

С выходом Nutanix Community Edition 2.0 на форумах стал часто появляться один и тот же вопрос – при попытке сформировать кластер из 3-4 узлов, которые развернуты в виде виртуальных машин на VMware vSphere, кластер не собирается и «висит» на попытке запуска службы Medusa на двух узлах. При этом на одном из узлов служба запущена.

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

Medusa ERROR: Cassandra gossip failed

Далее детальнее про проблему и ее решение.

ESXi 7 и зависший vmsyslog

Столкнулся с ситуацией, при которой ESXi 7 Update 3g (build 20328353) перестал отправлять логи на удаленный Syslog сервер, а при дальнейшем разбирательстве выяснилось, что локально логи он так же перестал писать и в /scratch/log журналы не обновляются. Место на диске есть.

В ходе диагностики были зафиксированы ошибки в журнале /var/log/.vmsyslogd.err следующего характера:

vmsyslog.main            : CRITICAL] Dropping messages due to log stress (qsize = 25000)

Адекватных KB по версии 7 на данную тематику я не нашел, была только KB по версии 6.5/6.7 с упоминанием данной ошибки, где было написано, что «проблема устранена».

Команда esxcli system syslog config get корректно выдает статус настроек, а esxcli system syslog reload к каким-то положительным результатам не приводит, логи локально писаться не начинают и, тем более, не отправляются на удаленный сервер.

Перезапуск службы из интерфейса управления хоста кнопкой Restart так же не приводит к каким-либо результатам. В логе можно увидеть только:

vmsyslog.main            : ERROR   ] reloading (3200395)

Что аналогично результату работы esxcli system syslog reload.

Остановить службу и запустить заново из интерфейса ESXi не удается, поскольку:

This service with 'vmsyslogd' is marked as 'required' and cannot be stopped.

Остается применить грубую силу и остановить его принудительно напрямую с хоста:

ps -cC | grep vmsyslog
3418096  3418096  vmsyslogd             /bin/python /usr/lib/vmware/vmsyslog/bin/vmsyslogd.pyc 1

Определяем PID vmsyslog, в данном случае 3418096 и убиваем его:

kill -9 3418096

В логе vmsyslog будет видно, что процесс был убит, а затем автоматически перезапущен:

vmsyslog.main            : ERROR   ] Watchdog 3418095 fired (child 3418096 died with status 9)!
vmsyslog.main            : ERROR   ] Watchdog 3418095 exiting
vmsyslog                 : CRITICAL] vmsyslogd daemon starting (3418940)

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

Немного новостей минувшего месяца

За прошедший месяц было несколько интересных мне новостей, которыми хотел бы поделиться и здесь.

Открыта регистрация на VeeamON 2022

В этом году флагманское мероприятие компании Veeam под названием VeeamON пройдет с 16 по 19 мая в гибридном формате, что уже стало привычным за последние пару лет. Желающие посетить лично могут сделать это в Лас-Вегасе, для остальных же доступен виртуальный формат.

Зарегистрироваться можно по ссылке.

Релиз Tanzu Community Edition 0.10

Совсем недавно вышла новая версия TCE 0.10. В данном релизе появился новый тип кластеров под названием Unmanaged, который в будущих версиях должен полностью заменить Standalone кластера (уже deprecated). Unmanaged кластера развертываются быстрее и при этом потребляют меньше ресурсов.

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

Напомню, что про установку TCE в кластер vSphere я писал здесь.

Релиз Nutanix AOS 6.1 (STS) и Prism Central pc.2022.1

Долгожданный релиз AOS 6.1 с объемным количеством изменений. Почитать можно здесь и более подробно в release notes. Отмечу несколько интересных мне нововведений:

Improved Single vDisk Performance;
Whole Node Maintenance Mode;
VM Centric Storage Policy.

Одновременно с AOS вышла новая версия системы централизованного управления кластерами Nutanix под названием Prism Central. Несколько подмеченных мной нововведений:

Category-based Host affinity policy;
AHV VM templates;
Storage Container Management.

Подробнее в release notes.

В заключении хотел бы поделиться одной недавно обнаруженной KB по базовой диагностике проблем в кластерах Nutanix.

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

Ошибки сайзинга и неочевидные сбои задач Veeam SureBackup

Есть у меня одна совсем маленькая инсталляция – сервер Veeam Backup and Replication и отдельный Linux прокси с репозиторием. Бэкапируется не многим больше двадцати машин и, как можно догадаться из заголовка, резервные копии проверяются на работоспособность с помощью SureBackup.

Основой для написания поста поступило периодическое возникновение ошибок при выполнении задач SureBackup. Практически в каждый запуск задачи одна или несколько машин не проверялись, а в задаче фигурировала не очень детальная ошибка: “Registering. Error: One or more errors occurred”.

Под катом немного процесса диагностики и решение.

Проблема при обновлении Veeam Enterprise Manager до версии 11a

Столкнулся с небольшой проблемой при обновлении Veeam EM до версии 11a. Инсталлятор отказывался останавливать службу VeeamRESTSvc и тем самым прерывал процедуру обновления:

[ERROR] Failed to stop service ‘VeeamRESTSvc'.

В моем случае обновление выполнялось с версии 11 P20210525 под управлением Windows Server 2016 с последними патчами.

Решение под катом.

QuickFix. После обновления Veeam Backup & Replication до версии 11, не обновляется AHV прокси до версии 2.1

Если после обновления VBR до версии 11, прокси сервера для AHV находятся в разделе Out Of Date, а при попытке обновления появляется ошибка следующего характера:

Failed to upgrade host components. Error: ‘Failed to upgrade Proxy – AHV Proxy upgrade failed. Error: Updates are not found.’

Стоило читать документацию перед обновлением 🙂 . Процедура обновления под катом.

Я собрал все грабли, но установил Veeam Agent на Oracle Linux 6.10

Под катом особенности установки Veeam Agent на сервер Oracle Linux 6.10. Все встреченные в процессе инсталляции ошибки и пути их исправления.

Nutanix Karbon – Failed to pull image. Service Unavailable при обращении к приватному реестру

На днях посчастливилось протестировать Nutanix Karbon, который позволяет без каких-либо трудозатрат развернуть на площадке Nutanix готовый к использованию кластер Kubernetes.

Процесс развертывания крайне прост и через ~20-30 минут в моем распоряжении был готовый к использованию кластер.

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

Вышел из строя диск на ноде Nutanix? – меняем

Время от времени приходится прибегать к процедуре замены дисков на нодах Nutanix серии NX, и хоть это и крайне простая операция, на некоторые моменты можно обратить внимание.