[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: A hypervisor for a headless server?



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 <mstone@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".


Reply to: