Search results

Yeah, a very stupid one you could say :(. Weird that I didn't notice it until now o_O . Yet another Case of the Problem being between the Chair and the Screen. Sorry about that :(. I would have guessed that since the default none Cache Options for the Virtual Disk were used (writes ARE cached...

@fabian: spotted the Issue, almost by coincidence, while cleaning up /etc/fstab File. There was a sync Mount Option set for the / Filesystem in /etc/fstab :rolleyes: . Not sure why I did that some Time ago ... So essentially every single write would be forced to be written immediately to Disk...

For reference the same base Load on VM 156 APTCacherNG which is fast

Base Load on VM 151 MirrorNAS using atop

OK I'll stop it. Anyways the load is Peanuts I don't think it will make any difference.

@fabian: atop as you requested (fio still running)

iothread shouldn't matter and discard being disabled on the Fast VM (156 APTCacherNG) is even more weirder (it should be slower not faster if anything). I guess it doesn't make too much of a difference at this speed and probably only relevant for TRIM Operations.

htop (while fio Benchmark is running VERY SLOWLY) since I have it installed it already. I'll try to install atop as well ...

Do I need to stop the fio benchmarking ? It's doing 1K at Queue Depth 1 now (4th Test only) ...

Also the Load on the Guest 151 only If I were to take a blind Stab at it, I'd guess that only 10% of the CPU Power is actually being allocated. Not sure how that causes the Performance of the Storage to drop THIS much though. It's weird because from LiveUSB + chroot it worked fine, so there...

Not really. I mean right now the entire Server load as seen from the Host is very low and most of it it's caused by running fio right now. Everything else is pretty much Idle.

The Virtual Machine 151 MirrorNAS was left unbootable because I interrupted an apt dist-upgrade and that left either the Kernel or Initramfs in a bad State (probably due to a half-compiled ZFS DKMS Module). I basically did a rescue of that broken VM using a Virtual USB Pendrive (Debian 13...

So @fabian First results are in for the Normal / Fast VM (156 - APTCacherNG). Now I'm recovering the other one from a Chroot and it's MUCH faster already compared to when booted from the Virtual Disk (I booted from a Virtual USB Pendrive).

If it's an IO Issue, I'm curious as to why it only affects one VM. My initial Theory was q35 vs i440fx but that proved to not be the Case unfortunately :( . These are old VMs and therefore still using 8k for volblocksize (both of them). IIRC only one ZVOL is used (for MirrorNAS the other one...

Thank you @fabian for your quick Reply. Storage Setup: root@pve99:~# zpool status pool: rpool state: ONLINE status: Some supported and requested features are not enabled on the pool. The pool can still be used, but some features are unavailable. action: Enable all features using 'zpool...

I am having a Problem with one Debian Guest VM (running Debian 12 Bookworm AMD64, currently running the Upgrade to Debian 13 Trixie AMD64). It's extremely sluggish, even to just run apt update. While compiling Kernel Modules (e.g. zfs via dkms) I can see that the CPU Usage never gets above 15%...

@t.lamprecht: wouldn't it be possible to allow also testing (next-stable) Releases of Containers to boot without Issue ? I am also running some CTs (and VMs) for the next Stable Release (Debian and Ubuntu currently, but I could imagine doing the same for Fedora for Instance) for the next Stable...

I observed the same after upgrading a cloned CT to Ubuntu 25.10. Might want to add this to /usr/share/perl5/PVE/LXC/Setup/Ubuntu.pm since it's going to be released soon anyways: '25.10' => 1, # questing

I agree 100% :( .

To be fair Proxmox VE is far from the only one doing this. At least in this Case the Workaround is quite simple. And most of the Stuff gets fixed relatively quickly by the Proxmox VE Team. They also provide good Answers in most Cases, although I admit that some Kernel Panics & Regression (very...