https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=292570
Bug ID: 292570
Summary: [virtio] virtio-balloon does not balloon correctly
Product: Base System
Version: 14.3-RELEASE
Hardware: amd64
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: [email protected]
Reporter: [email protected]
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.
--
You are receiving this mail because:
You are the assignee for the bug.
