It’s not the first time but for once I thought I would upload this to see if someone has any ideas why it would occur.
Last updates of today. It s a simple fedora server with libvirt and qemu installed under fedora 34
Of course as each times if I force power off and reboot then everything is okey. But still, it would be nice to know why it occurs.
Well it’s not the first time and it happens I guess on specific packages update.
And it happens every time on a sudo reboot.
So I don’t know if it happens at boot sequence or at the shutdown.
If you tell me what you are looking for specifically that would help me.
It doesn’t happen during the vm are running for example. And it’s not a memory problem, nor a cpu problem nor a cache problem. Everything have been tested. The only time it is happening and I can’t stress it enough, it’s after a package update and most of the time at a reboot, only one time it freezed the system completely.
Do you want the list of packages maybe which have been released to the repos today?
And every day the server is put up to date
this is the dnf transaction preceeding the sudo reboot command
the links you provided are all speaking about kernel panic.
Since nearly every day(not on sunday), there are updates releases that affects libvirtd or virtualization, every day the server is completely rebooted.
Since the first kernel panic or hang (I don’t know how you want to call it) a few months ago, and my destroyed vm of opnsense because of it, every dnf transaction are done when the VMs are down and nothing else besides the host system is running.
Those VMs are using the total amount of 32G RAM and CPU is mostly at 50% all the time, and I have never had any problem while the VM were running and that I wan’t doing a dnf transaction. If it was a kernel panic, at least every one in a while, because of the random load the VMs would have caused a kernel panic by now(as it is specified in the links you provided where the people are speaking about hanging while working) which is not the case.
Do you still want me to configure the kernel dump in the grub for future freezes?
If yes, then we will need to wait for a future dnf transaction which would cause the crash.
Where did you see exactly the change in a bfq parameters?
Because They were talking about a patch a few older iteration back of the kernel but that does not concern me then since their patch has been already applied.I didn’t see anything else.
Also you should know that swap is nearly not used in my case. Everything seems to go to ram and not swap
I reviewed the problem in deep. And look for everything related to something that might be even remotely exotic to kvm.
Indeed one of my vm was starting a guest vm of its own and I forgot about that. So I guess that the new kernel update did modify something about nested virtualization.
And I’m suspecting that the bfq call trace was about that too.