Memory ballooning?

[dereitz]

Does anyone know if the HA OS VM build supports memory ballooning as described at the below link?
https://pmhahn.github.io/virtio-balloon/

I tried to set a minimum of 1GB and a max of 2GB, but the memory footprint always appears to be 2GB as reported in Proxmox. The actual memory utilized appears to only be about 835MB, so I'd have thought it would shrink to only 1GB.

It would be fantastic if this worked, so if anyone has attempted this and can share your experience, I would greatly appreciate it!

Thanks,
David

[agners]

In my testing using Virtual Manager the system starts up with the minimum configured of 1GB, so that looks good here.

Technically, HAOS commes with VirtIO ballooning support, and the kernel module is loaded by default. So it really should work.

Does ballooning in your Proxmox setup work with other Linux distribution?

[dereitz]

To be honest, I haven't tried other Linux distributions, but can certainly try it for validation of how "it should work".

[agners]

It seems that Virtual Manager doesn't support dynamic ballooning, but changing the current assignment at any point in time seems to work and apply to the system:

[dereitz]

Interesting! I'll have to do some further testing in Proxmox.

[langemar]

Hi everyone,

I've just installed my new Raspberry Pi 5, and as it's slightly overpowered to just run HomeAssistent I run an AlmaLinux 9 as a KVM base below.

At first I gave HAOS 6 of 8GB of memory as I thought ballooning will prevent my memory to flow over (and Swap might clear the rest...). Or at least I can write some automations for that...
However, as already discussed here setting the current allocation does not work for me:

[root@lab-virt]/etc/libvirt# virsh setmem --domain HomeAssistent --size 2G --current 
error: Requested operation is not valid: Unable to change memory of active domain without the balloon device and guest OS balloon driver

I've tested with another VM running AlmaLinux 9 and setting current allocation limit works just fine.

[root@lab-virt]/etc/libvirt# virsh domstats almalinux9-2025-4-13 --balloon
Domain: 'almalinux9-2025-4-13'
  balloon.current=3145728
  balloon.maximum=3145728
  balloon.swap_in=0
  balloon.swap_out=0
  balloon.major_fault=242
  balloon.minor_fault=113352
  balloon.unused=2493532
  balloon.available=2704368
  balloon.usable=2500524
  balloon.last-update=1744550517
  balloon.disk_caches=65516
  balloon.hugetlb_pgalloc=0
  balloon.hugetlb_pgfail=0
  balloon.rss=688756

[root@lab-virt]/etc/libvirt# virsh setmem --domain almalinux9-2025-4-13 --size 2G --current 

[root@lab-virt]/etc/libvirt# virsh domstats almalinux9-2025-4-13 --balloon                 
Domain: 'almalinux9-2025-4-13'
  balloon.current=2097152
  balloon.maximum=3145728
  balloon.swap_in=0
  balloon.swap_out=0
  balloon.major_fault=242
  balloon.minor_fault=113352
  balloon.unused=2493532
  balloon.available=2704368
  balloon.usable=2500524
  balloon.last-update=1744550517
  balloon.disk_caches=65516
  balloon.hugetlb_pgalloc=0
  balloon.hugetlb_pgfail=0
  balloon.rss=817396

Given that, it seems the virtio ballooning driver is not included - or loaded - within the HAOS image. I'm using the Image haos_generic-aarch64-15.1.qcow2 .

Am I missing a peace here, maybe using the wrong image?

Best regards,
Markus

[Impact123]

What does ha os info and lsmod | grep balloon inside the VM say? You probably want the OVA for virtual machines. Stuff like this or guest agent does not usually come with the generic images meant for bare-metal installs.

[Impact123]

Just for comparison this is the output on a x86 based VM.

# ha os info
board: ova
...
data_disk: QEMU-QEMU-HARDDISK-drive-scsi0

# lsmod | grep balloon
virtio_balloon         32768  0

QCOW2 is indeed strongly correlated with virtualization. Please use your VM's OS level CLI (not an addon) and try this

# modprobe virtio_balloon; echo $?
0

I'm not that familiar with SBCs or ARM or virsh so I can't test and likely can't help you further with their specifics, I'm just curious.

[langemar]

Hi,

You already helped me a lot, and every piece of the puzzle helps to figure out what went wrong and may lead me to a solution :)

this already looks better, but still not quite right:

[root@lab-virt]~# virsh console HomeAssistent
Connected to domain 'HomeAssistent'
                                   Escape character is ^] (Ctrl + ])

homeassistant login: root
Welcome to Home Assistant OS.

Use `ha` to access the Home Assistant CLI.
# modprobe virtio_balloon; echo $?
0
# lsmod | grep balloon
virtio_balloon         24576  0
# exit

Welcome to Home Assistant
homeassistant login:  
[root@lab-virt]~# virsh setmem --domain HomeAssistent --size 2G --current
error: Requested operation is not valid: Unable to change memory of active domain without the balloon device and guest OS balloon driver

virsh console attaches to the serial console of VM.

And as manual loading of the module works, is there a recommended way to have it loaded on boot? Or could I simply add it to /etc/modules?

Best regards,
Markus

[Impact123]

You can utilize this but just loading the module does not seem to be the solution:

[langemar]

As the driver is present it should be loaded automatically anyway. However, as I dig deeper the memballoon device was missing in the configuration of the vm entirely. I have obviously used a wrong template to create the VM, I'll try to recreate the VM with another template and report back.

Thanks for your help :)
Markus

[langemar]

So after playing around a bit I found my mistake. I had used the "Generic" profile instead of an "Generic Linux" profile (Cockpit has two of them, now I used the 2022 variant of it) to import the qcow2 Image. This profile (Generic) did not include a balloon device and no guest agent.
After recreating the VM using the "Generic Linux" profile everything works as expected.

Thanks again for your Help, if you like to know more ask :)

Best regards,
Markus