Как правильнее использовать ресурсы ПК для терминального сервера и 1C+SQL?
Как правильнее использовать ресурсы ПК для терминального сервера и 1C+SQL?Ну для начала - зачем виртуализация?
Виртуализация штука несомненно удобная, поэтому ее есть смысл использовать для удобства работы с инфраструктурой.
Но если на первом месте быстройдействие - есть смысл задуматься, нужна ли она вам.

Особенно проблем доставляют  диски при виртуализации.  Сразу забываем про такие удобные вещи как TRIM, и зачастую имеем кучу проблем с быстродействием.

приходится все серверы терминалов целиком держать на nvme-накопителе, т.к. 1С чувствительна к скорости временных файлов пользовательского профиля.А кто мешает вынести на быстрый диск только юзерпрофиль? Причем можно использовать физический диск примонтировав его к виртуалке.

Только storage spaces? Работает ли оно в моих условиях? Работает. Ярусное хранение можно организовать. Но конкретно в вашем случае - когда можно отделить требовательные к скорости файлы явно,  лучше так и сделать.

Ну и шлюз - он то тут каким боком? Обычно под это выгоднее выделить специальную железку.
Да и смесь файловых и SQL баз - почему файловые не закинуть на SQL  сервер?
upd. не сообразил что сервер у тебя на windows, а мой ответ подходит только для linux хоста (можно конечно пробросить контроллеры дисков внутрь одной из виртуалок, и там уже на Linux все сделать но мне кажется это извращением)

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

Делать это лучше, мне кажется, там где к дискам прямой аппаратный доступ (на гипервизоре или пробросив контроллеры в виртуалку которая файлсервер). Так же сначала на основе физических железок поднимаешь raid-ы, а уже на получившихся - поднимаешь bcache, поверх получившихся дисков поднимаешь хранилища, а уже там либо файлы виртуалок и/или сами раздавать файлы по сети.

Настоятельно рекомендую не делать один большой блочный bcache диск с одним большим кешем на все доступное пространство на ssd... лучше поделить на тома, соответственно с разным характером нагрузки. Причем размеры кешей для каждого характера нагрузки могут быть разными. А еще можно части ssd и hdd диска выделить для разделов вне кеширования.

Пример - если сделать 2 блочных устройства отдельно для файлов ОС (к примеру выделил всего 8гб кеша) и отдельно для файлов нагруженной базы данных (у меня так на очень слабой железке 2013 года, хорошо такие нюансы выявлять) то высокая нагрузка на базу данных не затронет кеш файловой системы ОС, характер нагрузки ОС отличается от базы данных, файлы ОС читаются и меняются редко, и если бы лежали на одном блочном устройстве, из ssd кеша их бы выкинуло быстро, а так - отзывчивость работы с ОС осталась на высоте при видимой высокой на hdd диск из-за базы данных.

p.s. если у тебя ssd диск в рейде, то не бойся включать bcache стратегию writeback, поднимает скорость очень заметно