VirtualBox KVM Public Release (cyberus-technology.de)

https://en.m.wikipedia.org/wiki/Kernel-based_Virtual_Machine

https://xkcd.com/1053/

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.

Much of the reason I refuse to use Virtualbox for anything is how scummy Oracle is.

Guest integration (drag'n'drop, clipboard), USB passhthrough and audio support is also top-notch in VBox.

Most of the VMs are encrypted, so I feel safe traveling with them. Various secrets are also encrypted, but the encryption of the VMs themselves mean that I don't have to worry about losing my device at an airport and someone else potentially getting access to things they shouldn't. There are schemes that make this work in virt-manager and KVM, but I didn't like any of them as much; I didn't want to rely on the host for filesystem-level encryption (see portability), and I have previously had a bit of trouble with full disk encryption, so I wasn't comfortable relying on that. VirtualBox essentially is also doing full disk encryption, but it's invisible to the guest and seems to be reliable.

For portability, I should be able to use https://www.vbox.me/ to install the VMs and a host onto a flash drive and be able to run any of my environments from any Windows host without additional installations. Haven't actually tried this yet (happily, I no longer have easy access to Windows machines!), but it was a big point in favor.

Most of my environments now get auto-configured through Vagrant: https://github.com/robsheldon/vagrantfiles, so I get some of the benefits of virt-manager that way.

I really don't love relying on Oracle for anything

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.

    $ virsh net-dumpxml default6
    <network>
      <name>default6</name>
      <uuid>73590ea2-eb15-4e67-b104-319721bdf302</uuid>
      <forward mode='route'/>
      <bridge name='virbr1' stp='on' delay='0'/>
      <mac address='52:54:00:ff:a7:2d'/>
      <domain name='default6'/>
      <ip family='ipv6' address='2001:db8:ffff::1' prefix='48'>
      </ip>
    </network>

I'm honestly surprised there aren't more alternatives. Especially since SPICE has gstreamer instegration. Gstreamer can natively do webrtc video and data back channel. Someone could hack together a webrtc broweser-based VM viewer and I suspect there's a lot of interest, potentially money making things you could crate.

KVM also always has the hottest new (performance-relevant) features, because Intel and AMD will always build their hot stuff into KVM first.

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.

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.

From a performance perspective, it's a bit more complicated. KVM has support for modern virtualization features (Intel APICv, AMD AVIC, etc) that vanilla VBox lacks. You get these in the VirtualBox/KVM version. On the other hand, vanilla VBox emulates most devices in the kernel (see above). So SATA emulation in vanilla VBox is very fast compared to KVM/Qemu or KVM/VirtualBox for a bit unfair reasons. Modern devices, such as virtio or NVMe, are not as impacted by that.

tl;dr So the performance you get depends on your workload. If it's very interrupt heavy, VirtualBox/KVM will win. If it uses antiquated virtual devices (SATA), vanilla VirtualBox (with vboxdrv) will have an edge.

Which networking setup do you use for your pentesting VM? Ideally, I'd want a setup where the VM can access the internet (and therefore the HTB VPN), but not anything inside my local network. But I don't quite know how I could achieve that, at least in a way where I'd trust it to be reliable. Maybe the whole idea's a bit too paranoid to be practical in general, I don't know, so I'd love an expert opinion on this :)

Usually, I'd be using QEMU, but I'd be fine with using VirtualBox for this case if it includes something that makes this easier.

It's as FOSS as the VirtualBox open source edition.

> Do you expect Oracle to merge this?

That would be nice, but I wouldn't hold my breath. Oracle gonna Oracle.

> If oracle doesn’t merge this, will you keep on maintaining it, potentially forking VirtualBox?

We don't intend to fork VirtualBox. VBox has a somewhat modular architecture where you can plug-in different hypervisor backends. That's what we did. It's not as modular, but our changes to core VirtualBox code is very small.

As far as our plans go, we are pretty open at this point. We are very interested to get to know people that find this useful!

You can sill select these PV interfaces with VirtualBox-KVM, but the underlying hypervisor is different (kvm vs vboxdrv).

This new code is about using different virtualization technology on the host system.