Esxi не видит ssd
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- VMware Technology Network
- :
- Cloud & SDDC
- :
- ESXi
- :
- ESXi Discussions
- :
- ESXi installation, SSD drive not recognized.
JulSolaris
- Mark as New
- Bookmark
- Subscribe
- Mute
- Email to a Friend
I'm trying desperately to install ESXi 6.7 on my mini-server but apparently my SSD is not recognized.
During the installation, I do not even have the window to propose me the installation on a disk, it starts directly in standalone on the USB key.
In addition, if I connect to the web client and I try to add a datastore, it does not offer me any disk, it's empty.
My motherboard is an Asus N3150I-C and my SSD is a PNY 120Gb CS900.
A compatibility problem? Someone sees a solution?
JulSolaris
- Mark as New
- Bookmark
- Subscribe
- Mute
- Email to a Friend
Resolved, I don't know how.
golddiggie
- Mark as New
- Bookmark
- Subscribe
- Mute
- Email to a Friend
In my experiences with PNY products, I've never seen one work with either ESXi or vSphere installs. I've had solid results with SandDisk and Kingston in comparison.
I would try another brand SSD on your host to see if it's something else with the motherboard or just the first SSD you tried.
JulSolaris
- Mark as New
- Bookmark
- Subscribe
- Mute
- Email to a Friend
I do not have another disk on hand but I'll see that. For you, it's a compatibility problem?
sushilkm
- Mark as New
- Bookmark
- Subscribe
- Mute
- Email to a Friend
Does VMware HAL lists the Disks and controller ?
golddiggie
- Mark as New
- Bookmark
- Subscribe
- Mute
- Email to a Friend
Is the SSD being connected internally on a controller that shows up correctly under ESXi? One of the issues with using commodity parts (especially motherboards) is you could very well run into blocking issues with the hardware. One BIOS version might be great, but the one before and one after it breaks it.
If the drive simply never shows up in either the install, or once the host boots into ESXi, then it's a compatibility issue. It MIGHT be fixed with the needed drivers (injected either into the install ISO, or post install).
Personally, since ESXi loads into memory, I've not seen any performance gain from running on fast storage. ESXi on USB thumb drives have had no performance difference than ESXi installed onto higher speed hard drives. I am talking about on either the exact same host, or an identical host.
В данной статье хочу рассказать о том, как немного повысить производительность хоста 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 (Raw Device Mapping) позволяет виртуальной машине обращаться напрямую к физическому накопителю. Связь обеспечивается через специальные файлы «mapping file» на отдельном томе VMFS. RDM использует два режима совместимости:
— Виртуальный режим — работает так же, как и в случае с файлом виртуального диска, позволяет использовать преимущества виртуального диска в VMFS (механизм блокировки файлов, мгновенные снэпшоты);
— Физический режим — предоставляет прямой доступ к устройству для приложений, которые требуют более низкого уровня управления.
В виртуальном режиме на физическое устройство отправляются операции чтения\записи. RDM устройство представлено в гостевой ОС как файл виртуального диска, аппаратные характеристики скрыты.
В физическом режиме на устройство передаются практически все команды SCSI, в гостевой ОС устройство представлено как реальное.
Подключив дисковые накопители к ВМ средствами RDM, можно избавиться от прослойки VMFS, а в физическом режиме совместимости их состояние можно будет мониторить в ВМ (с помощью технологии S.M.A.R.T.). К тому же, если что-то случится с хостом, то получить доступ к ВМ можно, примонтировав HDD к рабочей системе.
Помечаем хранилище как SSD vMware ESXi 6.5
Для версии гипервизора ESXi 6.5 проделывается точно такая же процедура. Разница лишь в том, что Client теперь только HTML. Без комментариев, просто скриншоты, потому что все слова написаны выше
На предыдущем скриншоте, ID диска это линк на который нажать, чтобы удобнее было копировать потом в окошко PuTTY.
Если вдруг забыли, запускаем SSH на хосте
Дальше через консоль. Вводим команды одна за другой, как описано выше.
Все сделали. Убеждаемся, что диск стал SSD командой:
esxcli storage core device list --device=mpx.vmhba0:C0:T2:L0
В моем примере это так (is ssd — true).
Для «очистки совести» посмотри и через клиента.
Ура! Заработало! (с) кот Матроскин
И еще момент. Этот же SSD будет использоваться в случае, если вдруг, виртуалкам не хватило оперативки в хосте.
Как пишет vMware «SSD, конечно же, медленнее чем RAM, но, как временный выход из положения, это поможет»
Если хотите самостоятельно изучить данный вопрос, то вот ссылка на документацию VMware по этому вопросу.
Tag Devices as SSD
If the SSD device that you want to tag is shared among multiple hosts, make sure that you tag the device from all the hosts that share the device.
Если ваше SSD устройство раздается на несколько хостов, убедитесь, что на всех хостах оно помечено, также, на SSD.
13.04.2022
itpro
VMWare, Виртуализация
комментария 2
Рассмотрим гипотетическую проблему потери или повреждения VMFS хранилища, подключенное к ESXi хосту/vSphere. Например, из-за человеческой ошибки, когда администратор VMware случайно удалил VMFS хранилище, или когда диск/LUN с VMFS был отключен/потерян из-за ошибок на устройстве хранения/резервного копирования. В этой статье мы покажем, как вручную восстановить таблицу разделов на диске, где находилось VMFS хранилище.
Допустим администратор VMware, случайно выбрал Delete вместо Unmount и удалил VMFS хранилище.
В первую очередь, не паникуйте. Не надо пересоздавать VMFS датастору из интерфейса vSphere, и не делайте других действий, которые перезапишут данные старого vmfs разделе на диске (LUN).
Откройте интерфейс клиента vCenter, перейдите в раздел Storage -> Devices и найдите в списке диск (LUN) с ранее подключенным vmfs datastore. Нужно получить полный путь к диску (с идентификатором naa). На моем скриншоте это:
Включите SSH доступ на хосте ESXi, с которого доступен удаленный LUN и подключитесь к нему с помощью ssh клиента (я использую встроенный ssh клиент Windows)
Проверьте осталась ли таблица разделов на этом устройстве:
partedUtil getptbl /vmfs/devices/disks/naa.60003ff44dc75adc87daa4e08f467565 Команда вернула, что на указанном диске/LUN есть таблица разделов GPT
Теперь нужно получить начальный и конечный блок раздела удаленного VMFS на диске.
Чтобы вывести суммарную информацию о всех разделах, доступных с ESXi хоста, и найти начальный блок удаленного VMFS раздела, выполните такой скрипт:
В данном примере вывела информацию о нашем удаленном разделе (testVMFS) и мы получили номер начального блока 2048 этого раздела.
Теперь нужно получить конечный блок VMFS раздела на диске:
partedUtil getUsableSectors /vmfs/devices/disks/naa.60003ff44dc75adc87daa4e08f467565
В нашем примере это 20971486.
Если эта команда вернет ошибку “Unknown partition table on disk”, нужно руками прописать метку GPT раздела:
partedUtil mklabel /vmfs/devices/disks/naa.60003ff44dc75adc87daa4e08f467565 gpt
Теперь нужно узнать GUID таблицы разделов для VMFS. Это всегда AA31E02A400F11DB9590000C2911D1B8.
Вы можете вывести все возможные GUID таблиц разделов с помощью команды:
Итак, мы получили следующие данные:
- LUN ID — naa.60003ff44dc75adc87daa4e08f467565
- Start Block – 2048
- End Block – 2097148
- GPT GUID – AA31E02A400F11DB9590000C2911D1B8
Теперь создайте таблицу разделов на вашем диске используя полученные вами данные:
partedUtil setptbl /vmfs/devices/disks/naa.60003ff44dc75adc87daa4e08f467565 gpt "1 2048 20971486 AA31E02A400F11DB9590000C2911D1B8 0"
Еще раз проверим разделы на диске, и убедимся, что теперь на нем виден VMFS раздел:
partedUtil getptbl /vmfs/devices/disks/naa.60003ff44dc75adc87daa4e08f467565
Теперь нужно смонтировать данное VMFS хранилище:
vmkfstools -V
esxcli storage core adapter rescan --all
Откройте клиент vSphere, убедитесь что удаленное VMFS хранилище появилось. Смонтируйте его.
На VMFS хранилище сохранились все файлы, в том числе iso образы и файлы виртуальных машин.
05.02.2020
itpro
VMWare
комментария 2
Одним из нововведений в vSphere 5.x является функция Host Cache, которая позволяет администратору разместить файл подкачки (vswp) виртуальной машины на локальном диске с целью увеличения скорости работы за счет размещения свопа на локальных высокопроизводительных дисках (оптимально на SSD дисках, так как скорость доступа на них выше). Реализуется технология за счет создания на SSD диске отдельного раздела VMFS, который затем определяется службой SATP (Storage Adapter Type Plugin) и которая позволяет добавлять и управлять кэшированием на локальном хранилище VMFS.
С текущим падением цен на SSD это может дать реальный прирост производительности VMware ESXi 5.x-сервера, которому, например, не хватает памяти.
Собственно на новых серверах (которые заказывались с SSD дисками) мы и решили протестировать технологию SSD Host Cache. Но столкнулись с трудностью, по умолчанию локальное SSD хранилище не отображается как доступное для работы функции кэширования (пустая вкладка Host Cache Configuration).
Для борьбы с этой проблемой пришлось немного повозиться. Как оказалось, стандартные правила SATP не позволяют обнаружить установленный SSD диск, однако можно создать специальное правило для конкретного устройства SSD .
- Отключаем все диски, презентованные серверу по сети SAN (чтобы не возникло путаницы)
- Открываем локальную консоль сервера ESXi5 (зайти можно по ssh или через vMA) и выполняем команду:
- Затем выполняем команду
Примечание: Если нет ни одного SSD Datastores, проверьте, что ваш Datastore правильно помечен как SSD с списке storages. А также убедитесь, что ssd отформатирован как VMFS5.
Что еще можно отметить: после включения SSD Host Cache на локальном хранилище будет создана папка с произвольным (сгенерированным автоматически) именем, внутри которой будет находится папка hostCahe с кучей файлов по 1 MB, представляющие собой файлы свопа для страниц памяти виртуальных машин, запущенных на данном ESX сервере. При миграции (VMotion) этих виртуалок, данные файлы также должны быть перенесены на другой хост (или на общее хранилище, если на хосте Host Cache не включен), за счет чего время миграции несколько увеличивается.
В случае же отказа хост-сервера, надобность в этих файлах исчезает, т.к. виртуалки перезапускаются на другом хосте, и данные из старого файла подкачки им больше не нужны.
Для чего это может понадобиться? Ну, например, для того, чтобы единственной настройкой сказать гипервизору, чтобы хранил все swap’ы на этом Storage.
Со значения по умолчанию:
На вот такую конфигурацию: жмем Edit.
Теперь файлы подкачки всех ВМ хоста будут хранится на выделенном SSD хранилище.
Интересующимся применением технологии SSD в других современных продуктах, рекомендуем познакомиться со статьей «Оптимизация SSD для Windows 8»
Предыдущая статья Следующая статья
Как расширить диск виртуальной машины в VMWare
Установка VMware Tools на Debian, Ubuntu и CentOS
VMWare ESXi: Перезапуск зависшей виртуальной машины
Сжимаем тонкий (thin) диск в ESXi 5
Спасибо, интересно, SSD винты вообще радуют своей скоростью и бесшумностью. Думаю это даст неплохой прирост к производительности виртаулок.
Обновил статью по комментариям от Алекса Корнева. Мануал актуален и для vCenter / ESXi 6.x
Рубрики сайта
Последние статьи
lvmcache
lvmcache обеспечивает прозрачное кэширование данных медленных устройств HDD на быстрых устройствах SSD. LVM cache размещает наиболее часто используемые блоки на быстром устройстве. Включение и выключение кэширования можно производить, не прерывая работы.
При попытке чтения данных выясняется, имеются ли эти данные в кэше. Если требуемых данных там нет, то чтение происходит с HDD, и попутно данные записываются в кэш (cache miss). Дальнейшее чтение данных будет происходить из кэша (cache hit).
Запись
— Режим write-through — когда происходит операция записи, данные записываются и в кэш, и на HDD диск, более безопасный вариант, вероятность потери данных при аварии мала;
— Режим write-back — когда происходит операция записи, данные записываются сначала в кэш, после чего сбрасываются на диск, имеется вероятность потери данных при аварии. (Более быстрый вариант, т.к. сигнал о завершении операции записи передается управляющей ОС после получения данных кэшем).
Так выглядит сброс данных из кэша (write-back) на диски:
Обслуживание (Замена диска)
Если с диском вот-вот случится беда (по результатам S.M.A.R.T.), для того чтобы заменить его на рабочий необходимо выполнить следующую процедуру (на ВМ svm):
В настройках ВМ нужно «оторвать» погибающий vHDD, затем заменить HDD на новый.
После чего подготовить RDM накопитель и добавить к ВМ svm:
Краш-тест
Отключение питания
После включения и загрузки хоста ВМ 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 необходимо повторить процедуру настройки системы.
Резюме
В итоге, я использую lvmcache в режиме write-through и раздел для кэша размером 60Gb. Немного пожертвовав ресурсами CPU и RAM хоста — вместо 210Gb очень быстрого и 1.3Tb медленного дискового пространства я получил 680Gb быстрого и 158Gb очень быстрого, при этом появилась отказоустойчивость (но при неожиданном выходе из строя диска придется поучаствовать в процессе доступа к данным).
20.04.2018
Alex Kornev
VMWare
комментария 2
В VMware vSphere 5.x (ESXi 5.x), и более поздних версиях, появилась новая возможность, называемая Host Cache Configuration. Эта функция позволяет администратору VMware vSphere настраивать VMware vSphere 5.x (ESXi 5.x) хост-сервер для использования кэша на твердотельных дисках (SSD) для swap файла виртуальной машины для повышения производительности, так как SSD работает гораздо быстрее традиционных жестких дисков. Среди администраторов VMware это также называют «Swap to Host Cache» или «Swap to SSD». Как только данная конфигурация кэша хоста будет включена, виртуальные машины будут свопиться на SSD, но этот swapfile не является настоящим файлом подкачки, а действительный файл подкачки виртуальной машины (.vswp) не хранится на SSD.
Однако, иногда, SSD диски определяются неправильно и не помечаются как SSD. В этой статье я покажу как правильно сконфигурировать и пометить устройство как SSD.
Если хотите поэкспериментировать, но у вас нет под руками SSD, то, в принципе, любой диск можно сконфигурировать как SSD, хотя VMware утверждает, что данная фишка не поддерживается (This is not supported by VMware, tagging a non-SSD as a SSD).
Однако, я проделал этот «фокус» на ESXI 5.5 запущенном под управлением VMware Workstation 14. И все получилось
Производительность
Производительность измерялась синтетическим тестом (для сравнения, я снял показания с кластера на работе (в ночное время)).
Используемое ПО на тестовой ВМ:
— ОС CentOS 7.3.1611 (8 vCPU, 12Gb vRAM, 100Gb vHDD)
— fio v2.2.8
Полученные результаты представлены в таблицах (* во время тестов отмечал среднюю загрузку ЦП на ВМ svm):
Тип диска | FIO depth 1 (iops) | FIO depth 24 (iops) | ||
---|---|---|---|---|
randread | randwrite | randread | randwrite | |
HDD | 77 | 99 | 169 | 100 |
SSD | 5639 | 17039 | 40868 | 53670 |
SSD Cache | FIO depth 1 (iops) | FIO depth 24 (iops) | CPU/Ready* % | ||
---|---|---|---|---|---|
randread | randwrite | randread | randwrite | ||
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 | Первый запуск | Второй запуск | Третий запуск | |||
---|---|---|---|---|---|---|---|
Время загрузки первой ВМ | Время загрузки всех ВМ | Время загрузки первой ВМ | Время загрузки всех ВМ | Время загрузки первой ВМ | Время загрузки всех ВМ | ||
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 секунд
lvmcache
lvmcache обеспечивает прозрачное кэширование данных медленных устройств HDD на быстрых устройствах SSD. LVM cache размещает наиболее часто используемые блоки на быстром устройстве. Включение и выключение кэширования можно производить, не прерывая работы.
При попытке чтения данных выясняется, имеются ли эти данные в кэше. Если требуемых данных там нет, то чтение происходит с HDD, и попутно данные записываются в кэш (cache miss). Дальнейшее чтение данных будет происходить из кэша (cache hit).
Запись
— Режим write-through — когда происходит операция записи, данные записываются и в кэш, и на HDD диск, более безопасный вариант, вероятность потери данных при аварии мала;
— Режим write-back — когда происходит операция записи, данные записываются сначала в кэш, после чего сбрасываются на диск, имеется вероятность потери данных при аварии. (Более быстрый вариант, т.к. сигнал о завершении операции записи передается управляющей ОС после получения данных кэшем).
Так выглядит сброс данных из кэша (write-back) на диски:
Аварийный доступ к данным
Один из дисков подключается к рабочей станции, далее необходимо «собрать» RAID, отключить кэш и получить доступ к данным, примонтировав LVM том:
Также я пробовал загрузить систему непосредственно с диска, настроил сеть и на другом хосте подключил NFS датастор — ВМ доступны.
Помечаем хранилище как SSD в vMware ESXi 5.x/6.0
Все команды в данном руководстве это консольные команды ESXi. Подробный список команд можно посмотреть в статье «Список команд ESXi».
Как подключиться к хосту? Любым удобным для вас методом. Обычно это делается через PuTTY. Важно попасть в CLI.
Но сначала запускаем клиента.
- Подключаемся клиентом к VMware ESXi
2. Проверяем помечен ли Storage как SSD
Выберите: Host -> Configuration -> Storage
На картинке видно, что устройство mpx.vmhba1:C0:T0:L0 это локальный диск, отформатированный в VMFS5. Но … помечен как non-SSD. Запишите имя устройства, в примере это — mpx.vmhba1:C0:T0:L0, оно пригодиться при выполнении следующих шагов.
3. Подключаемся к консоли ESXi через PuTTY
Логинимся от имени root’a
4. Создаем новое SATP правило
В консоли выполните следующую команду. Здесь понадобится, записанное ранее, имя устройства.
esxcli storage nmp satp rule add --satp VMW_SATP_LOCAL --device mpx.vmhba1:C0:T0:L0 --option=enable_ssd
Если все правильно, консоль просто выведет следующую, пустую строку. Чтобы проверить, что правило было создано правильно, можно ввести команду:
esxcli storage nmp satp rule list | grep enable_ssd
В результате вы увидите, примерно то, что показано ниже.
5. Назначаем (claim) наше устройство
esxcli storage core claiming reclaim -d mpx.vmhba1:C0:T0:L0
и опять используем имя, которое записали на шаге 2
Я увидел примерно следующее, когда попробовал сделать unclaim. Но это произойдет автоматически при перезагрузке хоста.
Можете попробовать выполнить unclaim самостоятельно, указав имя устройства.
esxcli storage core claiming unclaim --type device --device mpx.vmhba1:C0:T0:L0
6. Перезапускаем правила назначения (claim rules)
Я обычно пользую вот такой парочкой команд для этого.
esxcli storage core claimrule load
esxcli storage core claimrule run
7. Убеждаемся, что наше устройство теперь помечено как SSD
Наберите следующую команду в консоли
esxcli storage core device list --device=mpx.vmhba1:C0:T0:L0
Увидите нечто подобное в качестве результата отработки команды
Нас интересует строка «Is SSD: true». Если это так, то все сделано правильно.
В качестве дополнительной проверки, можно посмотреть, как наше устройство отражается в клиенте.
После включения Host Cache на “SSD” диске для хранения кэша создается отдельная папка HostCache, в которой лежит множество vswp файлов по 1 MB. Это файлы свопа страницы памяти ВМ. По этим файлам «размазывается» настоящий .vswp файл.
Настройка системы
На хосте создается 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 и выполнить следующие команды:
Подготовка ВМ
Теперь эти диски можно подключить (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 сервера довольно проста:
Подготавливаем тома кэша и метаданных для включения кэширования тома cl_svm/data:
Уведомления о изменении состояния массива:
Чтобы изменения вступили в силу, нужно перезапустить службу mdmonitor:
Почта с ВМ отправляется средствами ssmtp. Так как я использую RDM в режиме виртуальной совместимости, то проверять состояние дисков будет сам хост.
Подготовка хоста
Добавляем NFS датастор в ESXi:
Настройка автозапуска ВМ:
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 .
Более гибко автостарт ВМ можно настроить с помощью командной строки:
Небольшая оптимизация
Включить 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:
Читайте также: