[errno 28] no space left on device#5816

Description of the issue

In my home lab case, I had started with ESXi 7.0 clean installs on all hosts. I first noticed the purple screen of death when I had applied updates to my ESXi hosts. What does the exact error look like?

The error would occur when it was on the VMware boot splash screen when components are being loaded.

VMware ESXi 7 Update 1 boot before PSOD

After a few moments, the ESXi host would PSOD with an error referencing the boot device: boot disk is not found or not responsive.

VMware ESXi 7 Update 1 Boot Disk is not Found

I had also seen a couple of odd things with vSAN when the host would boot that initially, I didn’t connect with the PSOD. I wrote about this error here:

vSAN Daemon Liveness Check Failed – vSAN 7 – Virtualization Howto

In the vSAN heath status check, I would see the EPD status as abnormal. As it turns out VMware recently released a KB article covering this issue here:

Bootbank loads in /tmp/ after reboot of ESXi 7.0 Update 1 host (2149444) (vmware.com)

What is the cause of the issue described here? The storage-path-claim service claims the storage device ESXi is installed on during startup. This results in the bootbank/altbootbank to become unavailable and ESXi then reverts back to ramdisk. Since I had seen the exact issue referenced in the KB article, it seemed reasonable this was the cause of the PSOD I was experiencing.

vSphere vSAN daemon liveness check failed for EPD

Как устранять потерю пакетов у виртуальной машины

Первое с чего следует начать диагностику, это посмотреть текущую загрузку ESXI хоста на котором располагается ваша виртуальная машина. Может быть ситуация, что на хосте все ресурсы утилизируются по максимуму и он вам об этом пишет «Host CPU usage и host memory usage».

Если на уровне хоста все хорошо и другие виртуальные машины работаю корректно и за ними не замечено потери пакетов, то проверяем уже саму виртуальную машину. Я вам советую открыть командную строку и запустить постоянный пинг через утилиту ping -t. Это нужно для того, чтобы сразу смотреть изменения при нашей диагностике.

Перейдем теперь к самой гостевой операционной системе, тут вам нужно проверить две вещи:

Первая это нагрузка на CPU. Если она под 100%, то вас сетевой интерфейс будет не успевать обрабатывать пакеты, тем более если вы используете устаревший вид интерфейса E1000. Сделать это можно в диспетчере задач. Для этого нажмите одновременно CTRL+SHIFT+ESC. Перейдите на вкладку производительности и выберите пункт «ЦП (CPU)». Убедитесь, что здесь нет всплеском под 100%, если они есть, то перейдите на вкладку «Процессы».

На данной вкладке произведите фильтрацию по загрузке CPU, для этого один раз щелкните по столбцу. В самом верху посмотрите, что за процесс потребляет ваши мощности, если он не нужен, то завершите его, если нужен, то нужно наращивать ресурсов или оптимизировать ПО, которое за него отвечает.

Далее так же посмотрите нагрузку на вашу дисковую подсистему. Для этого запустите монитор ресурсов из диспетчера процессов.

Перейдите на вкладку «Диск», тут вам нужно посмотреть два параметра:

• Длина очереди, которая не должна быть больше единицы
• Время ответов, которое для ssd не должно быть более 20 и для HDD не более 100.

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

Как исправить 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 и занимают место. Если вы выделили под этот каталог отдельный раздел, то скоро это может стать проблемой и вы получите ошибку при обновлении, поскольку программа просто не сможет записать в этот каталог новое ядро. Решение простое — удалить старые версии ядер, которые больше не нужны.

План устранения проблемы при использовании SD-карт или USB-устройств в качестве загрузочного накопителя

Использование SD-карт или USB-устройств связано с некоторыми ограничениями:

Использование автономных SD-карт или USB-накопителей (без дополнительного устройства для раздела ESX-OSData) в качестве загрузочного накопителя для хранения раздела ESX-OSData устарело в vSphere 7 Update 3 и не будет поддерживаться в будущих основных выпусках.
В ближайшем будущем единственной поддерживаемой конфигурацией, предполагающей использование SD-карты или USB-накопителя в качестве загрузочного накопителя, будет, как минимум, 8 ГБ SD-карта или USB-накопитель + локально подключенное постоянное устройство хранения для раздела ESX-OSData. Рекомендуемый список локально подключаемых устройств хранения данных приведен ниже.
В любом случае, если в качестве загрузочного накопителя используется SD- или USB-устройство (только SD/USB или SD/USB + локальный HDD/SSD-диск), следуйте приведенным ниже инструкциям, чтобы уменьшить объем ввода-вывода, отправляемого на загрузочный SD- или USB-накопитель:
Включите параметр ToolsRamDisk, чтобы разгрузить запросы ввода-вывода при установке/обновлении VMTools на RAM-диск.
Убедитесь, что раздел /scratch настроен на постоянное хранилище, например локальный HDD/SSD, или загрузитесь с устройства SAN. Программа установки ESXi 7.0 не создает /scratch-раздел на SD-карте или USB-накопителе. Она пытается найти постоянное хранилище и пытается создать /scratch на постоянном устройстве хранения. Раздел /tmp размером 250 МБ создается на RAM-диске, если постоянное хранилище недоступно
Обратите внимание, что производительность хостов ESXi снижается, если в разделе /tmp заканчивается место.
VMware не поддерживает раздел /scratch на загрузочном накопителе SD или USB. Всегда настраивайте /scratch на локально подключенном диске (HDD или SSD)
Если локальный диск недоступен, настройте его на SAN. Следуйте шагам, указанным в статье KB 1033696. Примечание: Пожалуйста, имейте в виду, что RAMDisk нестабилен и подвержен потере данных, поэтому хранение части загрузочных разделов на RAM Disk приводит к ухудшению режима работы.
Хорошей практикой всегда является настройка ESXi Dump Collector на разгрузку дампов ядра.

Для решения проблемы отсутствия /bootbank убедитесь, что клиенты также обновились до vSphere 7 Update 2c или выше.

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

Также важно отметить, что даже ухудшение работы одной SD-карты в зеркальной установке может привести к ухудшению работы других SD-карт.
Если ваш хост ESXi уже обновлен до версии 7.x, вы можете добавить локально подключенное устройство хранения и установить autoPartition=True. При следующей перезагрузке будет создан раздел первого локально подключенного хранилища, который будет использоваться для раздела ESX-OSData

См. статью VMware KB Article 77009.

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

Configuration	Status	Notes	Device Considerations
High Quality Boot Device	Supported, Preferred Long Term Support	Consolidation of System boot, bootbank, and ESX-OSData Partition on the same device	Device Endurance: 100TBW Locally attached devices such as: *NVMe (128 GB minimum) *SSD(128 GB minimum) *M.2 Industrial Grade (128 GB minimum) *HDD (32 GB Minimum) *Managed FCoE/iSCSI LUN (32 GB Minimum)
Low Quality Boot Device + High Quality Device	Supported, Legacy Configuration	Bootbank and ESX-OSData partition remain separate. SD card or USB device should only be considered to storage system boot partition	Low-Quality Device: *SD card or USB drive *Minimum 8 GB Device *Endurance: Minimum 1 TBW High-Quality Device: *Device Endurance: 100TBW *Locally attached devices such as: -NVMe (128 GB minimum) -SSD(128 GB minimum) -M.2 Industrial Grade (128 GB minimum) -HDD (32 GB Minimum) -Managed FCoE/iSCSI LUN (32 GB Minimum)
Low Quality Boot Device (Only SD card or USB device as the boot media), No High Quality Device	* It is being deprecated in vSphere 7 Update 3 * Still runs but with warnings. Please refer VMware KB Article 85615, linked at the end of this post	All the partitions, including the ESX-OSData partition, are installed on the same low-quality boot media. This is a degraded mode configuration.

What is the error “No space left on device (28)”?

For Linux to be able to create a file, it needs two things:

1. Enough space to write that file.
2. A unique identification number called “inode” (much like a social security number).

Most server owners look at and free up the disk space to resolve this error.

But what many don’t know is the secret “inode limit“.

What is “inode limit”, you ask? OK, lean in.

Linux identifies each file with a unique “inode number”, much like a Social Security number. It assigns 1 inode number for 1 file.

But each server has only a limited set of inode numbers for each disk.  When it uses up all the unique inode numbers in a disk, it can’t create a new file.

Quite confusingly, it shows the error : No space left on device (28) and people go hunting for space usage issues.

Now that you know what to look for, let’s look at how to fix this issue.

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

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 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'

No Space on Device Possible Causes

There are a couple of main causes here. If you saw a discrepancy between and , you can jump down to the first option here. Otherwise, start at the second one.

Deleted File Reserved by Process

Occasionally, a file will be deleted, but a process is still using it. Linux won’t release the storage associated with the file while the process is still running, but you can find the process and restart it.

Try to locate the process.

sudo lsof  | grep deleted

The problematic process should be listed. Just restart it.

sudo systemctl restart service_name

If it’s not immediately evident, do a full daemon reload.

sudo systemctl daemon-reload

Not Enough Inodes

There is a set of metadata on filesystems called “inodes.” Inodes track information about files. A lot of filesystems have a fixed amount of inodes, so it’s very possible to fill the max allocation of inodes without filling the filesystem itself. You can use to check.

sudo df -i 

Compare the inodes used with the total inodes. If there’s no more available, unfortunately, you can’t get more. Delete some useless or out-of-date files to clear up inodes.

Bad Blocks

The last common problem is bad filesystem blocks. Filesystems can become corrupt over time, and hard drives die. Your operating system will most likely see those blocks as usable unless they’re otherwise marked. The best way to find and mark those blocks is by using with the flag. Remember that you can’t use from the same filesystem that you’re testing, so you’ll probably need to use a live CD.

sudo fsck -vcck devsda2

Obviously, replace the drive location with the drive that you want to check. You can find that by using the command from earlier. Also, keep in mind that this will probably take a long time, so be prepared to grab a coffee.

Hopefully, one of these solutions solved your problem. This issue isn’t exactly easy to diagnose in every instance. With any luck, though, you can get it cleared up and have your system working again normally.

If you’re looking for more Linux pointers, see our guide on how to set up Bluetooth in Linux. Or, for something a little different, see how to install Mac’s Safari browser in Linux. Enjoy!

John Perkins

John is a young technical professional with a passion for educating users on the best ways to use their technology. He holds technical certifications covering topics ranging from computer hardware to cybersecurity to Linux system administration.

Subscribe to our newsletter!

Our latest tutorials delivered straight to your inbox

Важные ссылки

• ESXi System Storage Changes
• ESXi System Storage While Upgrading
• ESXi System Storage FAQs
• ESXi 7 Storage Requirements
• VMFS-L locker partition corruption
• Bootbank cannot be found at path ‘/bootbank’ errors being seen after upgrading to ESXi 7.0 U2
• Creating a persistent scratch location for ESXi 7.x/6.x/5.x/4.x
• Configure ESXi Dump Collector with ESXCLI
• Persistent storage warnings when booting ESXi from SD-Card/USB devices (85615)
• SD card/USB boot device revised guidance (85685)

P.S. Перевод выполнен комбинацией машинного обучения и человеческого интеллекта в пропорции 99/1. Если есть пожелание поправить чего, то пишите в комментарии.

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.

Недостаточно Инод (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%:

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

Start upgrade process

Now you are ready to upgrade. Replace the profile name of the following command (ESXi-6.0.0-20150704001-standard) with your prefered profile name to upgrade to. It takes some minutes until the Update Result is displayed.

~ # esxcli software profile update -d https://hostupdate.VMware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml -p ESXi-6.0.0-20150704001-standard

Update Result
   Message: The update completed successfully, but the system needs to be rebooted for the changes to be effective.
   Reboot Required: true
   VIBs Installed: VMware_bootbank_esx-base_6.0.0-0.11.2809209, VMware_bootbank_lsu-lsi-lsi-mr3-plugin_1.0.0-2vmw.600.0.11.2809209, ...
   VIBs Removed: Hewlett-Packard_bootbank_scsi-hpsa_5.5.0.106-1OEM.550.0.0.1331820, LSI_bootbank_scsi-mpt2sas_15.10.06.00.1vmw-1OEM.550.0.0.1198610, ...
   VIBs Skipped: VMWARE_bootbank_mtip32xx-native_3.8.5-1vmw.600.0.0.2494585, VMware_bootbank_ata-pata-amd_0.3.10-3vmw.600.0.0.2494585, ...

Upgrade HP software and drivers

If you are using an HPE Server, you may want to upgrade all HP VIB’s too.

The simplest way to do this, is to directly fetch the HP VIB repo data.

~ # esxcli software vib update -d https://vibsdepot.hpe.com/hpe/hpe-index.xml
 
 Could not download from depot at https://vibsdepot.hpe.com/hpe/hpe-index.xml, skipping (('https://vibsdepot.hpe.com/hpe/hpe-index.xml', '', ' HTTP Error 404: Not Found'))
        url = https://vibsdepot.hpe.com/hpe/hpe-index.xml
 Please refer to the log file for more details.

But I bet it won’t work for you, too. HP and VMware seemes to share their website developers and hosters, because the availability and performance of both sites is really bad.

Another way to upgrade is to download the depot and do an offline installation.

Download the depot ZIP file on https://my.VMware.com/. You will find it in the section “Custom ISOs”. It’s name will be similar to “VMware-ESXi-6.0.0-Update2-3620759-HPE-600.U2.9.4.7.13-Mar2016-depot.zip”. Now you have to extract the ZIP file on a datastore which is accessible by your ESX (myDataStore).

Update the HP VIB’s with the local depot.

~ # esxcli software vib update --depot=file:///vmfs/volumes/myDataStore/VMware-ESXi-6.0.0-Update2-3620759-HPE-600.U2.9.4.7.13-Mar2016-depot/index.xml
Installation Result
   Message: The update completed successfully, but the system needs to be rebooted for the changes to be effective.
   Reboot Required: true
   VIBs Installed: BRCM_bootbank_net-tg3_3.137l.v60.1-1OEM.600.0.0.2494585, EMU_bootbank_elxnet_10.5.121.7-1OEM.600.0.0.2159203, ...
   VIBs Removed: Broadcom_bootbank_misc-cnic-register_1.710.70.v55.1-1OEM.550.0.0.1331820, Broadcom_bootbank_net-bnx2_2.2.5f.v55.16-1OEM.550.0.0.1331820, ...
   VIBs Skipped: Hewlett-Packard_bootbank_char-hpcru_6.0.6.14-1OEM.600.0.0.2159203, Hewlett-Packard_bootbank_char-hpilo_600.9.0.2.8-1OEM.600.0.0.2159203, ...

Плохие блоки

Ещё одна распространённая проблема — это плохие блоки в файловой системе. Со временем из-за износа дисков, файловые системы повреждаются. Ваша операционная система, скорее всего, увидит эти блоки пригодными для использования, если они не помечены иным образом. Лучший способ найти и пометить эти блоки — использовать fsck с флагом -cc. Помните, что вы не можете использовать fsck из той же файловой системы, которую тестируете. Вам, вероятно, понадобится использовать Live CD.

замените /dev/sda1 на имя того диска и раздела, который вы хотите проверить. Кроме того, имейте в виду, что это, вероятно, займёт много времени.

Надеюсь, одно из этих решений решило вашу проблему. Эту проблему не всегда легко диагностировать в каждом случае. Однако, если повезёт, вы сможете устранить источник проблемы и продолжить пользоваться системой без её переустановки.

Кстати, сообщение “No space left on device” может возникнуть при попытке записать файл размером более 4GB на раздел с файловой системой FAT — данная файловая система не поддерживает файлы таких больших размеров.

Также можете вступить в Телеграм канал, или подписаться на . Ссылки в шапке страницы. Заранее всем спасибо!!!

How Bobcares helps prevent disk errors

All of what we have said here today is more “reactive” that “proactive”.

We said how we would RECOVER a server once a service fails with this error.

Here at Bobcares, our aim is to PREVENT such errors from happenig in the first place.

How do we do it? By being proactive.

We maintain production servers of web hosts, app developers, SaaS providers and other online businesses.

An important part in this maintenance service is Periodic Server Audits.

During audits, expert server administrators manually check every part of the server and fix everything that can affect the uptime of services.

Some of the checks to prevent disk errors are:

• Inode and Space usage – We check the available disk space and inodes in a server, and compare it with previous audit results. If we see an abnormal increase in the usage, we investigate in detail and regulate the service that’s causing the file growth.
• Temp folder auto-clearence – We setup scripts that keep the temp folders clean, and during the audits make sure that the program is working fine.
• Spam and catchall folders – We look for high volume mail directories, and delete accounts that are no longer maintained. This is has many times helped us prevent quota overage.
• Unused accounts deletion – Old user accounts that were either canceled or migrated out sometimes remain back in the server. We find and delete them.
• Old backups deletion – Sometimes people can leave uncompressed backups lying around. We detect such unused archives and delete them.
• Log file maintenance – We setup log rotation services that clears our old log files as it reaches a certain size limit. During our periodic audit we make sure these services are working well.
• Old packages deletion – Linux can leave old application installation packages even after an application is setup. We clear out old unused installation archives.
• Old application deletion – We scan for application folders that are no longer accessed, and delete unused apps and databases.

Of course, there are many more ways in which the disk space could be used up.

So, we customize the service for each of our customers, and make sure no part is left unchecked.

Over time this has helped us achieve close to 100% uptime for our customer servers.

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’

Проблемы с сетью

Resolve Не настраивать распределенный виртуальный порт NSX для использования трафика PVRDMA.

Issue: Сетевые адаптеры Solarflare x2542 и x2541, настроенные в режиме порта 1x100G, достигают пропускной способности до 70 Гбит/с в среде vSphere. Несмотря на то, что vSphere 7.0U2 поддерживает такие сетевые адаптеры, можно наблюдать ограничение по «железу» в устройствах.

Resolve нет.

Issue: После перезагрузки NIC трафик VLAN может упасть. NIC с PCI идентификатором устройства 8086:1537 может перестать посылать и получать тэггированные VLAN пакеты после перезагрузки, например, с командой: «vsish -e set /net/pNics/vmnic0/reset 1»

Resolve Избегать перезагрузки NIC. Если же проблема все-таки случилась, использовать для восстановления возможностей VLAN команды (пример для vmnic0):

# esxcli network nic software set –tagging=1 -n vmnic0
# esxcli network nic software set –tagging=0 -n vmnic0

Issue: Любое изменение в параметрах NetQueue балансера с помощью команды:

esxcli/localcli network nic queue loadbalancer set -n <nicname> –<lb_setting>

ведет к выключению NetQueue после перезагрузки ESXi-хоста.

Resolve После всего проделанного использовать команду:

configstorecli config current get -c esx -g network -k nics

для получения данных ConfigStore для подтверждения, работает ли «/esx/network/nics/net_queue/load_balancer/enable» как ожидается. Вывод должен быть примерно таким:

{
“mac”: “02:00:0e:6d:14:3e”,
“name”: “vmnic1”,
“net_queue”: {
“load_balancer”: {
“dynamic_pool”: true,
“enable”: true
}
},
“virtual_mac”: “00:50:56:5a:21:11”
}

Если же в нем встречается, например, «load_balancer”: “enable”: false», запустить следующее:

esxcli/localcli network nic queue loadbalancer state set -n <nicname> -e true

Issue: Задержка чтения адаптеров QLogic 16Gb Fibre Channel, поддерживаемых драйвером qlnativefc, растет при некоторых условиях. Если ВМ зашифрована, задержка последовательного чтения увеличивается на 8% в ESXi 7.0 Update 2 по сравнению с тем, что было актуально для ESXi 7.0 Update 1. Для незашифрованных машин она растет на 15-23%.

Resolve: нет.