While HashiCorp plays license roulette, Virter rolls out to rescue FOSS VM testing Virter is a useful little tool if you often create – and then remove – VMs to try stuff. It's arguably carried on the ripples from HashiCorp dropping the BSL into the FOSS pond. This year's Open Source Summit Europe was in Vienna, which as the The Reg FOSS desk arrived was stricken with storms and flooding, as was much of …
I used Virtual Box for years, but have recently switched to KVM. I used both for automated testing of software.
Both have GUIs for creating and managing the VMs, and both have command line tools which can do everything the GUI can plus a great deal more. I generally use the GUI to setup the VMs, do some initial testing of the VMs, and to debug my automated testing set up. I use the command line tools to script all of the actual software testing.
As to how they compare, I found both to be roughly equivalent for what I use them for, although KVM seems to be better maintained as a project than VB has been lately (things would stop working after an update and Oracle would take a long time to issue a fix).
I don't know the name of the VB GUI, but the one for KVM is called Virtual Machine Manager (VMM). I use only a fraction of the features in the VB GUI, but everything that I wanted from the GUI was there.
KVM VMM has fewer features, which is a plus and minus. From a plus perspective it means that I was able to figure it out fairly quickly, as the number of options is much more limited. On the minus side is that VMM doesn't create or delete snapshots in the GUI itself, you have to do that from the command line. However, that has not turned out to be a big deal so far.
With VB you can give snapshots a meaningful name, while with KVM they're simply a random integer. While the meaningful names were nice to have in VB, so far the lack of them hasn't been a big deal with KVM.
The story mentions networking. My test scripts SSH into each VM as it is running to run the tests on the software under development. The default way that VB does networking (localhost plus port) results in some rather unusual address formats and a bit of going over the ssh man pages to figure out how to use it. It also means that the address format for VMs is different from the address format for actual hardware over the network.
With KVM I installed the optional "libnss" and found that addressing VMs is done by default in the normal way the same as for actual hardware.
It may be possible that VB can be made to work the same as KVM in this respect, but you need to be a networking expert to stray away from the defaults for either as neither one documents this area very well. They just assume that you know lots about network stacks and can figure it out for yourself. When I started using VirtualBox however I was too busy to spend the time to deviate from the defaults, and when I got things working it was less painful to just leave it as is than to change everything. With KVM I just installed libnss and everything just worked the way it ought to.
I test using all the major Linux distros, BSD, and Windows, so I have plenty of experience installing them in VMs. I've looked at both Vagrant and Virter, and didn't really see any advantage to using them. Things may be different if I were responsible for setting up and managing VMs for large development teams for multiple projects. You really have to dig into how you would use them in your particular application to see if they really offer any advantage.
As for vmshed, so far as I can see it's meant for testing the VMs themselves, as opposed to just using the VMs to test software applications. If you are managing a project like Virter then you probably need vmshed. I don't think the way it works however is suitable for normal application testing. So far I haven't seen anything useful for running application unit tests on a combination of VMs and actual hardware that is suited to being hosted on a regular desktop for use by a single developer or small team (as opposed to cloud services). I have my own custom solution that works in my use case.
"On the minus side is that VMM doesn't create or delete snapshots in the GUI itself"
Yes it does. The furthest right button on the toolbar, a picture of a monitor with the Play symbol in it, with the tooltip "Manage VM Snapshots".
If you don't have it, must be something off in your deployment, I guess, but it's there on a stock Fedora deployment.
You are correct in that snapshot management is there in KVM VMM on the console window (the window that opens you click the console button).
If you right-click on the snapshot number you can start or delete that snapshot. I had not noticed that I could bring up a context menu using right-click, I had thought I could only see them listed.
However, I don't see a way to create a snapshot using VMM. If it's there, it's not obvious to me. If I can't create a snapshot using VMM, then I don't see the point of deleting them using VMM, at least not for my use cases. Creating and deleting snapshots via the command line is not difficult however.
Overall I am still happier with KVM than I was with Virtual Box, and I find that VMM does pretty much everything that I want from a GUI tool.
I will probably write a bash script with a Zenity GUI to handle any routine VM chores involving snapshots (I need new snapshots after doing updates). I had been thinking of doing the same for VirtualBox, as even if the GUI can do it, it still needs multiple steps and it's possible to make mistakes in the process. Automating it via scripts is the way to avoid that.
"I don't know the name of the VB GUI, but the one for KVM is called Virtual Machine Manager (VMM)."
Virt Manager is *one* GUI for KVM, it is not the only one, and it is also a GUI for LXC and Xen as well.
You cannot directly compare KVM with Virtualbox, Virtualbox is both a hypervisor and a CLI/GUI for managing that hypervisor; indeed if you edit the settings of a Virtualbox VM the in System -> Acceleration -> Paravirtualization Interface you can choose "Hyper-V" or "KVM" as well as Virtualbox's own "Default" hypervisor.
KVM is a kernel module that provides basic virtualisation support, it can be used by various hypervisors (QEMU, cloud-hypervisor, firecracker, etc) and GUIs or CLIs (i.e qemu-system-x86_64, virsh from libvirt, etc)
"With KVM I installed the optional "libnss" and found that addressing VMs is done by default in the normal way the same as for actual hardware."
I assume you are referring to libvirt-libnss, this is an "addon" for libvirt, not specifically for KVM.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
