[vbox-dev] VBoxBFE or VirtualBox
klaus.espenlaub at oracle.com
Tue May 10 11:46:03 PDT 2011
On 10.05.2011 18:03, Ribhi Kamal wrote:
> I think that in my case I will have two binaries and each is responsible
> of starting a specific type of virtual machine. Everything will be hard
> coded, the network interfaces, the ISO location, guest controllers... etc
In such a case VBoxBFE might be a reasonable starting point. With a big
Without the COM API you have to implement many features yourselves.
VBoxBFE doesn't support snapshots and other slightly more complicated
features. Also, since it's been unmaintained for many years it's way
beyond the feature support of the other VM frontends (different storage
controller support, multiple DVD drives, network boot, bridged
networking, different network card models, leave alone dynamic
configuration changes at VM runtime). All implementable, but LOTS of
work and once you're done you probably introduced something which is
worse than (XP)COM.
Additionally it's non-trivial to replace libSDL with something else.
> I'm worried about starting two virtual machines at the same time, is
> there going to be some conflicts when calling the kernel driver
> (vboxdrv) ? I guess my question is, is there some danger from starting
> two VMs using VBoxBFE (without COM)?
No. The kernel driver has all necessary synchronization. In a normal
multi-user setup there is also no coordination between different VBoxSVC
instances (which only care about one user).
> Finally, does anyone know if Oracle has something similar to what I'm
> doing -- No COM/XML? Money is not a problem (not yet anyway).
No customer has asked for no management so far if my memory doesn't fool
me. Generally they want more, preferably impossible management conditions :)
> Thanks again
> On Tue, May 10, 2011 at 9:10 AM, Alexey Eromenko <al4321 at gmail.com
> <mailto:al4321 at gmail.com>> wrote:
> On Tue, May 10, 2011 at 3:34 PM, Ribhi Kamal <rbhkamal at gmail.com
> <mailto:rbhkamal at gmail.com>> wrote:
> > The problem with COM (XPCOM too?) is that its very hard to lock down.
> > Especially when %50+ of people run everything with admin privs.
> So I'm
Well, if you have so many people running things as admin then I would
think VirtualBox is the least of your worries. I would consider it the
primary goal to get people off the admin account, and use their own.
Which would probably solve most of the lock down problems already.
> > trying to reduce the attack vectors that can be done from the
> host OS on the
> > virtualvbox installation it self.
> > Can you please explain a bit about the "VM synchronization point"
> "VM synchronization point" is a single host management layer.
The host part is done in the driver.
VBoxSVC only cares about a single user.
> The biggest difference between Qemu and VirtualBox engines, from
> programmer's point of view, is that if you write any program for Qemu,
> you must reimplement management layer yourself.
That's correct again.
> VirtualBox already provides single-host management layer (via
> VBoxSVC). Registered VMs. Each VM remembers it's parameters, such as
> RAM, HDDs assigned, Network adapters (along with MAC addresses),
Right. VirtualBox has so many options these days that it's simply not
efficient to use a command-line based approach.
The (XP)COM based API serves as a big sanity checker and reduces many
error sources with creating and running VMs.
> -Alexey Eromenko "Technologov"
> vbox-dev mailing list
> vbox-dev at virtualbox.org <mailto:vbox-dev at virtualbox.org>
> -- Ribhi
More information about the vbox-dev