SOREX.ORG: заметки с тегом esxi

Как узнать UUID в ESXI 5.5

sorex — Mon, 15 Nov 2021 06:06:50 +0000

The vCenter does have a UUID.

To view it simply go to https://VC-FQDN/mob

Click on RetrieveServiceContent -> Invoke Method

The UUID is listed as instanceUuid.

vCenter 6.7 уменьшить память для установки

sorex — Tue, 14 Sep 2021 06:24:25 +0000

В папке установки VMware VCSA перейдите в Vcsa-ui-installer \ win32 \ resources \ app \ resources.
Откройте файл с именем layout.json в Блокноте.
Вы можете сначала создать копию этого файла.
Внутри layout.json файла, прокрутите вниз до «tiny». Существует несколько вариантов, поэтому убедитесь, что вы выбрали вариант с меткой: «Tiny vCenter Server со встроенным PSC», который зависит от размера развертывания, Tiny, размера хранилища, по умолчанию (300 ГБ) и со встроенным PSC.
недостаточно памяти на хосте для выбранного размера
Измените «память» на желаемое значение. 6 ГБ (6144 МБ) в моем случае. Сохраните изменения.
В следующий раз, когда вы запустите установку VCSA, вы увидите, что развертывание Tiny было уменьшено до 6 ГБ (или вашего значения)
недостаточно памяти на хосте для выбранного размера
Теперь вы можете продолжить развертывание VCSA.
Примечание. Это изменение не отразится на виртуальном оборудовании при создании VCSA (ВМ), его нельзя изменить, и вы по-прежнему видите 10 ГБ. Но из монитора ресурсов вы увидите, что в качестве ограничения используется 6 ГБ.

Перенос qcow диска из libvirt в ESXi

sorex — Mon, 06 Sep 2021 11:19:24 +0000

qemu-img convert -f qcow2 myImage.qcow2 -O vmdk myNewImage.vmdk
потом переносим на esxi и в консоли хоста делаем:
vmkfstools -i myImage.vmdk outputName.vmdk -d thin
на выходе получаем 2 файла один заголовок диска и второй flat диск

Отключаем сообщение The number of vSphere HA heartbeat datastores for this host is 1 which is less than required 2 в ESXI 5.X.X

sorex — Tue, 13 Apr 2021 10:18:44 +0000

Данное сообщение появилось с введением в механизм VMware HA функционала Datastore Heartbeating, который позволяет хостам кластера общаться посредством хранилища данных и за счет этого более корректно отрабатывать ситуации, связанные с изоляцией хоста.

Сообщает оно о том, что для общения хостов используется только 1 общее хранилище, а рекомендуется минимум 2 (для надежности). Это может быть связано либо с тем, что в настройках кластера жестко выставлено использование только 1 хранилища, либо у вас всего 1 общее хранилище.

В 1-м случае лучше выставить автоматическое определение используемых датасторов, а во втором случае можно просто отключить сообщение, особенно, если инфраструктура тестовая.

Отключается так — Правой по кластеру -> Edit Settings -> vSphere HA -> Advanced

The number of vSphere HA heartbeat datastores for this host is 1 which is less than required 2-01

Дальше добавляем пункт «das.ignoreinsufficienthbdatastore» со значением «true»:

The number of vSphere HA heartbeat datastores for this host is 1 which is less than required 2-02

Ускорение домашнего ESXi 6.5 с помощью SSD кэширования

sorex — Tue, 13 Apr 2021 10:00:03 +0000

В данной статье хочу рассказать о том, как немного повысить производительность хоста ESXi с помощью SSD кэширования. На работе и дома я использую продукты от компании VMware, домашняя лаборатория построена на базе Free ESXi 6.5. На хосте запущены виртуальные машины как для домашней инфраструктуры, так и для тестирования некоторых рабочих проектов (как-то мне пришлось запустить на нем инфраструктуру VDI). Постепенно приложения толстых ВМ начали упираться в производительность дисковой системы, а на SDD все не помещалось. В качестве решения был выбран lvmcache. Логическая схема выглядит так:

Основой всей схемы является ВМ svm на базе CentOS 7. Ей презентованы HDD диски средствами RDM и небольшой диск VMDK с датастора SSD. Кэширование и зеркалирование данных реализуются программными средствами — mdadm и lvmcache. Дисковое пространство ВМ монтируется к хосту как NFS датастор. Часть датастора SSD отведена ВМ, которым требуется производительная дисковая подсистема.

Вычислительный узел собран на десктопном железе:

MB: Gygabyte GA-Z68MX-UD2H-B3 (rev. 1.0)
HDD: 2 x Seagate Barracuda 750Gb, 7200 rpm
SSH: OCZ Vertex 3 240Gb

На материнской плате имеется 2 RAID контроллера:

— Intel Z68 SATA Controller
— Marvell 88SE9172 SATA Controller

Завести 88SE9172 в ESXi у меня не получилось (There is a bug in the firmware of some Marvell adapters (at least 88SE91xx)), решил оставить оба контроллера в режиме ACHI.

RDM

Технология RDM (Raw Device Mapping) позволяет виртуальной машине обращаться напрямую к физическому накопителю. Связь обеспечивается через специальные файлы «mapping file» на отдельном томе VMFS. RDM использует два режима совместимости:

— Виртуальный режим — работает так же, как и в случае с файлом виртуального диска, позволяет использовать преимущества виртуального диска в VMFS (механизм блокировки файлов, мгновенные снэпшоты);
— Физический режим — предоставляет прямой доступ к устройству для приложений, которые требуют более низкого уровня управления.

В виртуальном режиме на физическое устройство отправляются операции чтения\записи. RDM устройство представлено в гостевой ОС как файл виртуального диска, аппаратные характеристики скрыты.

В физическом режиме на устройство передаются практически все команды SCSI, в гостевой ОС устройство представлено как реальное.

Подключив дисковые накопители к ВМ средствами RDM, можно избавиться от прослойки VMFS, а в физическом режиме совместимости их состояние можно будет мониторить в ВМ (с помощью технологии S.M.A.R.T.). К тому же, если что-то случится с хостом, то получить доступ к ВМ можно, примонтировав HDD к рабочей системе.

lvmcache

lvmcache обеспечивает прозрачное кэширование данных медленных устройств HDD на быстрых устройствах SSD. LVM cache размещает наиболее часто используемые блоки на быстром устройстве. Включение и выключение кэширования можно производить, не прерывая работы.

При попытке чтения данных выясняется, имеются ли эти данные в кэше. Если требуемых данных там нет, то чтение происходит с HDD, и попутно данные записываются в кэш (cache miss). Дальнейшее чтение данных будет происходить из кэша (cache hit).

Запись

— Режим write-through — когда происходит операция записи, данные записываются и в кэш, и на HDD диск, более безопасный вариант, вероятность потери данных при аварии мала;
— Режим write-back — когда происходит операция записи, данные записываются сначала в кэш, после чего сбрасываются на диск, имеется вероятность потери данных при аварии. (Более быстрый вариант, т. к. сигнал о завершении операции записи передается управляющей ОС после получения данных кэшем).

Так выглядит сброс данных из кэша (write-back) на диски:

Настройка системы

На хосте создается SSD датастор. Я выбрал такую схему использования доступного пространства:

220Gb — DATASTORE_SSD
149Gb — Отведено для особых ВМ
61Gb — Том для кэша и метаданных
10Gb — Host Swap Cache

Виртуальная сеть выглядит следующим образом:

Создан новый vSwitch:

Networking → Virtual Switches → Add standart virtual switch — указываем желаемое имя виртуального свитча (svm_vSwitch, в названиях я использую префикс svm_), остальное оставляем как есть.

К нему через порт группу подключается VMkernel NIC:

Networking → VMkernel NICs → Add VMkernel NIC
— Port group — New Port group
— New port group — Имя порт группы — svm_PG
— Virtual switch — svm_vSwitch
— IPv4 settings — Configuration — Static — указываем IP и маску сети

Создана порт группа, к которой будет подключена ВМ svm:

Networking → Port Groups → Add port group — указываем имя (svm_Network) и свитч svm_vSwitch

Подготовка дисков

Необходимо зайти на хост по ssh и выполнить следующие команды:

Отобразить пути всех подключенных дисков:
	# ls -lh /vmfs/devices/disks/
lrwxrwxrwx    1 root     root          72 Feb 22 20:24 vml.01000000002020202020202020202020203956504257434845535433373530 -> t10.ATA_____ST3750525AS_________________________________________9*E
lrwxrwxrwx    1 root     root          72 Feb 22 20:24 vml.01000000002020202020202020202020203956504257434b46535433373530 -> t10.ATA_____ST3750525AS_________________________________________9*F

Перейти в директорию, где будут размещаться «mapping file»:
	# cd /vmfs/volumes/DATASTORE_SSD/

Создаем RDM в режиме виртуальной совместимости:
	# vmkfstools -r /vmfs/devices/disks/vml.01000000002020202020202020202020203956504257434845535433373530 9*E.vmdk
	# vmkfstools -r /vmfs/devices/disks/vml.01000000002020202020202020202020203956504257434b46535433373530 9*F.vmdk

Подготовка ВМ

Теперь эти диски можно подключить (Existing hard disk) к новой ВМ. Шаблон CentOS 7, 1vCPU, 1024Gb RAM, 2 RDM disk, 61Gb ssd disk, 2 vNIC (порт группы VM Network, svm_Network) — во время установки ОС используем Device Type — LVM, RAID Level — RAID1

Настройка NFS сервера довольно проста:

# yum install nfs-utils
# systemctl enable rpcbind
# systemctl enable nfs-server
# systemctl start rpcbind
# systemctl start nfs-server
# vi /etc/exports
	/data 10.0.0.1(rw,sync,no_root_squash,no_subtree_check)
# exportfs -ar
# firewall-cmd add-service=nfs permanent
# firewall-cmd add-service=rpc-bind permanent
# firewall-cmd add-service=mountd permanent
# firewall-cmd —reload

Подготавливаем тома кэша и метаданных для включения кэширования тома cl_svm/data:

Инициализация диска и расширение группы томов:
	# pvcreate /dev/sdc
	# vgextend cl_svm /dev/sdc
Создание тома с метаданными, в «man» написано, что этот том должен быть в 1000 раз меньше тома с кэшем:
	# lvcreate -L 60M -n meta cl_svm /dev/sdc
Создание тома с кэшем:
	# lvcreate -L 58,9G -n cache cl_svm /dev/sdc
Создание кэш-пула из томов:
	# lvconvert type cache-pool cachemode writethrough —poolmetadata cl_svm/meta cl_svm/cache
Связываем подготовленный кэш-пул с томом данных:
	# lvconvert type cache cachepool cl_svm/cache cl_svm/data 
Статистику можно посмотреть в выводе:
	# lvs -o cache_read_hits,cache_read_misses,cache_write_hits,cache_write_misses
CacheReadHits    CacheReadMisses  CacheWriteHits   CacheWriteMisses
            421076           282076           800554          1043571

Уведомления о изменении состояния массива:

В конце файла /etc/mdadm.conf нужно добавить параметры, содержащие адрес, на который будут отправляться сообщения в случае проблем с массивом, и, если необходимо, указать адрес отправителя:

MAILADDR alert@domain.ru
MAILFROM svm@domain.ru

Чтобы изменения вступили в силу, нужно перезапустить службу mdmonitor:

#systemctl restart mdmonitor

Почта с ВМ отправляется средствами ssmtp. Так как я использую RDM в режиме виртуальной совместимости, то проверять состояние дисков будет сам хост.

Подготовка хоста

Добавляем NFS датастор в ESXi:

Storage → Datastores → New Datastore → Mount NFS Datastore
Name: DATASTORE_NFS
NFS server: 10.0.0.2
NFS share: /data

Настройка автозапуска ВМ:

Host → Manage → System → Autostart → Edit Settings
Enabled — Yes
Start delay — 180sec
Stop delay — 120sec
Stop action — Shut down
Wait for heartbeat — No

Virtual Machines → svm → Autostart → Increase Priority
(Автозапуск не сработал, пришлось удалить ВМ из Inventory и добавить заново)

Данная политика позволит ВМ svm запуститься первой, гипервизор примонтирует NFS датастор, после этого будут включаться остальные машины. Выключение происходит в обратном порядке. Время задержки запуска ВМ подобрано по итогам краш-теста, т. к. при малом значении Start delay NFS датастор не успевал примонтироваться, и хост пытался запустить ВМ, которые еще недоступны. Также можно поиграться параметром

NFS.HeartbeatFrequency

Более гибко автостарт ВМ можно настроить с помощью командной строки:

Посмотреть параметры автозапуска для ВМ:
	# vim-cmd hostsvc/autostartmanager/get_autostartseq
Изменить значения автостарта для ВМ (синтаксис):
	# update_autostartentry VMId StartAction StartDelay StartOrder StopAction StopDelay WaitForHeartbeat
Пример:
	# vim-cmd hostsvc/autostartmanager/update_autostartentry 3 «powerOn» «120» «1» «guestShutdown» «60» «systemDefault»

Небольшая оптимизация

Включить Jumbo Frames на хосте:

Jumbo Frames: Networking → Virtual Switches → svm_vSwitch указать MTU 9000;
Networking → Vmkernel NICs → vmk1 указать MTU 9000

В Advanced Settings установить следующие значения:

NFS.HeartbeatFrequency = 12
NFS.HeartbeatTimeout = 5
NFS.HeartbeatMaxFailures = 10
Net.TcpipHeapSize = 32 (было 0)
Net.TcpipHeapMax = 512
NFS.MaxVolumes = 256
NFS.MaxQueueDepth = 64 (было 4294967295)

Включить Jumbo Frames на ВМ svm:

# ifconfig ens224 mtu 9000 up
# echo MTU=9000 >> /etc/sysconfig/network-scripts/ifcfg-ens224

Производительность

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

Используемое ПО на тестовой ВМ:

— ОС CentOS 7.3.1611 (8 vCPU, 12Gb vRAM, 100Gb vHDD)
— fio v2.2.8

Последовательность команд запуска теста:
	# dd if=/dev/zero of=/dev/sdb bs=2M oflag=direct
	# fio -readonly -name=rr -rw=randread -bs=4k -runtime=300 -iodepth=1 -filename=/dev/sdb -ioengine=libaio -direct=1
	# fio -readonly -name=rr -rw=randread -bs=4k -runtime=300 -iodepth=24 -filename=/dev/sdb -ioengine=libaio -direct=1
	# fio  -name=rw -rw=randwrite -bs=4k -runtime=300 -iodepth=1 -filename=/dev/sdb -ioengine=libaio -direct=1
	# fio -name=rw -rw=randwrite -bs=4k -runtime=300 -iodepth=24 -filename=/dev/sdb -ioengine=libaio -direct=1

Полученные результаты представлены в таблицах (* во время тестов отмечал среднюю загрузку ЦП на ВМ svm):

VMFS6 Datastore
Тип диска	FIO depth 1 (iops)		FIO depth 24 (iops)
Тип диска	randread	randwrite	randread	randwrite
HDD	77	99	169	100
SSD	5639	17039	40868	53670

NFS Datastore
SSD Cache	FIO depth 1 (iops)		FIO depth 24 (iops)		CPU/Ready* %
SSD Cache	randread	randwrite	randread	randwrite	CPU/Ready* %
Off	103	97	279	102	2.7/0.15
On	1390	722	6474	576	15/0.1

Рабочий кластер
Тип диска	FIO depth 1 (iops)		FIO depth 24 (iops)
Тип диска	randread	randwrite	randread	randwrite
900Gb 10k (6D+2P)	122	1085	2114	1107
4Tb 7.2k (8D+2P)	68	489	1643	480

Результаты, которые можно потрогать руками, получились при одновременном запуске пяти ВМ с Windows 7 и офисным пакетом (MS Office 2013 Pro + Visio + Project) в автозагрузке. По мере нагревания кэша, ВМ грузились быстрее, при этом HDD практически не участвовал в загрузке. При каждом запуске отмечал время полной загрузки одной из пяти ВМ и полной загрузки всех ВМ.

Одновременный запуск пяти ВМ
№	Datastore	Первый запуск		Второй запуск		Третий запуск
№	Datastore	Время загрузки первой ВМ	Время загрузки всех ВМ	Время загрузки первой ВМ	Время загрузки всех ВМ	Время загрузки первой ВМ	Время загрузки всех ВМ
1	HDD VMFS6	4мин. 8сек.	6мин. 28сек.	3мин. 56сек.	6мин. 23сек.	3мин. 40сек.	5мин. 50сек.
2	NFS (SSD Cache Off)	2мин. 20сек.	3мин. 2сек.	2мин. 34сек.	3мин. 2сек.	2мин. 34сек.	2мин. 57сек.
3	NFS (SSD Cache On)	2мин. 33сек.	2мин. 50сек.	1мин. 23сек.	1мин. 51сек.	1мин. 0сек.	1мин. 13сек.

Время загрузки одиночной ВМ составило:

— HDD VMFS6 - 50 секунд
— NFS с выключенным кэшем - 35 секунд
— NFS с включенным и нагретым кэшем - 26 секунд

В виде графика:

Краш-тест

Отключение питания

После включения и загрузки хоста ВМ svm загрузилась с проверкой ФС (данные остались в кэше), на хосте примонтировался NFS датастор, далее загрузились остальные ВМ, проблем и потери данных не наблюдалось.

Выход из строя HDD (имитация)

Решил отключить питание SATA диска. К сожалению, горячая замена не поддерживается, необходимо аварийно выключать хост. Сразу после отключения диска появляется информация в Events.

Неприятным моментом оказалось, что при потере диска гипервизор просит для ВМ svm ответить на вопрос — «You may be able to hot remove this virtual device from the virtual machine and continue after clicking Retry. Click Cancel to terminate this session» — машина находится в состоянии фриза.

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

Выход из строя SSD

Наиболее неприятная ситуация — выход ssd из строя. Доступ к данным осуществляется в аварийном режиме. При замене ssd необходимо повторить процедуру настройки системы.

Обслуживание (Замена диска)

Если с диском вот-вот случится беда (по результатам S.M.A.R.T.), для того чтобы заменить его на рабочий необходимо выполнить следующую процедуру (на ВМ svm):

Посмотреть общее состояние массива: 
	# cat /proc/mdstat 
или для каждого устройства: 
	# mdadm —detail /dev/md126 /dev/md126
Пометить разделы неисправными:
	# mdadm manage /dev/md127 fail /dev/sda1 
	# mdadm manage /dev/md126 fail /dev/sda2
Удалить сбойные разделы из массива:
	# mdadm manage /dev/md127 remove /dev/sda1
	# mdadm manage /dev/md126 remove /dev/sda2

В настройках ВМ нужно «оторвать» погибающий vHDD, затем заменить HDD на новый.
После чего подготовить RDM накопитель и добавить к ВМ svm:

Перечитать список устройств, где X — номер SCSI шины Virtual Device Node в настройках vHDD:
	# echo «- — -» > /sys/class/scsi_host/hostX/scan
С помощью sfdisk скопировать структуру разделов:
	# sfdisk -d /dev/sdb | sfdisk /dev/sdc
Добавить получившиеся разделы в массив, установить загрузчик и дождаться окончания синхронизации:
	# mdadm manage /dev/md127 add /dev/sdc1
	# mdadm manage /dev/md126 add /dev/sdc2
	# grub2-install /dev/sdc

Аварийный доступ к данным

Один из дисков подключается к рабочей станции, далее необходимо «собрать» RAID, отключить кэш и получить доступ к данным, примонтировав LVM том:

# mdadm assemble scan
# lvremove cl_svm/cache 
# lvchanange -ay /dev/cl_svm/data
# mount /dev/cl_svm/data /mnt/data

Также я пробовал загрузить систему непосредственно с диска, настроил сеть и на другом хосте подключил NFS датастор — ВМ доступны.

Резюме

В итоге, я использую lvmcache в режиме write-through и раздел для кэша размером 60Gb. Немного пожертвовав ресурсами CPU и RAM хоста — вместо 210Gb очень быстрого и 1.3Tb медленного дискового пространства я получил 680Gb быстрого и 158Gb очень быстрого, при этом появилась отказоустойчивость (но при неожиданном выходе из строя диска придется поучаствовать в процессе доступа к данным).

NFS сервер для ESXi

sorex — Tue, 13 Apr 2021 09:46:47 +0000

apt-get install nfs-kernel-server

Создаем папку, которую будем расшаривать

mkdir ~/share

Далее, открываем на редактирование файл /etc/exports

sudo nano /etc/exports

Вставляем туда следующую строчку

/home/goodigy/share 192.168.1.0/24(rw,async,insecure,nohide,all_squash,anonuid=1000,anongid=1000)

Параметры:

/home/goodigy/share — путь к нашей расшариваемой папке,
192.168.1.0/24 — доступ только из моей подсети,
rw — чтение запись, или ro — только чтение,
async — асинхронный режим доступа, сервер не ждет записи на диск, передает во время нее. Не надежно, но быстро. Для более надежного доступа, есть синхронный доступ sync.
all_squash — все подключения от анонимного польхователя,
anonuid=1000,anongid=1000 — приравнивает анонимного пользователя к моему, если у вас id пользователя отличается от 1000, впишите свой, узнать «id goodigy»
hide — будут использоваться порты меньше 1024, отключить это требование - nohide.

Перезапустим nfs сервер

sudo service nfs-kernel-server restart

Проблемы с контроллером HP p410 при установке драйвера не на сервера HP

sorex — Tue, 13 Apr 2021 09:39:29 +0000

Для установки hpssacli нужно переделать vib файл а именно удалить из него проверку на биос вендора HP, для этого потребуется перепаковать файл vib

распаковываем

ar vx file.vib

Далее редактируем descriptor.xml, удаляем строки

Собираем vib обратно

ar -r hpssacli_n.vib hpssacli descriptor.xml sig.pkcs7

Закидываем на хост и ребут

/tmp # esxcli software vib install -f -v hpssacli_n.vib
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: Hewlett-Packard_bootbank_hpssacli_2.30.6.0-6.0.0.2159203
VIBs Removed:
VIBs Skipped:

Установлено: VMware-ESXi-5.5.0-Update3-3568722-HPE-550.9.6.5.9-Dec2016.iso

Версия драйвера дисков: — scsi-hpvsa-5.5.0.100-1OEM.550.0.0.1331820

Как выяснилось, HP что-то испортили в драйвере дисковой подсистемы для ESXi 5.5 и работа с дисками стала … скажем так, не очень эффективной. Более того, как выяснилось позже, такая же проблема существует и в гипервизорах ESXi 6.0/6.5 от HPE.

Насколько не эффективно? Результаты замеров в статье. Сразу скажу — оглушающие.

Пообщавшись со знакомыми и покопав Интернет было выяснено, что всему виной и правда, драйвер, который HPE включила в свой кастомный образ с установщиком гипервизора ESXi 5.5 и более поздних версий.

Но, решение этой проблемы есть. Совместными усилиями Интернет-сообщества (https://homeservershow.com) был найден драйвер, который реально ускоряет работу с дисками в HP Microserver Gen8.

Версия драйвера: scsi-hpvsa-5.5.0-88OEM.550.0.0.1331820

Сам драйвер можно легально, бесплатно и без регистрации, скачать c сайта HPE:
https://support.hpe.com/hpsc/swd/…b1dfc5314e02bc01b1436b
Type: Driver — Storage Controller
Version: 5.5.0-88.0(9 Sep 2014)
Operating System(s): VMware vSphere 5.5
File name: scsi-hpvsa-5.5.0-88OEM.550.0.0.1331820.x86_64.vib (707 KB)

Осталось его установить. Как это сделать, описано ниже.

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

А) Заходим в консоль ESXi хоста через PuTTY под именем root и запускаем команду

esxcli software vib list | grep scsi

Вот, что было у меня до смены драйвера

~ # esxcli software vib list | grep scsi

scsi-hpsa 5.5.0.124-1OEM.550.0.0.1331820 HPE VMwareCertified 2018-04-10
scsi-hpdsa 5.5.0.52-1OEM.550.0.0.1331820 Hewlett-Packard PartnerSupported 2018-04-10
scsi-hpvsa 5.5.0.100-1OEM.550.0.0.1331820 Hewlett-Packard PartnerSupported 2018-04-10
scsi-mpt2sas 15.10.06.00.1vmw-1OEM.550.0.0.1198610 LSI VMwareCertified 2018-04-10
scsi-bfa 3.2.6.0-1OEM.550.0.0.1331820 QLogic VMwareCertified 2018-04-10
scsi-bnx2fc 1.713.20.v55.4-1OEM.550.0.0.1331820 QLogic VMwareCertified 2018-04-10
scsi-bnx2i 2.713.10.v55.3-1OEM.550.0.0.1331820 QLogic VMwareCertified 2018-04-10
scsi-qla4xxx 644.55.37.0-1OEM.550.0.0.1331820 QLogic VMwareCertified 2018-04-10

То есть. Не тот. Почему? А вот, что показал тест производительности. Не то чтобы тест, но из приведенных команд видно, что тестируется.

Выполняем следующие команды из консоли ESXI:

cd /vmfs/volumes/[datastore]<br>time dd if=/dev/zero of=tempfile bs=8k count=1000000

Примечание: Не забудьте поменять [datastore] на имя вашего реального DataStore.

Получаем результат:
1000000+0 records in
1000000+0 records out
real 14m 12.62s
user 0m 12.23s
sys 0m 0.00s

Вроде бы не плохо, да?

Для сравнения, в той же конфигурации, но с установленным, ESXi 5.1U3 получаем примерно следующее:
1000000+0 records in
1000000+0 records out
real 17m 25.62s
user 0m 7.23s
sys 0m 0.00s

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

Итак, приступаем к смене драйвера.

Процедура достаточно простая. Предполагается, что нужный драйвер Вы уже скачали с сайта HP, по приведенный ранее ссылке.

Останавливаем все запущенные VMs
Если не включено, включаем ssh
Копируем файл «scsi-hpvsa-5.5.0-88OEM.550.0.0.1331820.x86_64.vib» to /tmp (например, с помощью WinSCP)
Подключаемся к консоли гипервизора ESXi с помощью PuTTY (с правами root, естественно)
Меняем текущую папку на ту, куда положили файл, то есть на папку /tmp
```
cd /tmp
```

Копируем vib-файл в папку из которой он будет инсталлирован
```
cp scsi-hpvsa-5.5.0-88OEM.550.0.0.1331820.x86_64.vib /var/log/vmware/
```

Переводим гипервизор в Maintenance Mode
```
esxcli system maintenanceMode set --enable true
```

Удаляем текущий драйвер дисковой подсистемы
```
esxcli software vib remove -n scsi-hpvsa -f
```

Инсталлируем правильный драйвер scsi-hpvsa-5.5.0-88OEM из файла

esxcli software vib install -v file:scsi-hpvsa-5.5.0-88OEM.550.0.0.1331820.x86_64.vib --force --no-sig-check --maintenance-mode

Перезапускаем ESXi, отключаем Maintenance Mode, запрещаем ssh (если нужно) и запускаем свои виртуальные машинки.

Примечание: Отключить Maintenace Mode можно из клиента или из консоли, командой:

esxcli system maintenanceMode set --enable false

Все просто? Да, просто.

Но ведь всегда хочется убедиться, что автор не наврал.

Проверяем, что версия драйвера изменилась.

esxcli software vib list | grep scsi

scsi-hpsa 5.5.0.124-1OEM.550.0.0.1331820 HPE VMwareCertified 2018-04-10
scsi-hpdsa 5.5.0.52-1OEM.550.0.0.1331820 Hewlett-Packard PartnerSupported 2018-04-10
scsi-hpvsa 5.5.0-88OEM.550.0.0.1331820 Hewlett-Packard PartnerSupported 2018-04-10
scsi-mpt2sas 15.10.06.00.1vmw-1OEM.550.0.0.1198610 LSI VMwareCertified 2018-04-10
scsi-bfa 3.2.6.0-1OEM.550.0.0.1331820 QLogic VMwareCertified 2018-04-10
scsi-bnx2fc 1.713.20.v55.4-1OEM.550.0.0.1331820 QLogic VMwareCertified 2018-04-10
scsi-bnx2i 2.713.10.v55.3-1OEM.550.0.0.1331820 QLogic VMwareCertified 2018-04-10
scsi-qla4xxx 644.55.37.0-1OEM.550.0.0.1331820 QLogic VMwareCertified 2018-04-10

Да. Изменилась на правильную.

А скорость? Не обманули? Проверяем! Что я и сам сделал. Запустил, повторно, тест производительности. Результат меня, мягко говоря, ошеломил

cd /vmfs/volumes/[datastore]<br>time dd if=/dev/zero of=tempfile bs=8k count=1000000

1000000+0 records in
1000000+0 records out
real 2m 6.73s
user 0m 5.21s
sys 0m 0.00s

Это в СЕМЬ раз быстрее, чем с предыдущим драйвером и почти в 9 раз быстрее чем на ESXI 5.1U3

На форуме пользователи подтвердили, что примерно такой же, не правильный, драйвер устанавливается и при инсталляции ESXi 6.0 и 6.5. И замена его на версию scsi-hpvsa-5.5.0-88OEM.550.0.0.1331820 приводит к такому же ускорению работы дисковой подсистемы.

Сброс настроек IPMI Supermicro через Ubuntu или Esxi 5.5

sorex — Tue, 13 Apr 2021 09:36:36 +0000

Для сброса закидывает всю папку linux\x64 и выполняем

chmod +x IPMICFG-Linux.x86_64; ./IPMICFG-Linux.x86_64 -fd

Ждем рестарта SMC и после этого входим по DHCP с логином паролем ADMIN ADMIN

IPMICFG_1.30.0_build.190710 Скачать

Ускорение датасторов HP в esxi 5.5

sorex — Tue, 13 Apr 2021 09:33:47 +0000

Установлено: VMware-ESXi-5.5.0-Update3-3568722-HPE-550.9.6.5.9-Dec2016.iso

Версия драйвера дисков: — scsi-hpvsa-5.5.0.100-1OEM.550.0.0.1331820

Насколько не эффективно? Результаты замеров в статье. Сразу скажу — оглушающие.

Версия драйвера: scsi-hpvsa-5.5.0-88OEM.550.0.0.1331820

Осталось его установить. Как это сделать, описано ниже.

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

А) Заходим в консоль ESXi хоста через PuTTY под именем root и запускаем команду

esxcli software vib list | grep scsi

Вот, что было у меня до смены драйвера

~ # esxcli software vib list | grep scsi

Выполняем следующие команды из консоли ESXI:

cd /vmfs/volumes/[datastore]<br>time dd if=/dev/zero of=tempfile bs=8k count=1000000

Примечание: Не забудьте поменять [datastore] на имя вашего реального DataStore.

Получаем результат:
1000000+0 records in
1000000+0 records out
real 14m 12.62s
user 0m 12.23s
sys 0m 0.00s

Вроде бы не плохо, да?

Итак, приступаем к смене драйвера.

Останавливаем все запущенные VMs
Если не включено, включаем ssh
Копируем файл «scsi-hpvsa-5.5.0-88OEM.550.0.0.1331820.x86_64.vib» to /tmp (например, с помощью WinSCP)
Подключаемся к консоли гипервизора ESXi с помощью PuTTY (с правами root, естественно)
Меняем текущую папку на ту, куда положили файл, то есть на папку /tmp
```
cd /tmp
```

Копируем vib-файл в папку из которой он будет инсталлирован
```
cp scsi-hpvsa-5.5.0-88OEM.550.0.0.1331820.x86_64.vib /var/log/vmware/
```

Переводим гипервизор в Maintenance Mode
```
esxcli system maintenanceMode set --enable true
```

Удаляем текущий драйвер дисковой подсистемы
```
esxcli software vib remove -n scsi-hpvsa -f
```

Инсталлируем правильный драйвер scsi-hpvsa-5.5.0-88OEM из файла

esxcli software vib install -v file:scsi-hpvsa-5.5.0-88OEM.550.0.0.1331820.x86_64.vib --force --no-sig-check --maintenance-mode

Перезапускаем ESXi, отключаем Maintenance Mode, запрещаем ssh (если нужно) и запускаем свои виртуальные машинки.

Примечание: Отключить Maintenace Mode можно из клиента или из консоли, командой:

esxcli system maintenanceMode set --enable false

Все просто? Да, просто.

Но ведь всегда хочется убедиться, что автор не наврал.

Проверяем, что версия драйвера изменилась.

esxcli software vib list | grep scsi

scsi-hpsa 5.5.0.124-1OEM.550.0.0.1331820 HPE VMwareCertified 2018-04-10
scsi-hpdsa 5.5.0.52-1OEM.550.0.0.1331820 Hewlett-Packard PartnerSupported 2018-04-10
scsi-hpvsa 5.5.0-88OEM.550.0.0.1331820 Hewlett-Packard PartnerSupported 2018-04-10
scsi-mpt2sas 15.10.06.00.1vmw-1OEM.550.0.0.1198610 LSI VMwareCertified 2018-04-10
scsi-bfa 3.2.6.0-1OEM.550.0.0.1331820 QLogic VMwareCertified 2018-04-10
scsi-bnx2fc 1.713.20.v55.4-1OEM.550.0.0.1331820 QLogic VMwareCertified 2018-04-10
scsi-bnx2i 2.713.10.v55.3-1OEM.550.0.0.1331820 QLogic VMwareCertified 2018-04-10
scsi-qla4xxx 644.55.37.0-1OEM.550.0.0.1331820 QLogic VMwareCertified 2018-04-10

Да. Изменилась на правильную.

cd /vmfs/volumes/[datastore]<br>time dd if=/dev/zero of=tempfile bs=8k count=1000000

1000000+0 records in
1000000+0 records out
real 2m 6.73s
user 0m 5.21s
sys 0m 0.00s

Это в СЕМЬ раз быстрее, чем с предыдущим драйвером и почти в 9 раз быстрее чем на ESXI 5.1U3

flashcache Centos

sorex — Tue, 13 Apr 2021 09:31:15 +0000

Разбивка в installimage

SSD: так как он первый, то закомментирован. Остальные секции
DRIVE: переименованы по номерами на 1 и 2.

SWRAIDLEVEL = 1

( по умолчанию на 3-х пытается создать 5-й RAID)

PART swap swap 32G
PART /boot ext3 512M
PART lvm vg0 all
LV vg0 vz /vz ext4 600G
LV vg0 root / ext4 all

Далее, в соответствии с установщиком. Нажимаем f10 и enter.

После загрузки сервера в обычном режиме с установленным чистым Centos, ставим OpenVZ. Установка описана здесь.

Теперь начинается самое интересное.

Установка flashcache

К сожалению, это не быстрый способ установки. Возможно, это из-за OpenVZ ядра. Мануал всего из двух строчек:

1) Подключаем репозиторий

rpm -Uvh http://elrepo.reloumirrors.net/elrepo/el6/x86_64/RPMS/elrepo-release-6-4.el6.elrepo.noarch.rpm

2) И устанавливаем

yum -y install kmod-flashcache flashcache-utils

На момент написания статьи было ядро OpenVZ rhel6-2.6.32 версии 042stab074.10.

Так как для сборки FlashCache требуются некоторые внутренние заголовочные файлы, которые не входят в состав пакета kernel-headers/devel, требуется загрузить и установить полный код ядра. Нам же не хватало vzkernel-headers.

yumdownloader —source kernel-`uname -r`
rpm -ivh kernel-`uname -r`.src.rpm

Далее скачиваем и устанавливаем:

git clone https://github.com/facebook/flashcache.git

cd flashcache

make -f Makefile.dkms

Esxi 5 получение данных smart

sorex — Tue, 13 Apr 2021 09:30:15 +0000

esxcli storage core device smart get -d t10.ATA_____SG9XCS1F50GMIBM______43W7729_59Y1873IBM_____________501010LJ

Parameter Value Threshold Worst
————————————— — -—— -—
Health Status N/A N/A N/A
Media Wearout Indicator N/A N/A N/A
Write Error Count N/A N/A N/A
Read Error Count N/A N/A N/A
Power-on Hours N/A N/A N/A
Power Cycle Count N/A N/A N/A
Reallocated Sector Count N/A N/A N/A
Raw Read Error Rate N/A N/A N/A
Drive Temperature N/A N/A N/A
Driver Rated Max Temperature N/A N/A N/A
Write Sectors TOT Count N/A N/A N/A
Read Sectors TOT Count N/A N/A N/A
Initial Bad Block Count N/A N/A N/A

Smartctl установка в esxi 5.5 u2 6.0 и прочие

sorex — Tue, 13 Apr 2021 09:29:15 +0000

Для полуяения полного отчета ставим пакет

Download
Copy the VIB to the /tmp/ directory of an ESXi host
SSH to the ESXi host
Set the VIB acceptance level to CommunitySupported
# esxcli software acceptance set —level=CommunitySupported
Install the package (Maintenance Mode or Reboot is not required)
#esxcli software vib install -v /tmp/smartctl-6.6-4321.x86_64.vib

The tool is located at /opt/smartmontools/smartctl and works just like the Linux version.
Locate physical disks with ls -l /dev/disks/

/opt/smartmontools/smartctl -d [Device Type] —all /dev/disks/[DISK]

# smartctl -d sat —all /dev/disks/t10.ATA_____Samsung_SSD_850_EVO_M.2_250GB___________S24BNXAG805065D_____
smartctl 6.6 2016-05-10 r4321 [x86_64-linux-6.0.0] (daily-20160510)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Samsung based SSDs
Device Model:     Samsung SSD 850 EVO M.2 250GB
Serial Number:    S24BNXAG805065D
LU WWN Device Id: 5 002538 d404b9f9f
Firmware Version: EMT21B6Q
User Capacity:    250,059,350,016 bytes [250 GB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    Solid State Device
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ACS-2, ATA8-ACS T13/1699-D revision 4c
SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
SMART support is: Available — device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART Status not supported: Incomplete response, ATA output registers missing
SMART overall-health self-assessment test result: PASSED
Warning: This result is based on an Attribute check.

General SMART Values:
Offline data collection status:  (0x00) Offline data collection activity
                                        was never started.
                                        Auto Offline Data Collection: Disabled.
Self-test execution status:      (   0) The previous self-test routine completed
                                        without error or no self-test has ever
                                        been run.
Total time to complete Offline
data collection:                (    0) seconds.
Offline data collection
capabilities:                    (0x53) SMART execute Offline immediate.
                                        Auto Offline data collection on/off support.
                                        Suspend Offline collection upon new
                                        command.
                                        No Offline surface scan supported.
                                        Self-test supported.
                                        No Conveyance Self-test supported.
                                        Selective Self-test supported.
SMART capabilities:            (0x0003) Saves SMART data before entering
                                        power-saving mode.
                                        Supports SMART auto save timer.
Error logging capability:        (0x01) Error logging supported.
                                        General Purpose Logging supported.
Short self-test routine
recommended polling time:        (   2) minutes.
Extended self-test routine
recommended polling time:        ( 133) minutes.
SCT capabilities:              (0x003d) SCT Status supported.
                                        SCT Error Recovery Control supported.
                                        SCT Feature Control supported.
                                        SCT Data Table supported.

SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       —       0
  9 Power_On_Hours          0x0032   099   099   000    Old_age   Always       —       5040
 12 Power_Cycle_Count       0x0032   099   099   000    Old_age   Always       —       35
177 Wear_Leveling_Count     0x0013   094   094   000    Pre-fail  Always       —       122
179 Used_Rsvd_Blk_Cnt_Tot   0x0013   100   100   010    Pre-fail  Always       —       0
181 Program_Fail_Cnt_Total  0x0032   100   100   010    Old_age   Always       —       0
182 Erase_Fail_Count_Total  0x0032   100   100   010    Old_age   Always       —       0
183 Runtime_Bad_Block       0x0013   100   100   010    Pre-fail  Always       —       0
187 Uncorrectable_Error_Cnt 0x0032   100   100   000    Old_age   Always       —       0
190 Airflow_Temperature_Cel 0x0032   049   034   000    Old_age   Always       —       51
195 ECC_Error_Rate          0x001a   200   200   000    Old_age   Always       —       0
199 CRC_Error_Count         0x003e   100   100   000    Old_age   Always       —       0
235 POR_Recovery_Count      0x0012   099   099   000    Old_age   Always       —       26
241 Total_LBAs_Written      0x0032   099   099   000    Old_age   Always       —       6345601655

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
No self-tests have been logged.  [To run self-tests, use: smartctl -t]

Warning! SMART Selective Self-Test Log Structure error: invalid SMART checksum.
SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
  255        0    65535  Read_scanning was never started
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

smartctl-6.6-4321.x86_64 Скачать