>  А SWAP ?

А вы почитайте
https://access.redhat.com/solutions/103833

SWAP в Linux - это чудовище. Его реализация даже в современном ядре такова, что затюнить его под свою задачу - вопрос в большей степени астрологический, нежели технический. И виноват во всем именно страничный кэш.
Если вы укажете слишком высокую цифру у вас в swap будут попадать активные буферы процессов, а если слишком маленькие, то почти ничего.

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

Отдельно нужно сказать про страничный кэш, который оно будет активно отбирать. Вы же знаете да, что ядро Linux имеет поддержку единственной верной файловой системы ext4, а остальные там сильно сбоку. Например, если RHEL предоставляет по умолчанию XFS, поэтому делает форк ядра в том числе, чтобы страничный кэш учитывал специфику XFS. А если у вас ZFS, то у вас вообще будет существовать как бы 2 разных страничных кэша. А теперь попробуйте угадать резервирование (в гуманитарном смысле) RAM под этот зоопарк на сервере виртуализации. Если у вас 1ТБ RAM или что-то близкое к этому, то заложить минимум 80 ГБ было бы не плохо, но нужно понимать сколько локального диска. С учетом того как там всё форкается налево и направо было бы неплохо угадать и этот потенциальный перерасход.

> Так как отключить?

Проставить значение vm.oom-kill = 0 в sysctl или поиграться с vm.overcommit_memory
Но если вы так сделаете, то у в условии нехватки памяти будет падать не одна виртуалка, а целый хост (привет VMware, она так любит делать). В реальности вам нужно производить скоринг процессов, чтобы контролировать, что вам будут ронять с большей вероятностью, а что с меньшей. Но сделать так чтобы не падало ничего не выйдет.

Поймите, Linux постоянно производит оверкоммитмент ресурсов RAM, хотите вы этого или нет. Максимум что вы можете сделать:
1. Создать шаблоны ресурсов виртуальных машин
2. Размещать виртуальные машины одного типа на одной группе серверов, второго типа на второй, итд. Ради предсказуемости нагрузки и объемов.
3. Рассчитывать ресурсы железа так, чтобы не срабатывал OOM Killer.
4. Выделить приоритеты в /proc для важных процессов

Если вы хотите автоматизацию таких вещей избавьтесь от Linux, ну или хотя бы избавьтесь от KVM, перейдите на Xen (Citrix Hypervisor), где ваши виртуальные машины не считаются за обычные процессы ОС, хотя и там вам от него не избавиться. И опять, даже в случае с Xen всё в конечном итоге зависит от сборки дистрибутива/юзерспейса и как там присваиваются приоритеты и распределяются ресурсы.

Если же вы хотите, чтобы у вас виртуалки свапились, а не падали, когда вы перерасходуете RAM, то вам нужен Hyper-V. Но не могу понять зачем это может потребоваться. Засвапилась у вас виртуалка или упала - всё одно. Оно больше не работает нормально.