Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

VirtualBox KVM Public Release

cyberus-technology.de

Post reply on HN
Print view View original

121–130 of 205 posts

Re: VirtualBox KVM Public Release

#121

Post by [deleted] »

nonrandomstring wrote: post #96
blitzclone wrote: post #28

Earlier quoted context omitted.

There is no real connection to UML here. Hardware virtualization (Intel VT, AMD-V) are much faster in practice and also don't require the guest operating system to be heavily modified. So besides as curiosity or test vehicle, approaches like UML are pretty dead.

Thanks. So, slow as it may be, the win for UML (which seems to still have a heartbeat) is that it can run on uP without any specific virtualisation capabilities, right? If I could run Linux on a Z80/6502 then in theory I could run a virtualised Linux on a Z80/6502.

[deleted]

Re: VirtualBox KVM Public Release

#122

Post by als0 »

mark_undoio wrote: post #117
nonrandomstring wrote: post #96

Earlier quoted context omitted.

Thanks. So, slow as it may be, the win for UML (which seems to still have a heartbeat) is that it can run on uP without any specific virtualisation capabilities, right? If I could run Linux on a Z80/6502 then in theory I could run a virtualised Linux on a Z80/6502.

Yes - plus the original win of UML was also being able to run virtual instances on a kernel without proper virtualization capabilities. In the early 2000s people used to use UMLs as a hosting platform - they didn't have the same security isolation as a proper VM (or even, necessarily, of a container) though.

How do containers have better security isolation than UML?

Re: VirtualBox KVM Public Release

#123

Post by eek2121 »

eVeechu7 wrote: post #86
sph wrote: post #19

Finally! Every time I need to run a virtual machine, I choose libvirt because it's more performant and easy to deal with than Virtualbox (no kernel module, etc.), but the GUI choices are pretty terrible. The "best" libvirt GUI is virt-manager and it's very, very buggy and lacking features (i.e. doesn't play nice with HiDPI screens, no way of configuring IPv6, etc.) Many times I have caved and chosen VirtualBox simply…

I thought virt manager was ok but honestly your complaints about it are specific and fair.

Virtual box has graphical configuration for a ton of different options. It also “just works” in many cases and is relatively easy to use.

I am surprised the open source community has not built better gui tools, and no project, closed or open has made configuring pcie passthrough easy.

I have always wanted to be able to run Windows in a virtualized session with my GPU for gaming, and use my onboard APU for the Linux host, but the configuration is daunting, and many of the games I play today don’t work on linux thanks to anticheat or DRM.

Re: VirtualBox KVM Public Release

#124

Post by ComputerGuru »

blitzclone wrote: post #28
nonrandomstring wrote: post #9

Earlier quoted context omitted.

Is there a connection to User Mode Linux (UML) from around the same time? Or are these completely unrelated projects? I get that running a kernel in the user space provided by another kernel is not really the same as a proper hypervisor, but have never really dug deep into why and what the various tradeoffs are.

There is no real connection to UML here. Hardware virtualization (Intel VT, AMD-V) are much faster in practice and also don't require the guest operating system to be heavily modified. So besides as curiosity or test vehicle, approaches like UML are pretty dead.

The “original” UML is/was, I believe, NetBSD running as a “rump kernel” and something that virtualization of the actual kernel does not, directly and on its own, fill the shoes of.

Re: VirtualBox KVM Public Release

#125

Post by treffer »

ImPleadThe5th wrote: post #32

I'm quite inexperienced with Virtualization. Are there benefits to kernel based virtual machines beyond (what I assume is the primary benefit) performance?

I wouldn't call it kernel based. It's not like this is an in-kernel emulation. I would stick with hardware virtualization.

KVM is a userspace API, and kvm-intel/kvm-amd are the drivers for the hardware.

You will be using hardware features. That's also why it is in the kernel: nothing but the kernel should have full unlimited access to the CPU to set this up.

So you could say it must be in kernel to keep the kernel secure. And the performance benefit is "just" exposed hardware features.

The kernel does not provide additional things. As far as I understand: you set up a dedicated memory space and handle traps that halt the execution e.g. when the VM talks to the PCI bus. (It's been a while since I looked this up)

But you need the pieces, especially virtual PCI devices. That's where qemu or VirtualBox enter the scene (or minimalist systems like firecracker). They provide a repository of virtual hardware and all the auxiliary methods to boot a virtual machines. You also need to emulate something like a BIOS or UEFI.

You can think of it as your CPU removing the need to emulate the very same CPU (and a memory controller). You still need to emulate the rest though! But running on the same CPU removes most performance penalties. You run at native speed.

Newer generations can even nest this. Having virtual machines in virtual machines. That's mostly useful for cloud environments so that the cloud provider can run kvm based VMs and you are still able to run VMs inside that VM.

Re: VirtualBox KVM Public Release

#126

Post by melvyn2 »

_cenw wrote: post #119
WhyNotHugo wrote: post #93

Earlier quoted context omitted.

virt-manager plays fine with hidpi on Wayland. On the opposite side, VirtualBox’s GUI is super buggy in Wayland. It’s basically the opposite for both. I use virt-manager because the GUI is simpler (and setting up virtualbox is a nightmare anyway). Regardless, this feature is a step in the right direction. I’m wondering if distributions will pick it up or if it will ever be integrated upstream.

That's a very recent change to virt-manager, so recent it's on nixos-unstable, but not on nixos-23.11. So it might be in Fedora 39 and some rolling-release distros... and nowhere else.

Could you link the change? At least a few days ago virt-manager still seemed to have scaling issues with guest displays, on nixos-unstable. I had viewer scaling on though as a workaround, so maybe I just didn’t notice.

Re: VirtualBox KVM Public Release

#127

Post by monocasa »

ComputerGuru wrote: post #124
blitzclone wrote: post #28

Earlier quoted context omitted.

There is no real connection to UML here. Hardware virtualization (Intel VT, AMD-V) are much faster in practice and also don't require the guest operating system to be heavily modified. So besides as curiosity or test vehicle, approaches like UML are pretty dead.

The “original” UML is/was, I believe, NetBSD running as a “rump kernel” and something that virtualization of the actual kernel does not, directly and on its own, fill the shoes of.

UML is older than NetBSD rump kernels.

Re: VirtualBox KVM Public Release

#128

Post by nyrikki »

Y-bar wrote: post #3

I have ever only heard KVM in the context of a Keyboard Video Monitor-type device but somehow I can't fully fit that into the concept of a virtual machine. Does it mean something different here?

While an over simplification, here is the context

There are two large hypervisors in the Linux world.

Xen, which extends the kernel to support virtual CPUs with time slices.

KVM, which assigns each virtual core a process that uses the Linux scheduler.

When a hardware vm vcpu core is preempted there is vmexit call that has to reset registers etc... and it is expensive.

Xen is what legacy AWS instances ran on and has advantages for being fair to guests is an easier task.

KVM has the advantage of gaining the benefits of the Linux scheduler which is red black tree based and well optimized.

When a new CPU comes out for example, KVM gains support from the upstream while Xen has to support it themselves.

Once technology like cgroups improved the benefits of letting your thread complete and not be preempted due to the time slice expiring avoided the cost of vmexit.

In theory, leveraging the inherently optimized core Linux features is what will also benefit virtualbox.

Most people who use KVM are using an abstraction layer like libvirt that hides how it is implemented.

In fact if you look at the processes you will see qemu even if KVM is how it is implemented.

Re: VirtualBox KVM Public Release

#129

Post by dijit »

WhyNotHugo wrote: post #95
ImPleadThe5th wrote: post #32

I'm quite inexperienced with Virtualization. Are there benefits to kernel based virtual machines beyond (what I assume is the primary benefit) performance?

You can’t use virtualbox’s kernel module and kvm at the same time. This basically means that you can’t use virtualbox and qemu at the same time. If you use virtualbox with this new backend, you can use it concurrently with qemu (and a few other virtualisation tools). KVM is also part of Linux itself, so there’s a lot less haste with setting it up.

virtualbox drivers are/were a constant source of kernel panics on MacOS and Linux too, so that should not be underestimated.

IIRC they also disabled ASLR kernel wide.

Additionally, and perhaps less important: USB3 is a commercial feature of virtualbox, there are stories of companies getting C&D letters (or Audits/Invoices) from Oracle because a developer had installed the virtualbox extensions..

Re: VirtualBox KVM Public Release

#130

Post by ImPleadThe5th »

treffer wrote: post #125
ImPleadThe5th wrote: post #32

I'm quite inexperienced with Virtualization. Are there benefits to kernel based virtual machines beyond (what I assume is the primary benefit) performance?

I wouldn't call it kernel based. It's not like this is an in-kernel emulation. I would stick with hardware virtualization. KVM is a userspace API, and kvm-intel/kvm-amd are the drivers for the hardware. You will be using hardware features. That's also why it is in the kernel: nothing but the kernel should have full unlimited access to the CPU to set this up. So you could say it must be in kernel to keep the kernel se…

That clarifies some things and gives me some tails to chace after! Thanks for the detailed response!
Post reply on HN