В моем хозяйстве находятся сервера VMware ESX 4.1. В большинстве своем достались они мне уже такими, поэтому периодически я сталкиваюсь с различными глюками, об одном из которых я и хочу поведать.
При обновлении хостов через Update Manager 4.1 я столкнулся с ошибкой из заголовка:
некоторые хосты при обновлении ругались “The host returns esxupdate codes: 7”
Погуглив только по коду ошибки (esxupdate codes: 7), я получил список ошибок. Ошибка №7 означает, что хост не смог скачать файл. Гениально, как сказал бы КО.
Вчитавшись в лог, я увидел там следующее:
“Remediation did not succeeded…”,”[Errno 14] HTTP Error 404: Not Found’)”
Ух ты, сказал я и вбил это в гугле. Поиск вывел меня на статью про регистрозначимый фикс для Update Manager. Смысл в том, что до этого фикса все обновления закачивались и выкладывались в нижнем регистре, хотя в базе были в смешанном, например, cross_oem-vmware-esx-drivers-net-vxge_400.2.0.28.21239-1OEM.vib.
Соответственно, после обновления до Update Manager4.1 U2 или 4.0 U4 вы могли словить такой баг.
Для лечения этого бага вам необходимо:
– открыть репозиторий UM
- Windows2008:
C:\ProgramData\VMware\VMware Update Manager\Data\Hostupdate\vmw\vibs\ - Windows2003:
C:\Documents and Settings\All Users\Application Data\VMware\VMware Update Manager\Data\Hostupdate\vmw\vibs\
– переименовать следующие файлы
bind-libs-9.3.6-4.p1.el5_5.3.i386.vibbind-libs-9.3.6-4.p1.el5_5.3.x86_64.vibbind-utils-9.3.6-4.p1.el5_5.3.x86_64.vibbind-libs-9.3.6-4.p1.el5_5.3.i386.vibcross_oem-vmware-esx-drivers-net-vxge_400.2.0.28.21239-1oem.vibcross_oem-vmware-esx-drivers-scsi-3w-9xxx_400.2.26.08.036vm40-1oem.vibvmware-esx_swmgmt_provider-4x.1.0.1-1.4.348481.vib
в
bind-libs-9.3.6-4.P1.el5_5.3.i386.vibbind-libs-9.3.6-4.P1.el5_5.3.x86_64.vibbind-utils-9.3.6-4.P1.el5_5.3.x86_64.vibbind-libs-9.3.6-4.P1.el5_5.3.i386.vibcross_oem-vmware-esx-drivers-net-vxge_400.2.0.28.21239-1OEM.vibcross_oem-vmware-esx-drivers-scsi-3w-9xxx_400.2.26.08.036vm40-1OEM.vibvmware-esx_swMgmt_provider-4x.1.0.1-1.4.348481.vib.
Кстати говоря, переустановка ОС хоста также решает эту проблему. Проверено vMind.ru 😉
find . -type f -size +50000k -exec ls -lh {} \; | awk ‘{ print $9 “: ” $5 }’
Скрипт для консоли – чтобы найти в текущей директории все файлы больше 50Мб.
В моем случае на нескольких стареньких ESX наблюдалась схожая картина:
df -h отображает отсутствие места на /
Удаляем каталог esxupdate, содержащий кэш файлов обновления и создаем его заново. На файлы в этом каталоге может вывести поиск.
cd /var/cache/
rm -rf esxupdate
mkdir esxupdate
А зачем удалять сам каталог и восстанавливать потом? Не проще сразу сделать
rm -rf /var/cache/esxupdate/
🙂
И что? 🙂
эта команда точно так же удаляет каталог (просто не надо предварительно заходить в более высокий каталог 🙂
Обрати внимание на закрывающий слеш – удаляется СОДЕРЖИМОЕ а не сам каталог.
Осспади :))
И этот линукс приводят в пример большей прозрачности, по сравнению с виндами :)))
В консоли ESX 4.1 каталог удаляется.
И с закрывающим слешом, и без него
??? Ну не будем холивар разводить.
в догонку – искать по размеру файлов не всегда хорошо, так как место могут сожрать и 100500 мелких файлов. Лучше размер папки смотреть командой du.
Например делаем “du -sh /*” – видим размер папок в корне.
Можно с сортировкой извратится, например в /var/:
du -s /var/* | sort -n | cut -f2- | xargs du -hs
Это чтоб “хуман вид” у размера был =) почему-то в esxi у sort нет параметра -h и я ничего проще двойного du не придумал 🙁
а, ну да =)
rm -rf /var/cache/esxupdate/*