Статья прислана читателем бложика.
Занимались аудитом и обслуживанием очередной пары фирм, попутно обновляли VMware – увидели много интересного.
Первая фирма, обновления 7.0.1 – 7.0 Update 2e build 19290878.
Опять какие-то проблемы с iSCSI. На одном сервере полностью поменялся IQN, причем с изменением даже имени. После этого по возвращении сервер не увидел СХД, пришлось настраивать. На аналогичном втором сервере потерялся target, но IQN остался тот же.
Как оказалось, проблема описана в интернете, НО что-то не находится в VMware release notes:
In some cases, with the upgrade from vSphere 7.0 Update 1 to Update 2, the iSCSI adapter IQN may change. This issue is specifically after an upgrade from vSphere 7.0 U1 to U2 where iSCSI was added while using Update 1. The issue can occur when the IQN is automatically generated and not user-defined, which is usually the case. Also, if the iSCSI adapter was added before vSphere 7.0 Update 1, the issue doesn’t seem to occur.
https://core.vmware.com/blog/iscsi-adapter-iqn-changed-after-upgrading-esxi-70-u2
Есть kb для 7.0.1 – iSCSI adapter IQN may change during the upgrade of ESXi 7.0 U1 (84339).
Upgrade from 6.7 to >= 7.0U2 – No issue, the iSCSI adapter IQN is moved from vmkiscsid.db to config store
Upgrade from 7.0 to >= 7.0U2 – No issue, iSCSI adapter IQN is moved from vmkiscsid.db to config store
Upgrade from 7.0U1 to >= 7.0U2 – Issue, if all 3 conditions below are met:
- ESXi is a fresh install of version 7.0 U1 or a particular software/dependent iSCSI adapter was added in 7.0 U1 only
- The IQN of the iSCSI adapter is not set by the user but automatically generated by ESXi
- LUN access control is configured on the target side based on the generated IQN
Один сервер отказался обновляться до ребута, даже из командной строки – из WEB писал «не смог, читайте логи», из командной строки «не могу обновить следующие VIB..». После ребута обновился.
На одном сервере пропал iSCSI target, пришлось передобавить. Но это, скорее всего, проблема с диском / USB – The issue occurs when the iSCSI configuration is corrupted. Software iSCSI LUNs disappear after rebooting or upgrading the ESX/ESXi host (1038065)
Вторая фирма – проблемы не связаны напрямую с VMware, но тоже интересно.
При обновлении из WEB VUM писал, как и в прошлые разы «не смог, все в логах», из CLI – [Errno 32] Broken pipe vibs = VMware_locker_tools-light
Небольшое отступление – VMware все дальше идет по пути MS и HPE, то ломая то, что работало годами, то теряя статьи. Например: из статьи Location of log files for VMware products (1021806) идет ссылка на Locating logs for VMware vSphere Update Manager 5.0 – https://kb.vmware.com/s/article/2038036 – а статья удалена.
Логи (tail /var/log/esxupdate.log ) – не содержат ничего вразумительного, как и статья ESXi host upgrade fails with “The host returns esxupdate error code:15. The package manager transaction is not successful” (60372)
Статья прекрасна как 7.0.3 образца 2021 года – Run ls -ltrh and identify the device UUID that is being used for /store. Re-format the device disk from above step with vfat filesystem
Я так делать, естественно, не стал.
Что было проверено
– Заменить ProductLockerLocation – благо это стало совсем просто, In vSphere 6.7 Update 1, updateProductLockerPolicy tool has been deprecated by the updateProductLockerLocation vSphere API. Therefore, for the hosts running ESXi 6.7 Update 1 or later, /productLocker symlink can be updated just by invoking updateProductLockerLocation vSphere API with /vmfs/volumes/<volumeName>/<extracted directory> as the argument
Статья Installing and upgrading the latest version of VMware Tools on existing hosts (2129825)
Итог – как ни странно, не работает. ProductLockerLocation меняется, проблема остается.
Почитать вот эти три статьи
VMware ESXi Patching Error – [Errno 32] Broken pipe vibs = VMware_locker_tools-light || [DatabaseIOError] Error in purging old directory
И ее продолжение
Итоговое решение по статьям простое и мудрое (наверное) –
In order to fix the issue permanently, we would need to delete the existing store partition and create new one. Before proceeding with that, first, we need to copy the “var” & “packages” folder from store partition to a local server or another VMFS datastore.
Но пока обошлись без этого, сделав rename старой vmtoolsRepo (пустой, кстати) и создав новую. Напоминаю – пути к тулзам меняются от версии к версии:
5.5 /locker/packages/5.5.0/
6.0 /locker/packages/6.0.0/
6.5 /locker/packages/6.5.0/
6.7 /locker/packages/vmtoolsRepo/
7.0 /locker/packages/vmtoolsRepo/
https://kb.vmware.com/s/article/1037405
В одном случае по так и не выясненной причине (лень – это ж тикет надо заводить, с минимальным приоритетом) пришлось сначала обновить VMtools вручную, путем
– из zip файла с патчем достаем VMware_locker_tools-light_(какая-там-у-вас-версия).vib
– берем в руки SCP и кладем его в /tmp
– esxcli software vib install -v /tmp/VMware_locker_tools-light_(какая-там-у-вас-версия).vib
Огонь!