The open source VirtualBox hypervisor is still alive and kicking after being absorbed into the Oracle collective more than two years ago, and has just gotten what the project calls a major update with release 4.2.
Oracle has also revved its Enterprise Manager 12c to turn it into a platform cloud manager for puffy infrastructure …

VirtualBox hypervisor is not a bare-metal or type 1 hypervisor

Re: VirtualBox hypervisor is not a bare-metal or type 1 hypervisor

Straight from wikipedia as I can't be bothered to think about the best way to explain this on a friday night:

Type 1 (or native, bare metal) hypervisors run directly on the host's hardware to control the hardware and to manage guest operating systems. A guest operating system thus runs on another level above the hypervisor.

This model represents the classic implementation of virtual machine architectures; the original hypervisors were the test tool, SIMMON, and CP/CMS, both developed at IBM in the 1960s. CP/CMS was the ancestor of IBM's z/VM. Modern equivalents of this are Oracle VM Server for SPARC, the Citrix XenServer, KVM, VMware ESX/ESXi, and Microsoft Hyper-V hypervisor.

Type 2 (or hosted) hypervisors run within a conventional operating system environment. With the hypervisor layer as a distinct second software level, guest operating systems run at the third level above the hardware. BHyVe, VMware Workstation and VirtualBox are examples of Type 2 hypervisors.

Re: VirtualBox hypervisor is not a bare-metal or type 1 hypervisor

VMware ESX, Xen and KVM are Type 1 Hypervisors. Xen doesn't run on top of Linux kernel, a Linux kernel for the management console runs on top of Xen. KVM is Type 1 because it is a part of the Linux kernel, rather than running on top of it. The Linux kernel _IS_ the hypervisor in that case, hence it's Type 1.

Xen doesn't really run on Linux. The Hypervisor itself boots first and handles all scheduling. It then boots a dom0 (which could be Linux, NetBSD, or Solaris 10). The dom0 acts as a management "console" and also provides the various hardware drivers.

So I/0 runs through the dom0, but the Hypervisor itself does run on bare metal.

"....So, separate question: who wants a VirtualBox hypervisor for ARM machines?..." No thanks, I want a production-ready hypervisor, not a toy. VMware would still be the first choice (easiest to get the moneymen to sign off on as they recognise the name), followed by KVM if we can get full RHEL on ARM, please, and maybe Hyper-V if Microsoft can be tempted. But not VirtualBox, thanks.

"And regardless of what the host and guest platforms are, if you're emulating, the performance is going to suck."

Emulation doesn't have to be sucky. Until VT-x came along, all X86 VMMs had little choice but to emulate some features. VMware were sufficiently proud of their emulation that they published a paper a year or so back explaining how their emulation was actually faster than VT-x for some code.

".......There is already a RHEL clone for ARM....." Thanks, Gordan, I was made aware of RedSleeve back in May by a Reg article (http://www.theregister.co.uk/2012/05/29/redsleeve_enterprise_linux_arm/). Whilst I wish you luck with the endeavour, what I require is Linux with proper Red Hat-like support, 24x7. Whilst roll-your-own is fine for some, for enterprises it's usually not acceptable to the moneymen. RH have worked very hard over the years not just to offer a solid distribution but also a good support structure.

VirtualBox is pretty good, but RPM packaging needs a fix

I do quite like VirtualBox (though I think it needs a Web front-end rather than a graphical GUI, because it makes things easier to admin remotely), but I wish they wouldn't do what some Linux RPM-packaged software does (I'm looking at you, LibreOffice) and put the version number in the package field.

For example, the RPM for RHEL/CentOS 6 has a name of "VirtualBox-4.2" and a version number of "4.2.0_80737_el6". This is quite frankly dumb because you have to use "VirtualBox-4.2" as the package name in various RPM commands (e.g. "rpm -qi VirtualBox-4.2"), you can't just do "yum update VirtualBox" or "yum update VirtualBox-4.1" (the previous release) and you can't "rpm -Uvh" to upgrade either.

Nope, you've got to manually remove the old version ("rpm -e" or "yum remove") and then install the new one instead. This is dismal - no-one but a few VirtualBox developers will ever need two versions simultaneously installed (that's the lame excuse LibreOffice gives too and it's wrong because there's a separate LibreOffice dev set of RPMs!). Fix it Oracle - it's not as bad as LibreOffice's dismal packaging (over 50 RPMs, WTFs all that about?) - but it makes updates to VirtualBox a real pain.

Re: VirtualBox is pretty good, but RPM packaging needs a fix

I came across this, might fit the bill <http://remotebox.knobgoblin.org.uk/>

"RemoteBox allows you to administer an installation of VirtualBox residing on another machine such as a server, as if it was installed locally. You can also interact with the displays of the guests. This allows you to treat VirtualBox much more like an installation of Xen, KVM or VMware ESX."

Why does anyone even bother with VirtualBox any more?

When it comes to performance, VirtualBox's performance is so utterly disgraceful I've no idea why anyone even bothers any more, especially when there are far better alternatives that are just as easy to use.

Re: Why does anyone even bother with VirtualBox any more?

@HBT:

It's not the storage performance that's the only issue - even where everything is running from cache (note that the test I posted I link to lists that the entire data set is primed into caches, and host write caching is enabled) VirtualBox is 20x (I bullshit you not) slower than bare metal. That's eyewateringly poor.

Re: Why does anyone even bother with VirtualBox any more?

Yes yes yes but......

...... can I simply drag and drop virtual machines files from one machine to another, and have it simply boot with out any kind of preparation like I can with VMware virtual machines, or do I still have to go through all that "Export" nonsense?

Re: Yes yes yes but......

In my experience, yes you can. (A Windows guest will notice the difference and insist on re-activation, but I assume that this happens on VMware, too. If it doesn't, I'm sure Microsoft's lawyers won't be happy.)

Re: Yes yes yes but......

Nope VMware guests simply load after a "Has this VM been copied from another machine" prompt. If you choose "yes" It loads if you choose "no" it doesn't. A guest only notices the difference in physical hardware. A virtual machine should be unaware of the physical hardware. I'm happy to confer with you directly with several VMWare / Vbox examples to enlighten you.

This is an example of the previous rigmarole I've had to go through when recovering someone elses Vbox machines from failed hardware:- http://www.howtogeek.com/howto/36870/how-to-backup-and-move-virtualbox-machines/ In all cases, it was expected that preparation had been performed to facilitate the transfer from one physical hardware to another. However in my case all I got was a "erm, we have been using Vbox for some time now instead of VMware, we thought making a copy of the files was enough, we are unable to restore from the backup, HELP!!!"

If this has now been resolved with Vbox, please point me to the relevant documentation so I can pass this onto my clients who would like to use Vbox, but I keep pointing to VMware simply because the clients are hardware agnostic, and I can cut and paste the files to as many machines as I want, at will.

Re: Yes yes yes but......

"A guest only notices the difference in physical hardware. A virtual machine should be unaware of the physical hardware."

You appear to have contradicted yourself there, but I don't think it affects the conclusion.

My experience is that I've moved VMs between four machines (2 with AMD CPUs and 2 with Intel) by copying the directory containing the VM. In each case, Windows noticed the different CPUID, but the VM actually ran perfectly normally. However, as far as I'm aware this isn't guaranteed by documentation so I can't offer you anything for your clients. There is some wording in section 10.1.2 of the user manual that mentions the tedious export/import procedure as a limitation of the old (pre-4) way of storing files, but it doesn't come out and say explicitly that the new layout removes this restriction.

Re: Yes yes yes but......

> I keep pointing to VMware simply because the clients are hardware agnostic, and I can

> cut and paste the files to as many machines as I want, at will.

The only host-specific hardware that a VM normally sees is the CPU. I say "normally" because Virtualbox lets you set a VM's CPU to a "synthetic" one that is neither AMD nor Intel, this preventing the VM from seeing any CPU change if you copy it it from one PC to another with a different physical CPU.

See:

vboxmanage modifyvm --synthcpu on|off

Of course your VM settings might specify things that impose certain hardware requirements on a different PC that you may copy it to, for example having the same physical network cards, but thats hardly a virtualbox limitation.

Oracle got it all wrong with VirtualBox

What Oracle did was they tried to compete with VMware and everyone simply said "Oracle, they're not an OS company, they make databases!" What Oracle SHOULD have done played to their strengths and turned it into a database sale rather than a hypervisor one. To do so they should take their Oracle DB for Linux, put it on top of a self-installing image of Oracle's clone of RHEL, then put that on top of VirtualBox, put the whole lot in a GUI wrapper and sell it as Oracle Virtual Database Appliance. I can imagine the Oracle sales pitch now - "all the customer needs to do is install Oracle VDA on bare metal and then they can create databse instances EACH IN ITS OWN SANDBOX! Patch, update and restart all without impacting other database instances on the same Appliance!" The sandbox of course being a separate VM of Linux. Each time they want to create a new database instance they go to the GUI, simply slap in the IP address and volumes they want to use for the new instance and VirtualBox creates the new Linux VM and then the new database instance on top of it. Oracle DBAs would love it as they could say "no other database can do that", ignoring the fact other DBs don't come bundled with Linux and a hypervisor. It would allow an end run around Hyper-V and VMware and even gives the added bonus of cutting Red Hat out of the deal. And Oracle would love it as every instance would require a licence, and they could charge more than the combined cost of the Oracle DB LTU, the VirtualBox LTU and the Oracle EL LTU and it would still get bought. It might have an impact on Exadata sales but probably not too much as they could still claim the Exadata is tuned better out of the box. But, hopefully, they'll carry on with teh VirtualBox team butting their head against the VMware wall.

Re: Oracle got it all wrong with VirtualBox

Oracle didn't really set out to compete with other hypervisor vendors. VirtualBox came as part of the Sun acquisition. It was Sun that had some vague intention of competing in a few new areas (hence their acquisitions of VirtualBox and MySQL back in the day).