Bug 292570 - [virtio] virtio-balloon does not balloon correctly
Summary: [virtio] virtio-balloon does not balloon correctly
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 14.3-RELEASE
Hardware: amd64 Any
: --- Affects Only Me
Assignee: freebsd-virtualization (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2026-01-18 16:58 UTC by lysfjord.daniel
Modified: 2026-03-04 21:38 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description lysfjord.daniel 2026-01-18 16:58:56 UTC
See also #198344 and #277473

I am running FreeBSD 14.3-RELEASE in a kvm on Linux 6.18 with libvirt 12.0.0

> virsh -V
Virsh command line tool of libvirt 12.0.0
See web site at https://libvirt.org/

Compiled with support for:
 Hypervisors: QEMU/KVM LXC OpenVZ Cloud-Hypervisor VMware VirtualBox ESX Test
 Networking: Remote Network Bridging Interface udev Nwfilter
 Storage: Dir Disk Filesystem SCSI Multipath iSCSI iSCSI-direct LVM Gluster ZFS
 Miscellaneous: Daemon Nodedev Secrets Debug Readline

VM is configured with a memory size of 25165824k, Q35 chipset, BIOS firmware, VirtIO disk of 20GB, a VirtIO nic of type bridge.

info from ps aux on a freshly started VM:
VSZ:27259904
RSS: 5005584

Seems to be consistent with what you see inside on the inside
# sysctl vm.kmem_size
vm.kmem_size: 25013338112

virtio_balloon seems to be loaded:
# kldstat -v | grep virtio_balloon
                301 virtio_pci/virtio_balloon
                300 virtio_mmio/virtio_balloon

Also seems to be working:
# sysctl -a | grep balloon
vtballoon0: <VirtIO Balloon Adapter> on virtio_pci2
vtballoon0: <VirtIO Balloon Adapter> on virtio_pci2
device  virtio_balloon
dev.vtballoon.0.current: 512
dev.vtballoon.0.desired: 1048576
dev.vtballoon.0.%iommu: 
dev.vtballoon.0.%parent: virtio_pci2
dev.vtballoon.0.%pnpinfo: vendor=0x00001af4 device=0x1045 subvendor=0x1af4 device_type=0x00000005
dev.vtballoon.0.%location: 
dev.vtballoon.0.%driver: vtballoon
dev.vtballoon.0.%desc: VirtIO Balloon Adapter
dev.vtballoon.%parent: 
dev.xen.balloon.high_mem: 0
dev.xen.balloon.low_mem: 0
dev.xen.balloon.hard_limit: 0
dev.xen.balloon.driver_pages: 0
dev.xen.balloon.target: 0
dev.xen.balloon.current: 0


However, if I want to adjust the amount of memory used by the VM:
VM: # sysctl dev.vtballoon.0 | grep "current\|desired"
dev.vtballoon.0.current: 512
dev.vtballoon.0.desired: 1048576
Host: ❯ virsh setmem "FreeBSD buildd" 20480m
VM: # sysctl dev.vtballoon.0 | grep "current\|desired"
dev.vtballoon.0.current: 768
dev.vtballoon.0.desired: 1048576

Rerunning the virsh command;
Host: ❯ virsh setmem "FreeBSD buildd" 20480m
VM: # sysctl dev.vtballoon.0 | grep "current\|desired"
dev.vtballoon.0.current: 1024
dev.vtballoon.0.desired: 1048576
Host: 
VSZ: 27259904
RSS: 5010588


No matter how long (exaggeration; I just waited a few minutes), on an idle system, that "current" number does not change. Every time one uses virsh setmem, the value does indeed change (today the value seems to increase by 256 each time), but I can't recall seeing it change more than 2048 in one go. VSZ and RSS seems to be stuck on the same values.

After running a quick poudriere bulk (no packages built, but it still seems to write to all the memory in the VM)
VSZ: 27312164
RSS: 16032432
❯ virsh setmem "FreeBSD buildd" 20480m
# sysctl dev.vtballoon.0 | grep "current\|desired"
dev.vtballoon.0.current: 1536
dev.vtballoon.0.desired: 1048576
❯ virsh setmem "FreeBSD buildd" 20480m
# sysctl dev.vtballoon.0 | grep "current\|desired"
dev.vtballoon.0.current: 1792
dev.vtballoon.0.desired: 1048576
❯ virsh setmem "FreeBSD buildd" 20480m
# sysctl dev.vtballoon.0 | grep "current\|desired"
dev.vtballoon.0.current: 2048
dev.vtballoon.0.desired: 1048576
VSZ: 27262988
RSS: 16036424

To my untrained eye, it seems like the balloon-code runs one loop of trying of adjusting memory, then stops, hence adjusting only with a small amount. It doesn't seem to affect the memory usage on the host. Not in this limited testing at least.

Using virt-manager (https://virt-manager.org/), adjusting the memory allocation there, changes the number by 1MB each time. If I do the same thing on a Linux VM, the value changes by a very small amount first, then rapidly to the correct number. Working in both directions. Indicating that the libvirt on the host is not horribly broken, at least.
Comment 1 Graham Perrin 2026-03-04 21:38:10 UTC
> See also #198344 and #277473

Clickable links to the two closed reports: bug 198344, bug 277473.