I mean. I cant use qemu on that I5 cpu because is slow without kvm. Kvm does not work on that cpu because it is needs some extensions from the cpu that there arent. Bhyve is the only alternative because it is a mix between qemu and kvm in terms of speed. So. My question is : how much old cpu there are that cant run kvm ? I dont think mine is the only one. May be a good idea is to port bhyve on linux to cover the little needs of the users who wants a fast hyp on the old cpus. and not,qemu in these cpus is very slow. is not the solution. I really think there isnt any better alternative than qemu in these situations. The only one is bhyve if someone wants to try the scenarios that im talking about,they will understand for sure. and maybe they want to start the porting of bhyve on linux.
Il ven 2 giu 2023, 15:01 Michael Stone <mst...@debian.org> ha scritto: > On Fri, Jun 02, 2023 at 08:41:44AM +0000, Victor Sudakov wrote: > >Interestingly, libvirt claims to support bhyve, I just never felt a > >need for such sophisticated tools to run just several VMs. > > Yes, it sounds like you should just ignore libvirt entirely and just > install qemu-system-x86 (and not qemu-system-gui). That's a minimal > system with no gui, you just run qemu from the command line to start > VMs. If you run with --enable-kvm or --machine accel=kvm, then you're > using kvm (assuming the kernel module is loaded). > > That said, there's a huge convenience factor for libvirt. You may end up > with libraries you'll never use on the server, but so what? You can > install virt-manager on a client system and manage with a gui that uses > ssh in the background, or use virsh on the server. If you find yourself > needing to do something infrequently, it's much easier to discover it in > the virt-manager gui than it is to dig through docs on how to do it from > the qemu command line. (This is, of course, the usual tradeoff between > text and graphical interfaces.) It's also easier to use > standard/documented solutions for startup, config, storage, etc, than it > is to remember what bespoke solution you came up with several years ago > when something breaks, even if all the abstraction layers of libvirt are > "less efficient". > >
