Как расширить виртуальный диск через Vmware Workstation
У меня установлен гипервизор второго типа Vmware Workstation 14 и он может подключаться к vCenter Server и выполнять базовые вещи, вы с его помощью можете расширить диск и обойти ошибку «Invalid operation for device ‘0’.». Подключитесь к vCenter Server через Vmware Workstation и перейдите в свойства виртуальной машины.
Выберите нужный виртуальный диск, после чего нажмите кнопку «Expand», введите новый размер диска и нажмите «Expand».
Через пару секунд вы увидите успешный статус «The disk was successfully expanded. You must repartition the disk and expand the file systems from whithin the quest operating system».
Единственный прикол, что у меня vCenter так и не увидел, что диск расширен, а вот сама система все прекрасно увидела.
Как видите добавленные 20 ГБ на своем месте и можно расширять том, кстати если вдруг у вас будет не активна кнопка расширения тома, то посмотрите как это исправить.
Как обновить ESXi
Для обновления хостов нам потребуется подключиться к хосту по SSH и воспользоваться командной строкой esxcli.
Сначала, выключите или переместите виртуальные машины с обновляемого хоста(не помешает сделать бэкап). Потом переведите хост в режим обслуживания, выполнив команду:
Shell
vim-cmd hostsvc/maintenance_mode_enter
1 | vim-cmd hostsvcmaintenance_mode_enter |
Мы будем рассматривать обновление из репозитория VMware, поэтому нам понадобится доступ в интернет и разрешающее правило файрвола:
Shell
esxcli network firewall ruleset set -e true -r httpClient
1 | esxcli network firewall ruleset set-etrue-rhttpClient |
Теперь давайте посмотрим список доступных образов ESXi, выполнив команду:
Shell
esxcli software sources profile list —depot=https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml
1 | esxcli software sources profile list—depot=httpshostupdate.vmware.comsoftwareVUMPRODUCTIONmainvmw-depot-index.xml |
Чтобы осуществить поиск только определенной версии нужно дописать в конце | grep -i ESXi-6.5
Через некоторое время команда выведет список доступных образов:
Выбираем нужный образ и выполняем команду обновления с параметром —dry-run. Этот параметр позволяет посмотреть какие пакеты будут установлены, а какие удалены. Если в списке удаляемых есть необходимые вам пакеты, будьте готовы их потом поставить вручную.
Shell
esxcli software profile update -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml -p ESXi-6.5.0-20190104001-standard —dry-run
1 | esxcli software profile update-dhttpshostupdate.vmware.comsoftwareVUMPRODUCTIONmainvmw-depot-index.xml-pESXi-6.5.0-20190104001-standard—dry-run |
После этого запускаем непосредственно обновление:
Shell
esxcli software profile update -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml -p ESXi-6.5.0-20190104001-standard
1 | esxcli software profile update-dhttpshostupdate.vmware.comsoftwareVUMPRODUCTIONmainvmw-depot-index.xml-pESXi-6.5.0-20190104001-standard |
Через несколько минут, в случае удачного обновления вы должны увидеть следующее:
Вводим команду reboot и перезагружаемся.
После перезагрузки выводим хост из режима обслуживания:
Shell
vim-cmd hostsvc/maintenance_mode_exit
1 | vim-cmd hostsvcmaintenance_mode_exit |
Проверяем версию ESXi:
И видим, что мы справились с задачей обновления хоста ESXi.
Установить апдейты можно и, скачав их на локальное хранилище хоста, командой типа:
Shell
esxcli software vib update -d «/vmfs/volumes/datastore1/patch-directory/ESXi500-201111001.zip»
1 | esxcli software vib update-d»/vmfs/volumes/datastore1/patch-directory/ESXi500-201111001.zip» |
Вместо команды update можно использовать команду install, но учтите, что она перезаписывает все пакеты, установленные в системе, в то время как update заменяет только более старые версии пакетов, а те, которые новее, чем содержащиеся в патче, оставляет без изменений.
Проверьте с du и df
Перед тем как начать искать проблему, давайте убедимся, что на диске действительно есть свободное место. Хотя инструменты с графическим интерфейсом хорошие, намного лучше использовать программы напрямую из командной строки.
Начнём с du. Укажем ей базовую директорию на диске у которого проблемы. Это руководство подразумевает, что проблемным диском является раздел с рутом.
sudo du -sh /
Для обхода всего дерева директорий потребуется время.
Теперь попробуем с df:
sudo df -h
Добавьте корень файловой системы (рут) и файловые системы, смонтированные под ним. Например, если у вас есть «/home» на отдельном диске, добавьте это к показанию для root. Количество занятого и свободного пространства должно получиться близко к тому, что нам показала программа du. Если это не так, это может указывать на то, что удалённые файлы используются процессами.
Главное, на что следует обратить внимание, чтобы вывод этих команд о занятом пространстве соответствовал друг другу и размеру диска. Если это не так, значит имеется проблема.
Как исправить no space left on device
Первым дело надо понять на каком разделе у вас закончилась память. Для этого можно воспользоваться утилитой df. Она поставляется вместе с системой, поэтому никаких проблем с её запуском быть не должно:
На точки монтирования, начинающиеся со слова snap внимания можно не обращать. Команда отображает общее количество места на диске, занятое и доступное место, а также процент занятого места. В данном случае 100% занято для корневого раздела — /dev/sda5. Конечно, надо разобраться какая программа или файл заняла всё место и устранить эту проблему, но сначала надо вернуть систему в рабочее состояние. Для этого надо освободить немного места. Рассмотрим что можно сделать чтобы экстренно освободить немного памяти.
1. Отключить зарезервированное место для root
Обычно, у всех файловых систем семейства Ext, которые принято использовать чаще всего как для корневого, так и для домашнего раздела используется резервирование 5% памяти для пользователя root на случай если на диске закончится место. Вы можете эту память освободить и использовать. Для этого выполните:
Здесь опция -m указывает процент зарезервированного места, а /dev/sda5 — это ваш диск, который надо настроить. После этого места должно стать больше.
2. Очистить кэш пакетного менеджера
Обычно, пакетный менеджер, будь то apt или yum хранит кэш пакетов, репозиториев и другие временные файлы на диске. Они некоторые из них ненужны, а некоторые нужны, но их можно скачать при необходимости. Если вам срочно надо дисковое пространство этот кэш можно почистить. Для очистки кэша apt выполните:
Для очистки кэша yum используйте команды:
3. Очистить кэш файловой системы
Вы могли удалить некоторые большие файлы, но память после этого так и не освободилась. Эта проблема актуальна для серверов, которые работают долгое время без перезагрузки. Чтобы полностью освободить память надо перезагрузить сервер. Просто перезагрузите его и места на диске станет больше.
4. Найти большие файлы
После выполнения всех перечисленных выше рекомендаций, у вас уже должно быть достаточно свободного места для установки специальных утилит очистки системы. Для начала вы можете попытаться найти самые большие файлы и если они не нужны — удалить их. Возможно какая-либо программа создала огромный лог файл, который занял всю память. Чтобы узнать что занимает место на диске Linux можно использовать утилиту ncdu:
Она сканирует все файлы и отображает их по размеру:
Более подробно про поиск больших файлов читайте в отдельной статье.
5. Найти дубликаты файлов
С помощью утилиты BleachBit вы можете найти и удалить дубликаты файлов. Это тоже поможет сэкономить пространство на диске.
6. Удалите старые ядра
Ядро Linux довольно часто обновляется старые ядра остаются в каталоге /boot и занимают место. Если вы выделили под этот каталог отдельный раздел, то скоро это может стать проблемой и вы получите ошибку при обновлении, поскольку программа просто не сможет записать в этот каталог новое ядро. Решение простое — удалить старые версии ядер, которые больше не нужны.
VMware ESXi Error No Space Left On Device Installing NSX-T Components
In installing the NSX-T components on a host, the installation of the components failed as you see below – “NSX install Failed“.
Installation of NSX-T components failed on ESXi host
In hitting the Resolve button on the screen above, you see the underlying reason for the failure of the process. “NSX components not installed successfully on compute-manager discovered node. Failed to install software on host. Failed to install software on host. 10.1.149.30. java.rmi.RemoteException: No space left on device. Please refer to the log file for more details.
VMware ESXi host error No Space Left On Device
Looking at the esxupdate.log on the ESXi host itself, I saw the following in the log:2019-01-29T16:37:43Z esxupdate: 2101264: HostImage: DEBUG: installer BootBankInstaller failed: No space left on device. Clean up the installation.�
2019-01-29T16:37:43Z esxupdate: 2101264: HostImage: ERROR: Failed to send vob install.error: Cannot allocate memory�
2019-01-29T16:37:43Z esxupdate: 2101264: vmware.runcommand: INFO: runcommand called with: args = ‘localcli system visorfs ramdisk list | grep /stageliveimage && localcli system visorfs ramdisk remove -t /tmp/stageliveimage’, outfile = ‘None’, returnoutput = ‘True’, timeout = ‘0.0’
General Information Regarding VMware ESXi Swap File Location
In case you are interested in information on the VMware ESXi swap file location, VMware has a KB covering this topic called About System Swap located here: https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vsphere.resmgmt.doc/GUID-56608D3C-3C93-4D03-B565-172C08478EA3.html
What is the System Swap anyway? Per the KB:
-
System swap is a memory reclamation process that is used to take advantage of any unused memory that may be available across the entire system.
-
System swap allows the system to reclaim memory from memory consumers that are not virtual machines. When system swap is enabled you have a tradeoff between the impact of reclaiming the memory from another process and the ability to assign the memory to a virtual machine that can use it. The amount of space required for the system swap is 1GB.
-
Reclaimed memory is written to background storage after it has been taken out of memory. Of course reading from background storage is much slower than reading from memory, so you must be careful when and where swapping is used from background storage.
-
The Preferred swap file location is where ESXi determines automatically where the system swap is to be stored . This decision can be aided by selecting a certain set of options. The system selects the best possible enabled option. If none of the options are feasible then system swap is not activated.
The available locations are:
-
Datastore – Uses the datastore specified. Please note that a vSAN datastore or a VVol datastore cannot be specified for system swap files.
-
Host Swap Cache – Allow the use of part of the host swap cache.
-
Preferred swap file location – Allow the use of the preferred swap file location configured for the host.
Как устранять потерю пакетов у виртуальной машины
Первое с чего следует начать диагностику, это посмотреть текущую загрузку ESXI хоста на котором располагается ваша виртуальная машина. Может быть ситуация, что на хосте все ресурсы утилизируются по максимуму и он вам об этом пишет «Host CPU usage и host memory usage».
Если на уровне хоста все хорошо и другие виртуальные машины работаю корректно и за ними не замечено потери пакетов, то проверяем уже саму виртуальную машину. Я вам советую открыть командную строку и запустить постоянный пинг через утилиту ping -t. Это нужно для того, чтобы сразу смотреть изменения при нашей диагностике.
Перейдем теперь к самой гостевой операционной системе, тут вам нужно проверить две вещи:
Первая это нагрузка на CPU. Если она под 100%, то вас сетевой интерфейс будет не успевать обрабатывать пакеты, тем более если вы используете устаревший вид интерфейса E1000. Сделать это можно в диспетчере задач. Для этого нажмите одновременно CTRL+SHIFT+ESC. Перейдите на вкладку производительности и выберите пункт «ЦП (CPU)». Убедитесь, что здесь нет всплеском под 100%, если они есть, то перейдите на вкладку «Процессы».
На данной вкладке произведите фильтрацию по загрузке CPU, для этого один раз щелкните по столбцу. В самом верху посмотрите, что за процесс потребляет ваши мощности, если он не нужен, то завершите его, если нужен, то нужно наращивать ресурсов или оптимизировать ПО, которое за него отвечает.
Далее так же посмотрите нагрузку на вашу дисковую подсистему. Для этого запустите монитор ресурсов из диспетчера процессов.
Перейдите на вкладку «Диск», тут вам нужно посмотреть два параметра:
- Длина очереди, которая не должна быть больше единицы
- Время ответов, которое для ssd не должно быть более 20 и для HDD не более 100.
Если у вас значения выше или существенно выше, то нужно искать проблему низкой производительности дисков или самого датастора на котором лежит виртуальная машина.
Как вернуть активную опцию «migrate»
У компании VMware есть KB в которой описаны вот такие симптомы:
- Параметр миграции неактивен на выключенной виртуальной машине в vSphere Client.
- Вы не можете перенести выключенную виртуальную машину.
- В vSphere Client, когда вы выбираете опцию «Migrate» на вкладке «Summary» для виртуальной машины, вы видите ошибку:
Call «VirtualMachine.Relocate» for object «Virtual Machine-NAME» on vCenter Server «vCenter-Name» failed
Подробнее можно почитать вот тут — https://kb.vmware.com/s/article/2044369
Перед тем как мы все исправим мне стало интересно, а есть ли у меня еще виртуальные машины имеющие данную проблему, чтобы это определить среди множества серверов, можно воспользоваться помощью PowerCLI. Откройте оболочку и подключитесь к вашему vCenter. Далее выполните вот такой код:
Get-vm | Select name,@{Name=»RelocateVM»;Exp={$_| get-view | Select-Object –ExpandProperty DisabledMethod | %{$_ -like «RelocateVM_Task»} | Sort-Object -Unique| Measure-Object | Select-Object -ExpandProperty Count}} | where{$_.RelocateVM -ne 1}
В результате я получил список из двух серверов. Понимая, что это не массовая проблема идем к самому решению.
Нам нужно удалить регистрацию виртуальной машины из vCenter Server Inventory. Для этого через правый клик вызовите на сбойном сервере контекстное меню и найдите там пункт «Remove from iventory», это не удалит сервер с датасторов, а просто уберет его из списка зарегистрированных.
Перед удалением из vCenter Server Inventory выключите виртуальную машину и запомните на каком датасторе она у вас располагалась
Соглашаемся с тем, что отменяем ее регистрацию в vCenter.
Далее вы открываете ваш датастор с виртуальными дисками вашего сервера, находите там файл конфигурации, он имеет формат vmx. Далее нажимаем кнопку «Register VM».
У вас откроется мастер регистрации «Register Virtual Machine», на первом шаге вам нужно указать имя виртуальной машины, я оставлю как есть и по возможности вы можете ее сразу положить в контейнер.
Далее выбираем в каком кластере оно будет работать.
Завершаем нашу регистрацию.
Теперь проверьте, что у вас стал активен пункте «Migrate» у виртуальной машины.
Еще у сбойной машины я вам советую обновить VMware Tools, точнее удалить текущие и потом установить свежие.
На этом у меня все. Мы починили кнопку миграции, с вами был Иван Семин, автор и создатель IT портала Pyatilistnik.org.
General Information Regarding VMware ESXi Swap File Location
In case you are interested in information on the VMware ESXi swap file location, VMware has a KB covering this topic called About System Swap located here: https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vsphere.resmgmt.doc/GUID-56608D3C-3C93-4D03-B565-172C08478EA3.html
What is the System Swap anyway? Per the KB:
- System swap is a memory reclamation process that is used to take advantage of any unused memory that may be available across the entire system.
- System swap allows the system to reclaim memory from memory consumers that are not virtual machines. When system swap is enabled you have a tradeoff between the impact of reclaiming the memory from another process and the ability to assign the memory to a virtual machine that can use it. The amount of space required for the system swap is 1GB.
- Reclaimed memory is written to background storage after it has been taken out of memory. Of course reading from background storage is much slower than reading from memory, so you must be careful when and where swapping is used from background storage.
- The Preferred swap file location is where ESXi determines automatically where the system swap is to be stored . This decision can be aided by selecting a certain set of options. The system selects the best possible enabled option. If none of the options are feasible then system swap is not activated.
The available locations are:
- Datastore – Uses the datastore specified. Please note that a vSAN datastore or a VVol datastore cannot be specified for system swap files.
- Host Swap Cache – Allow the use of part of the host swap cache.
- Preferred swap file location – Allow the use of the preferred swap file location configured for the host.
VMware ESXi Error No Space Left On Device Resolution
The resolution in my case was to allow the System swap file location to use a local datastore on the ESXi host. To do that, under the context of the host, navigate to Configure > System Swap > Edit.
Editing the VMware ESXi System Swap file location
Under the Edit System Swap Settings select the checkbox to Can use datastore:<your datastore> and choose the datastore you want to use. After doing this, I rebooted my nested ESXi host to ensure the settings were correctly recognized.
Changing the VMware ESXi host System Swap file location to use a datastore
After getting the VMware ESXi Error No Space Left On Device changing swap location on ESXi resolved the issue
Как расширить виртуальный диск через PowerCLI
PowerCLI имеет более широкие возможности чем графический интерфейс, поэтому он легко может обойти ошибку «Invalid operation for device ‘0’.» Как устанавливать и где брать оболочку, я уже рассказывал. Подключитесь к вашему vCenter серверу, через команду:
Connect-VIServer dns-имя vcenter сервера
Если выскочит ошибка «Error: Invalid server certificate», то посмотрите как ее устранить.
Теперь вам нужно в настройках виртуальной машины посмотреть номер диска, который не удается расширить, в моем примере это первый диск «Hard disk 1». Далее пишем:
Get-HardDisk -vm имя виртуальной машины | where {$_.name -eq «Hard disk 1»} | Set-HardDisk -capacityGB 220
После выполнения данной команды я увеличил размер диска до 220 ГБ.
Смотрим настройки виртуальной машины, там тоже все отображается как нужно.
На этом все, мы успешно обошли данную ошибку. С вами был Иван Семин, автор и создатель IT портала Pyatilistnik.org.
Ремонт работающей виртуальной машины со статусом Invalid (Unknown)
В ситуации, когда виртуалка работает и хотелось бы вернуть возможность ее редактировать и взаимодействовать из самого ESXI, вы можете выполнить ряд действий, которые устранят статус Invalid (Unknown). Во первых, вы можете попробовать выполнить из консоли ssh, такие команды:
vim-cmd vmsvc/reload 97 (97 Это ID, мы его получили выше), после этого минуты через две, обновите интерфейс в вашем ESXI клиенте, чтобы проверить статус машины
Если новая перерегистрация не помогла, то делаем вот что, тушим по возможности виртуальную машину из самой ОС. Далее, щелкаем по ней правым кликом и удаляем ее из инвентории. В vCenter 6.5 это выглядит так, «All Virtual infrastructure Actions — More Custom Atrtributes — Remove From Inventory».
В ESXI 5.5, это выглядит вот так.
Если виртуалка работает и нет возможности ее выключить, перезагружаем ESXI хост. После чего создаем новую виртуальную машину. На этапе «Customize Hardware», где нужно указывать размер ваших ресурсов, удалите стандартно созданный диск, и нажмите кнопку Add. Выберите пункт «Существующий виртуальный диск (Existing Hard Disk).
И добавьте все ваши существующие диски, от прежней виртуальной машины. Запустите ее и проверьте, что все работает.
В ESXI 5.5, это выглядит так же, там нужно выбрать «Use an existing virtual disk».
Как только вы удостоверились, что все в порядке, осталось еще выполнить миграцию этих дисков в папку с виртуальной машиной, чтобы все было в одном месте. Для этого два пути, тупое копирование файлов и заново передобавлять их из конфигурации мастера или же сделать Storage VMotion.
VMware ESXi Error No Space Left On Device Resolution
The resolution in my case was to allow the System swap file location to use a local datastore on the ESXi host. To do that, under the context of the host, navigate to Configure > System Swap > Edit.
Editing the VMware ESXi System Swap file location
Under the Edit System Swap Settings select the checkbox to Can use datastore:<your datastore> and choose the datastore you want to use. After doing this, I rebooted my nested ESXi host to ensure the settings were correctly recognized.
Changing the VMware ESXi host System Swap file location to use a datastore
After getting the VMware ESXi Error No Space Left On Device changing swap location on ESXi resolved the issue
Недостаточно Инод (Inode)
Для современных файловых систем Linux есть такое понятие как иноды (“inodes”) — это набор метаданных на файловой системе. Иноды отслеживают информацию о файлах. Многие файловые системы имеют фиксированное количество инод, поэтому очень возможно занять максимальное выделенное количество без заполнения самой файловой системы. Вы можете использовать для проверки команду df:
sudo df -i /
Сравните количество существующих инод с количеством занятых. Если больше нет свободных, к сожалению, вы не можете получить больше. Выход: удалите ненужные или устаревшие файлы для очистки инод.
В нормальных условиях, даже на системах интенсивно использующих постоянное хранилище, редко происходит потребление всех инод. Как правило, исчерпание inodes сигнализирует о другой проблеме. Обычно причиной является неконтролируемое создание огромного количество файлов из-за бага в системе или в программе.
В первую очередь нужно локализовать папку, в которой возникла проблема.
for i in /*; do echo $i; find $i |wc -l; done
Ещё варианты команд, которые делают это же самое (по умолчанию они настроены проверять текущую папку — это можно изменить, для этого вместо точки впишите желаемую для проверки папку:
sudo find . -xdev -type f | cut -d "/" -f 2 | sort | uniq -c | sort -n
Второй вариант:
find . -maxdepth 1 -type d | grep -v '^\.$' | xargs -n 1 -i{} find {} -xdev -type f | cut -d "/" -f 2 | uniq -c | sort -n
Когда найдена папка с наибольшим количеством инод, то проверьте её подпапки — для поиска проблемной. Продолжайте эти действия, пока не найдёте папку с огромным количеством нагенерированных файлов.
Например, использование первой команды для поиска по директории /src/:
for i in /src/*; do echo $i; find $i |wc -l; done
Вариант для поиска по директории /var/cache/:
for i in /var/cache/*; do echo $i; find $i |wc -l; done # или: find /var/cache/* -maxdepth 1 -type d | grep -v '^\.$' | xargs -n 1 -i{} find {} -xdev -type f | cut -d "/" -f 2 | uniq -c | sort -n
В разных ситуациях для пользователей проблемными папками оказывались:
- /var/lib/php/sessions/
- /var/cache/fontconfig
- /usr/src/
- /var/cache/eaccelerator/
- /var/log/squid3/
В /usr/src/ накапливалось слишком большое количество файлов, имеющих отношение к предыдущим ядрам. В /var/lib/php/sessions/ — бесконечные сессии phpMyAdmin. В /var/log/squid3/ и вообще в папке /var/log/ может накопиться огромное количество файлов с журналами от неправильно работающей программы или просто за много лет. В папке /var/cache/ может скопиться огромное количество файлов, имеющих отношение к кэшированию.
В моём случае причиной проблемы оказалась папка /var/cache/fontconfig — в этой папке постоянно накапливаются новые файлы (я не знаю, насколько это нормально) и по итогу работы за 4 года из-за этой папки закончились иноды.
Когда проблемная папка найдена, то нужно её очистить. Скорее всего все файлы в ней не нужны (оцените это исходя из вашей ситуации). Также весьма вероятно, что файлов там астрономическое количество и их обработка может затянуться на часы, поэтому самый быстрый вариант — удалить папку целиком, а затем создать её заново. Даже при таком подходе в моём случае удаление папки /var/cache/fontconfig заняло около 10-20 минут.
Это полностью разрешило мою проблему и снизило количество используемых инод со 100% до 13%:
Плохие блоки
Ещё одна распространённая проблема — это плохие блоки в файловой системе. Со временем из-за износа дисков, файловые системы повреждаются. Ваша операционная система, скорее всего, увидит эти блоки пригодными для использования, если они не помечены иным образом. Лучший способ найти и пометить эти блоки — использовать fsck с флагом -cc. Помните, что вы не можете использовать fsck из той же файловой системы, которую тестируете. Вам, вероятно, понадобится использовать Live CD.
sudo fsck -vcck /dev/sda2
Очевидно, замените /dev/sda2 на имя того диска и раздела, который вы хотите проверить. Кроме того, имейте в виду, что это, вероятно, займёт много времени.
Надеюсь, одно из этих решений решило вашу проблему. Эту проблему не всегда легко диагностировать в каждом случае. Однако, если повезёт, вы сможете устранить источник проблемы и продолжить пользоваться системой без её переустановки.
Кстати, сообщение “No space left on device” может возникнуть при попытке записать файл размером более 4GB на раздел с файловой системой FAT — данная файловая система не поддерживает файлы таких больших размеров.
VMware ESXi Error No Space Left On Device Installing NSX-T Components
In installing the NSX-T components on a host, the installation of the components failed as you see below – “NSX install Failed“.
Installation of NSX-T components failed on ESXi host
In hitting the Resolve button on the screen above, you see the underlying reason for the failure of the process. “NSX components not installed successfully on compute-manager discovered node. Failed to install software on host. Failed to install software on host. 10.1.149.30. java.rmi.RemoteException: No space left on device. Please refer to the log file for more details.
VMware ESXi host error No Space Left On Device
Looking at the esxupdate.log on the ESXi host itself, I saw the following in the log:
2019-01-29T16:37:43Z esxupdate: 2101264: HostImage: DEBUG: installer BootBankInstaller failed: No space left on device. Clean up the installation.� 2019-01-29T16:37:43Z esxupdate: 2101264: HostImage: ERROR: Failed to send vob install.error: Cannot allocate memory� 2019-01-29T16:37:43Z esxupdate: 2101264: vmware.runcommand: INFO: runcommand called with: args = 'localcli system visorfs ramdisk list | grep /stageliveimage && localcli system visorfs ramdisk remove -t /tmp/stageliveimage', outfile = 'None', returnoutput = 'True', timeout = '0.0'
Способы включения ssh в Vmware хостах
Существует, как минимум три метода, позволяющие вам это сделать.
- Через консоль управления Vmware ESXI — для этого, вам придется использовать один из портов управления сервером, либо же использовать ip KVM, хотя в малых компаниях, все ограничиться банальным подключением монитора и клавиатуры.
- Из клиента vSphere Client, но это актуально для версии до 5.5, .
- В версиях, выше 5.5 уже используют HTML клиента
Включение SSH и esxi shell на ESXi 5/6 через локальную консоль
Подключитесь к вашему гипервизору. Для входа в его настройки нажмите клавишу <F2> в консоли:
Как включить доступ по SSH и esxi shell на хосте VMware ESXi 5.1-01
Вводим пароль root и переходит в пункт «Troubleshooting Options»:
Как включить доступ по SSH и esxi shell на хосте VMware ESXi 5.1-02
Выбираем пункт «Enable SSH»: Enable esxi shell, для включения данной службы. После чего вы выходите из данного режима и сохраняете настройки.
Как включить доступ по SSH и esxi shell на хосте VMware ESXi 5.1-03
Попасть в esxi shell консоль Alt+F1 выйти Alt+F 2
Включение ssh, через vSphere Client
Второй метод, это включение SSH и esxi shell на ESXi 5 через vSphere Client. Открываем его и переходим на вкладку «Configuration», выбираем пункт «Security Profile» и нажимаем «Properties»:
Как включить доступ по SSH и esxi shell на хосте VMware ESXi 5.1-04
Выбираем сервис SSH и нажимаем «Options»:
Как включить доступ по SSH и esxi shell на хосте VMware ESXi 5.1-05
Устанавливаем режим запуска сервиса SSH на ESXi и включаем его кнопкой Start. Как видите тут 3 варианта запуска службы:
- Start automatically if any ports are open, and stop when all ports are closed — тут все будет работать автоматически
- Start and stop with host — будет запускаться и останавливаться вместе с сервером
- Start and stop manually — запуск вручную.
Как включить доступ по SSH и esxi shell на хосте VMware ESXi 5.1-06
После включения SSH на ESXi 5.0 у вас появятся следующие предупреждения в vSphere Client для хоста:
SSH for the host has been enabled
Как включить доступ по SSH и esxi shell на хосте VMware ESXi 5.1-07
Если вы включали ESXi Shell, то будет сообщение:
ESXi Shell for the Host has been enabled
Чтобы их убрать, нужно сделать так. Выбираем нужный хост ESXi.Переходим в категорию «Advanced Settings» в разделе «Software» на вкладке «Configuration». Переходим в раздел UserVars > UserVars.SupressShellWarning. Меняем значение с 0 на 1. Нажимаем OK.
Включение ssh, через HTML клиента
По умолчанию, версия VMware ESXI 6.5 не имеет толстого клиента, но уже имеет встроенного HTML клиента, доступного через браузер, для версий 5,5 и ниже, нужно будет докачивать отдельно клиента. Давайте, включим ssh доступ в версии 6.5. Логинимся через браузер в интерфейс управления.
В открывшемся окне, найдите пункт «Manage» Затем переходите на вкладку «Services» и выбираете службу ssh.
Выбрав службу ssh, найдите в самом верхнем меню, пункт действия «Actions». Нажав его вы сможете взаимодействовать со службой.
- Restart — перезапуск
- Start — запуск
- Stop — остановка
Пункт «Policy» позволит настроить автозапуск служб. Как видите, использование и предоставление доступа по ssh на Vmware ESXI реализованного, очень просто.
Так же обнаружил на одной из последних версий Vmware ESXI 6.5, что можно просто щелкнуть правым кликом по «Host» и выбрать пункты меню «Services — Enable Secure Sell (SSH)», удобно вынесли активацию службы SSH.
Материал сайта pyatilistnik.org