Recent content by monkfish

I concur. Thanks team! I am using nested virtualisation on my dev environment to provide a full-on hyper-v test lab. This does help. Anecdotally (with absolutely no graph evidence to back this up for I am a doofus and not yet finished my monitoring!) a side-effect of specifically...

Keep in mind what ARC is when it comes to ZFS - "Adaptive Replacement Cache". Thus caching already happens in main memory. I dug through my previous notes, there's mention of it here https://forum.proxmox.com/threads/vm-virtual-hdd-cache-settings-for-ssd-backed-zfs.114928/ but I have in mind...

Might I suggest you also review the caching you have set on the VM disk? In OP I'm reading that the subsystem is ZFS. Its my undertanding the recommendation is not to set any caching on VM disks themselves when using ZFS to avoid precisely what your seeing ... CPU lockups, duplicate data writes...

Hello, got me an odd one here. Within a last few batch of updates I get a massive negative CPU readout when rebooting any of my containers. Once restarted it settles down but I wouldn't have expected to see this level of oddness. Systems hardened in accordance with CIS but I doubt this causes...

@fiona Thanks for that - I see pve-qemu-kvm-10.2.1-2 in pve-test as of time of writing. I had 2 updates on my test lab whether or not the other one is applicable to this bug or just coincidence wouldn't know. For those that used workaround from @uzumo to hold back pve-qemu-kvm, remember to...

Well... not so much freezing but I have something - non-issue I am proper pushing that box to its limits, its only a dev box. There is no bug or no reason why other than I have, purposely, crammed that box full. This is not on Debian, Proxmox or anything except my empty wallet to add another...

Here you go - in case you've not already found it this is courtesy of @uzumo in this thread...

With respect, disagree - yes there is an issue but seemingly cosmetic. There is a suggestion that if you dont enable iothreads then you're not even affected. Discussed elsewhere - its "test" repo for a reason. Yes there's that issue but early adopters also have a chance to test what else they...

Running great on test lab, small cluster of Dell 7070. CPU(s) - 8 x Intel(R) Core(TM) i7-9700T CPU @ 2.00GHz (1 Socket) Kernel Version - Linux 7.0.0-1-rc6-pve (2026-03-30T09:17Z) Boot Mode- EFI (Secure Boot) Manager Version - pve-manager/9.1.7/16b139a017452f16 No ZFS here, all LVM (thin volume...

Sorry, I'm out. All of the above is on you. Who told you to implement the "test" repository in "an enterprise-grade environment of this scale". It is not published in either pve-no-subscription or pve-enterprise repositories. I don't dispute you experienced an issue - however remember one...

Inneresting! I did not have that occur on mine. For sure the proxmox team will identify the reason why - lets remember this is a package published to test so those of us brave enough to use that will know the caveats. I reckon you might want to limit your 47 servers to a small subset exposed to...

Excellent! Thing is, as alluded to previously, I dont actually think its increased io. I'm not the worlds best at iotop but I wasnt seeing any difference - only in the realtime bar i/o delay and the io pressure stall graph. Good luck hunting, happy to test and/or give any other logs you might...

Interesting. Here is mine for comparison. No zfs on this box all lvmthin. can find one if more results desired. Initial findings after reinstalling pve-qemu-kvm 10.2.1-1, uplift of all Windows VMs to pc-q35-10.2 and flipping aio=threads on all disks. Proper shutdown and restart conducted of all...

Thank you OP for testing and workaround! Same experiences on lesser hardware, small cluster of Dell Optiplex 7070. Unfortunately for me it coincided with research on zswap implementation so spent time eliminating that as a symptom first. For me, applying workaround returned io state and cpu...

You know what? I did actually log a ticket with detailed information. Turns out there was a very old (2021, 2022?) ticket that had precisely one line it it, logged against version 7 with zero activity. More up to date ticket closed as duplicate against this one which has not been touched in 4...