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 <[email protected]
<mailto:[email protected]>> wrote:
On Tue, May 10, 2011 at 3:34 PM, Ribhi Kamal <[email protected]
<mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
http://vbox.innotek.de/mailman/listinfo/vbox-dev
--
-- Ribhi
_______________________________________________
vbox-dev mailing list
[email protected]
http://vbox.innotek.de/mailman/listinfo/vbox-dev
