[vbox-dev] VBoxBFE or VirtualBox

[Klaus Espenlaub]

On 10.05.2011 18:03, Ribhi Kamal wrote:
> Thanks,
> 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 
question mark.

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"
>     issue?
>
>     "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),
>     etc...

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.

Klaus

>
>     --
>     -Alexey Eromenko "Technologov"
>
>     _______________________________________________
>     vbox-dev mailing list
>     vbox-dev at virtualbox.org <mailto:vbox-dev at virtualbox.org>
>     http://vbox.innotek.de/mailman/listinfo/vbox-dev
>
>
>
>
> --
> -- Ribhi