> Я не спец ни по солярке, ни под железу
> санок: сужу по словам коллеги, сертифицированного в своё время по санкам
> по полной. Который сейчас так же вплотную занимается Линухом.

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

>    Это и железо и софт: я это указывал. Хотя
> в ВМ сейчас на горячую тоже можно и добавить и убавить
> и ядра и память, но не редко (сам сталкивался) можно "весёлые
> спецэффекты" словить.

Знаете, я не знаю сохранились ли рассылки по солярису тех времён в открытом доступе - но вот там было что-то подозрительно похожее на то, что Вы сейчас говорите.

>    Вообще-то этими технологиями решаются несколько разные задачи, местами пересекающиеся.

Вы про то, что быстро поднятый сервис всё-таки считается упавшим?
Ну, для таких случаев есть pacemaker и иже с ними.
Да, на это уйдёт больше ресурсов, да это потребует больше внимания при настройке - но это будет на пару порядков (то есть раз в 100) дешевле чем такое же решение в 2000-ых на сертифицированном комплексе (Solaris) + (Hard from Sun)

>    И не всё и не всегда решается виртуализацией. Если
> у вас серьёзный кластер СУБД (на пару сотен ТБ и высоконагруженный),
> например, то виртуализация тут противопоказана.

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

Это Вы просто, наверное, не интересуетесь, что там сейчас в мире k8s происходит со всякими cloud-native db.
Пройдет ещё совсем немного времени, и это, скорее всего, будет доступно даже тем, кто и подумать об этом не мог.