Headless back-end (Re: Notes on VirtualBox)

[jarod-ajLrJawYSntWk0Htik3J/w at public.gmane.org (Jarod Wilson)]

On Tue, Apr 20, 2010 at 3:51 PM, Rich Braun <richb-RBmg6HWzfGThzJAekONQAQ at public.gmane.org> wrote:
> Jarod Wilson <jarod-ajLrJawYSntWk0Htik3J/w at public.gmane.org> observed in response to the query:
>>> * Can one remotely manage a VirtualBox server?
>>
>> Sort of. But its really more geared towards desktop use, more similar
>> to vmware workstation than vmware server. You can of course ssh to
>> your server and use some of the included cli tools for management, or
>> run the management gui over ssh x11 forwarding.
>
> Well Chapter 7 of the VirtualBox User manual states the following about
> VBoxHeadless:
>
> "In particular, if you are running servers whose only purpose is to
> host VMs, and all your VMs are supposed to run remotely over VRDP, then
> it is pointless to have a graphical user interface on the server at all"

VRDP is for accessing the console of the virtual machine, a la remote
desktop (in fact, its an extension to microsoft's remote desktop
protocol). That's per-guest. And at the guest level, not at the
host-side VM management level. There's no "power on this guest" or
"add memory to this guest" its simply "here's the console of this
guest". Less than useful if you need to alter network interfaces,
disks, memory, cpus, etc. allocated to a guest. So you still need
their gui, or to ssh into the host and use vboxmanage to alter guest
bits.

> This chapter seems to describe a mechanism for turning a base Linux install
> onto an ESXi-like system, on which you'd put a lightweight 64-bit distro of
> your choice as the host and then use the VRDP management package to control
> one or more VM instances running on one ore more systems (perhaps a whole data
> center).

Haven't actually read it, but that chapter sounds misleading to me.

>> Last I knew, you can't have virtualbox auto-start VMs at boot time at
>> all, without the aid of a 3rd-party initscript/config file, which
>> doesn't integrate w/the management gui at all.
>
> This chapter of the manual conflicts with your statement here; probably this
> is new functionality since the last time you set up VirtualBox. ?The front-end
> for managing the VBoxHeadless servers is called VBoxManage.

Um. And what is starting up those guests on boot using VBoxManage?
(hint: you need the 3rd-party script I referred to, which I stumbled
back across -- its vboxcontrol).

> I haven't looked at the UI but the manual section 7.1.3 is a cookbook for
> scripting VM-instance creation and startup. ?Even if the GUI doesn't include
> auto-start, all you'd have to do is create a shell/perl script that brings up
> your VMs in whatever order you want.

...which is exactly what vboxcontrol is. Didn't you just contradict
yourself there?... :)

>> For server use like this, VMware is definitely still superior.
>
> Looks to me from this document (just download the 3.1.6 pdf from
> virtualbox.org) like Sun has gone balls-to-the-wall making this product better
> in the past couple of years. ?By comparison, VMware Inc. has been sitting on
> its laurels, presumably solving problems that I don't happen to have within my
> own data center.

VirtualBox has been improving by leaps and bounds, but its still way
behind for server use.

> VMware Inc's pricing strategy is so stratospheric that I'm going down the path
> of building these headless servers as soon as I can get some benchmarks run.
> I've been perpetually out of capacity on the several VMware servers I have at
> work; if we can actually go open-source, such limits will completely vanish.

Like I said before, I actually prefer to use kvm wherever I can over
either VMware or VirtualBox. VirtualBox is great for machines w/o
hardware virt or an operating system other than Linux, such as on my
Mac OS X laptop. But I have to maintain that VMware Server is,
unsurprisingly given its name, better for server use than VirtualBox.
Its got more flexible management tools than kvm too, but kvm at least
has startup integration and management tools designed to be run
remotely (virsh and virt-manager, primarily written and maintained by
some of my co-workers).

-- 
Jarod Wilson
jarod-ajLrJawYSntWk0Htik3J/w at public.gmane.org