Спасибо за ответ. Если я правильно понимаю, процесс освобождения памяти не происходит, когда RAM установлена в 4096/4096. Получается, 4096/4096 — это как отключить ballooning?

Привет! У меня 3 ВМ (Windows 11 со всеми драйверами https://pve.proxmox.com/wiki/Windows_10_guest_best_practices). На моём последнем узле Proxmox 8.2.2 всего 32 ГБ ОЗУ.

- ВМ1: минимум 4 ГБ ОЗУ, максимум 14 ГБ ОЗУ, Ballooning: Включён
- ВМ2: минимум 4 ГБ ОЗУ, максимум 14 ГБ ОЗУ, Ballooning: Включён
- ВМ3: минимум 4 ГБ ОЗУ, максимум 14 ГБ ОЗУ, Ballooning: Включён

---------
Минимальный общий объём ОЗУ ВМ: 12 ГБ из 32 ГБ ОЗУ на узле
Максимальный общий объём ОЗУ ВМ: 42 ГБ из 32 ГБ ОЗУ на узле

Когда я включаю ВМ, одна из них всегда отключается. Я понимаю, что это из-за нехватки ОЗУ, но ведь есть МИНИМАЛЬНЫЙ объём ОЗУ и Ballooning. Так почему же этот механизм не работает? И как его заставить работать?

Большое спасибо!

Привет! В настройках ВМ -> Оборудование нет "PCI Device", и на хосте у меня их тоже нет.

Не может ужать ВМ в реальном времени. Если бы сразу же удаляла оперативную память из ВМ, гостевая ОС зависла бы и не успела бы выгрузить данные. Поэтому делает это постепенно. Но 1,5 часа — это слишком долго...

Тонкая виртуализация CPU имеет смысл, когда хочется перераспределить ресурсы. Чем больше ресурсов у тебя есть, тем больше она может быть полезна. Например, если ты пытаешься сэкономить оперативную память на 8ГБ системе, скорее всего, это не стоит усилий и проще купить ещё одну планку памяти. Но если ты провайдер услуг интернета и у тебя сотни серверов с более чем 1ТБ памяти каждый, ты можешь сэкономить миллионы, немного перераспределив ресурсы вместо покупки оборудования. Ну как обычно, IT спрашивает у разработчиков, сколько ресурсов понадобится новому приложению (они немного переоценивают), они спрашивают у менеджеров продукта, сколько миллионов пользователей ожидается (они всегда завышают прогноз), поэтому в больших окружениях обычно можно просто немного перераспределить ресурсы и все будет хорошо. Для небольших систем, на мой взгляд, контейнеры лучше, если ты хочешь максимально использовать последнюю свободную память вместо виртуальной машины. Также хост не может просто "взять" память у ВМ, он спрашивает у ВМ, может ли он вернуть немного памяти, и ВМ решает, отдавать ли память или нет. Это обычно не одно взаимодействие, скорее всего, они делают много итераций, и каждый раз возвращается всего несколько КБ/МБ, поэтому это медленно. (Если у хоста заканчивается свободная память, ему приходится использовать подкачку или убивать процессы, обычно самые большие -> твои KVM/QEMU ВМ). И наоборот, если ВМ хочет вернуть свою динамическую память, она должна запросить её у хоста, и хосту приходится решать, возвращать ли память или нет. (Если она не получит память достаточно быстро, она должна использовать подкачку или убивать процессы). По поводу настройки минимального размера, есть программы, у которых свой планировщик памяти и которым требуется весь диапазон при запуске. Например, Java: если у тебя Java-приложение настроено на использование 8ГБ, а у ВМ в данный момент свободно 6ГБ и возможно ещё 4ГБ благодаря тонкой виртуализации, Java-приложение вылетит с ошибкой нехватки памяти при запуске, тонкая виртуализация в этом случае недостаточно быстра... Это постоянно случается, в этих случаях правильно настроенный минимальный размер имеет смысл. Также, правильный размер виртуальных машин лучше, чем перераспределение, но реально сложно угадать. Обычно мы справляемся с 120% перераспределения памяти и 350% перераспределения CPU, но каждое окружение разное. И как-то меня раздражает, что это называется "тонкой виртуализацией" с KVM. "Тонкая виртуализация" — это от ESX, где в ВМ есть процесс, который надувается (как воздушный шарик, отсюда и название), и хост отображает эти страницы. Кроме того, этот "шарик" подкреплён собственным файлом подкачки, поэтому ВМ на ESXi может сильно замедлиться в условиях нехватки памяти, но хост никогда не убьёт её. В KVM/QEMU размер твоей ВМ будет уменьшаться и увеличиваться... Так что динамическая/гибкая память было бы гораздо лучшим названием, и если у хоста недостаточно места для подкачки, это может спровоцировать убийство процесса в зависимости от того, как ты увлечёшься перераспределением.

Хм... ну, в последний раз, когда мы это тестировали, было года 3-4 назад на ovirt/rhev. Тогда создалось впечатление, что гостевая система может не отпускать память, если она в данный момент использует только активную память. Я, правда, с proxmox не тестировал. Базовый kvm/qemu, вероятно, одинаков. После короткого гугла, Red Hat кое-что делали с управлением памятью через mom и libvirt. Вот об этом написано: https://medium.com/coccoc-engineering-blog/the-way-of-kvm-memory-management-9670f0f852af, и в конце даже видно, что память расширяется/сокращается небольшими порциями. А вот старый тест с mom и ballooning: https://developer.ibm.com/tutorials/l-overcommit-kvm-resources/. Ещё у ovirt есть кластерный планировщик, который переносит ВМ на другой хост, если ресурсов не хватает. Ну, значит, я ошибся насчет ванильного kvm/qemu, но разве нет какой-нибудь команды или что-то подобное в /proc, где можно вручную управлять balloon и проверить это? Если ванильный kvm/libvirt действительно написан так, что он баллонирует без согласия ВМ, и ВМ падает из-за этого, это довольно глупо, и я бы посчитал это ошибкой. Я понимаю, что хост может исчерпать память/своп и, соответственно, kill ВМ. С другой стороны, можно возразить, что эта ВМ неправильно сконфигурирована, поскольку у нее недостаточно свопа для обработки такой ситуации.