И slave тоже научились переводить, как ведомое устройство

ну теперь-то заживём

надо полагать следующий вопрос будет где взять  статически собранный openvpn клиент для исиксая

Как же хорошо, что всего этого добра нет в esxi. А то мне это начинает напоминать недавний кейс с отключением антивируса (!) на win хостах s2d (!), где сам антивирус жрал несколько GB RAM и предположительно останавливал ввод/вывод.

хм, а есть где почитать детали?

Джентльмены, кто работал с Storage Spaces от Microsoft? Проблема такова - для бэкапов виртуалок, баз скуля и файлов к скулю, собран на базе jbod из 48 sas дисков two way mirror pool. Диски по 8 ТБ. На пуле virtual disk отформачен в ntfs с размером кластера 64K. Когда пул заполнился на треть (объем порядка 160ТБ, заполнен чуть больше 50ТБ), он перестал писать или считывать данные. При попытке записать или считать прогресс 0% и висит. Что локально с другого диска или пула, что по сети. При этом на этом же серваке есть другой пул, меньшего размера (из дисков того же jbod-а), всего из 12 дисков, он работает отлично. Оба пула собраны абсолютно одинаково. При попытке перезагрузить сервер, сервер висит на экране завершения работы, приходится резетить. После ночных мучений, перезагрузок по питанию, попыток отключить антвивирь в винде (подозрение пало на него, т.к. он сжирал вагон оперативы в несколько гигабайт) и такой-то матери каким-то образом получилось начать считывать данные с пула. Сейчас образы перетаскиваем по nfs на временный пул zfs на другом сервере. При попытке посмотреть свойства диска, строка Free space висит в статусе working... И все. Что делать? Естественно когда данные сольются и пул будет пересоздан, думаю все заработает, но сколько времени он будет так работать? Пока опять на него несколько ТБ не зальем? В гугле забанили, т.к. ничего не смог толково найти. Сервер Win 2019 LTSC полностью обновлен, левого софта нет. Железо - 2х xeon 8c/16t/ 128GB RAM, os на ссд, + jbod и пулы.

антивирус тут только предположение

причем неподтвержденное

но любопытно, кину своим

Дело не в том, что он привёл к проблемам. А в том, что он просто ЕСТЬ и МОЖЕТ привести к проблемам. И соответственно в процессе траблшутинга с этим надо работать. Как ещё со всякой другой фигней на хосте, которая есть из коробки или которую мог поставить пользователь по дурости.

так же как и есть default exclusions, бест практис и прямой гайд с параметрами по настройке компонента системы

с тем же успехом я могу кивнуть на CIM провайдер в исиксае который тоже за собой может хост утащить

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

*кстати не удивлюсь если в кейсе выше нарушены или не выполнены рекомендации (надо доку смотреть)

В данном кейсе дело было не в антивирусе

Запихивание статического пакета на esxi имеет все таки несколько больший порог входа, чем нажать next-next-finish по .exe файлу. Что подразумевает хоть некоторую компетенцию, а значит увеличивает шанс что организатор сия действия хоть чуть чуть пониманиет, что он делает

У вари с этим все отлично - говнософ та вагон, на самом хосте

безусловно

но я скорее про сам факт наличия возможности которая присутствует в обоих случаях

А в чем же?