Reputation: 1763
I know that VB offers many things to control it : SDK, API, COM, web server etc
What I'd like to do is have a GUI to simply create VM connected through networks but I have to know: what is the best solution use Frontends [1], webserver, COM* or API ? elsewhere libvirt ?
A an example a use case could be : I put 3 VMs on my GUI, choose their respective OS , create 1 or more network connection(s) for each and connect these VM to create network(s).
Python, C++, etc, implementation language doesn't matter.
[1] http://www.virtualbox.org/manual/ch01.html#frontends
Upvotes: 4
Views: 522
Reputation: 33039
My qualifications for answering this being that I created and have maintained Vagrant since early 2010. Here are my general opinions of each of the available frontends for scripting VirtualBox:
vboxwebsrv
is the VirtualBox web service which provides an API to control VirtualBox. The pro of this is that web services are easy to program for nowadays. The main con is that you must handle startting and stopping this web service manually (or check to make sure it is already running). Historically, the web service has not been fully up-to-date with the latest APIs available in each version of VirtualBox, but I'm not sure what the status of that is today.
COM or C API
. VirtualBox provides an XPCOM based API on non-Windows platforms and an MSCOM based API on Windows. If you can't use C++, you can also use the C API on Linux (but it is not available/exported on Windows). I used this API for over a year. Pros: Fast and complete. Since it is a C API it is very fast, communicating with the VirtualBox process directly. It is also complete, since this is the same API that VirtualBox GUI is using as well as using internally. The main con is that XPCOM is not easy, and the C API is not available on Windows, meaning you either have to pain through XPCOM, or you need to handle both C and MSCOM. I chose the latter and it turned out to be a nightmare of compatibility. Almost every minor release of VirtualBox (3.1, 3.2, etc.) will change the API in a backwards incompatible way (slightly) and a major release and you can completely forget about (3.0, 4.0, etc.). This makes handling older versions of VirtualBox... tricky. This is definitely an advanced use case.
VBoxManage
is the CLI based frontend for VirtualBox. Under the covers VBoxManage
is of course just using the COM-based API, but provides a much more user-friendly cover on top of it. I've found that for 99% of use cases, VBoxManage can cover it. VBoxManage also handles all error handling, does proper exit status (0 for success, non-zero for everything else), etc. After 1.5 years of the C API I've switched back to VBoxManage because its simply easier to use and does what I need to do. The downside is you must use a subprocess to talk to VBoxManage. The upside is VBoxManage changes relatively infrequently, and as such it makes it very easy to support many versions of VirtualBox.
I hope this helps!
Upvotes: 4