You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
I've obtained drivers from the FedoraPeople virtio group, as described in Proxmox's documentation. What I've found is that in all version above virtio-win-0.1.185 (v62.82.104.18500), the VirtIO SCSI Controller driver (viostor) appears to have some sort of memory leak, as far as I've been able to trace. Using the version ending in 18500, my VM idles around 3GB memory usage and does not spike. Using any newer available version (v100.83.104.18700 - v100.93.104.24000), memory usage at idle is 5GB, spiking at least as high as 8-10GB, though if I recall in testing, I've seen it spike upwards of 15GB.
To Reproduce
Steps to reproduce the behaviour:
install Windows 10, any build between 1909-22H2 [I'm running Enterprise, though I've seen it in Pro as well]
install the appropriate virtio drivers from the fedora people archive [I'm running the network, ballon, and storage drivers, as well as QEMU guest]
observe memory usage with task manager, or any appropriate memory usage tool, such as RAMMap.
for extra confusion, install the vioserial driver (of any versions listed here) and reboot until your memory usage inside the VM is all available memory.
Expected behavior
memory usage should remain similar to its usage under driver version v62.82.104.18500
Host:
Disto: Proxmox 8.0.4 [Debian 12]
Kernel: Linux 6.2.16-14-pve #1 SMP PREEMPT_DYNAMIC PMX 6.2.16-14 (2023-09-19T08:17Z)
QEMU version: QEMU emulator version 8.0.2 (pve-qemu-kvm_8.0.2-6)
Windows version: Windows 10 Enterprise 22H2 [19045.2728]
Which driver has a problem: viostor (and possibly vioserial)
Driver version: 100.83.104.18700+
Additional context
Oddly, I've seen strange memory usage of nearly all 16GB assigned to the VM when the vioserial driver is installed. I'm uncertain whether this is related to the issue, though I am certain there's a leak in the SCSI driver, given it's necessary for VM functionality -- whereas the serial driver shouldn't be from what I've read.
Additional info available upon request.
The text was updated successfully, but these errors were encountered:
Thank you for reporting the issue.
Can you please tell what kind of tools did you use to discovery the memory leakage in viostor driver?
Is it related to the storage read/write activity or the memory leakage happens all the time?
Can you please confirm that the problem can be reproduced with v100.83.104.18700 but not with v62.82.104.18500? I'm asking you because there were no changes in viostor code between builds 185 and 187.
Describe the bug
I've obtained drivers from the FedoraPeople virtio group, as described in Proxmox's documentation. What I've found is that in all version above
virtio-win-0.1.185
(v62.82.104.18500
), the VirtIO SCSI Controller driver (viostor
) appears to have some sort of memory leak, as far as I've been able to trace. Using the version ending in18500
, my VM idles around 3GB memory usage and does not spike. Using any newer available version (v100.83.104.18700
-v100.93.104.24000
), memory usage at idle is 5GB, spiking at least as high as 8-10GB, though if I recall in testing, I've seen it spike upwards of 15GB.To Reproduce
Steps to reproduce the behaviour:
I'm running Enterprise, though I've seen it in Pro as well
]I'm running the network, ballon, and storage drivers, as well as QEMU guest
]Expected behavior
v62.82.104.18500
Host:
Linux 6.2.16-14-pve #1 SMP PREEMPT_DYNAMIC PMX 6.2.16-14 (2023-09-19T08:17Z)
QEMU emulator version 8.0.2 (pve-qemu-kvm_8.0.2-6)
qemu-server 8.0.7
VM:
19045.2728
]viostor
(and possiblyvioserial
)100.83.104.18700
+Additional context
Oddly, I've seen strange memory usage of nearly all 16GB assigned to the VM when the vioserial driver is installed. I'm uncertain whether this is related to the issue, though I am certain there's a leak in the SCSI driver, given it's necessary for VM functionality -- whereas the serial driver shouldn't be from what I've read.
Additional info available upon request.
The text was updated successfully, but these errors were encountered: