Now I am able to reply each one:
pdecker
I think I had this issue too. I had been using Gnome Boxes and decided I’d switch to VirtualBox. I couldn’t run them at the same time though. After I removed Gnome Boxes it worked for me.
As I see, it seems an internal conflicts between software. I remember this mostly in Windows years ago thanks for the .dll files
Daniel
Blacklist KVM add blacklist kvm_intel and blacl kvm to /etc/modprobe.d/blacklist.conf
That kind of solution was suggested in other network, the other solution is about GRUB. I am going to create other post to know what approach should be used and why
László
Moving from Debian 12 to 13 I faced the same problem.
My readings told me it’s because the newer kernel loads and inits kvm module by default, whereas the previous version did not.
Yes, it seems the Kernel update is root of the situation. Wondered why that approach was taken, I meant load that module by default
This makes impossible for Virtualbox to init virtualization on its own
Now is clear the following part of the complete message:
- VT-x is being used by another hypervisor (VERR_VMX_IN_VMX_ROOT_MODE)
so the sulotion is either to disable kvm initialization in GRUB adding a kernel parameter (
kvm.enable_virt_at_load=0) , or blacklist kvm module via /etc/modprobe.d/something.conf.
Yes, as I said there are two options
I choosed the latter
Can you tell me why? What is better than the former?
I want avoid crush the OS by a mistake, because it is a direct installation I need be careful with this
Adding that, and rebooting made Virtualbox working flawlessly.
Huge thanks for that confirmation
As for version, I have now Virtualbox 7.2, is there a reason you are still trying 7.1?
Thanks to this situation I did do realize about 7.2.
I installed VB 7.1 without the .deb approach. Therefore it was installed by the repository approach of Oracle/VirtualBox itself instead. It because for 7.1x with a .deb file rises a party of hell dependencies (It did not happen for 6.1.x series) so I changed the approach. It seems the 7.1.x had reached its own top (so it seems there are no more new releases).
In other machine I use in peace VB 6.1.x yet
Neville
I have not noticed any problem with virt-manager and I have it in Void Linux which would have a newer kernel than Debian.
I remember that other tool than VB
I think a more desirable solution would be to let the new kernel have its way, and modify virtualbox instead. The problem lies with virtualbox not keeping up with linux kernel changes.
Well has sense the secondary software must adapt to the principal software. I think is a kind of common conflict for some software after an upgrade
JoeIA
What is your output for?
lsmod | grep kvm
I am going to keep that info in standby if none of the two possible solutions work
you might also do a quick read on this post Issue with Virtual Box 7.0 on Ubuntu 22.04
Thanks for the link
László
The virt-manager uses KVM behind the scenes, which uses the recently boot-time activated virtualization “driver”. So it’s obvoius it won’t have problems
Has a lot of sense
On the other hand Virtualbox uses its own solution, which is incompatible with KVM.
Clear now …
I doubt Oracle will do that.
It depends if that refactoring is a big problem to apply
But yes, it would be nice to have it work that way.
Yes
I used Virtualbox for a long time, recently tried Quemu/KVM and virt-manager.
Both work well for me on my desktop -not at the same time though.
Sounds great
With KVM I see a slightly better performance of the guest.
I am aware through readings and some posts that the 2 other tools are faster than VB
But Virtualbox makes it possible to run VM’s on my laptop with bridged network through the wifi, which is just awfully painful to achieve with KVM/Virt-manager.
So I decided to keep Virtualbox.
Interesting experience
Thanks to all