Virtualbox Networking Scripting

Question

I know that VB offers a lot of things to manage it: SDK, API, COM, web server, etc.

What I would like to do is to have a graphical interface to just create a virtual machine connected through the network, but I must know: which solution is best to use Frontends [1], webserver, COM * or API? elsewhere libvirt?

As an example, you can use: I put 3 virtual machines in my GUI, select their corresponding OS, create 1 or more network connections for each and connect these virtual machines to create networks.

Python, C ++, etc., the implementation language does not matter.

[1] http://www.virtualbox.org/manual/ch01.html#frontends

Answer 1

My qualifications for responding to this creature that I created and supported Vagrant since the beginning of 2010. Here are my general opinions on each of the available VirtualBox scripting interfaces:

• vboxwebsrv is a VirtualBox web service that provides an API for managing VirtualBox. About this is that web services are easy to program today. The main thing is that you must manually start and stop this web service (or check that it is already running). Historically, the web service has not been fully updated with the latest APIs available in each version of VirtualBox, but I'm not sure what this status 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 cannot use C ++, you can also use the C API on Linux (but it is not available / not exported to Windows). I have been using this API for over a year now. Pros: Fast and full. Since this is a C API, it is very fast, directly related to the VirtualBox process. It is also complete, as it is the same API as the VirtualBox GUI, as well as internally used. The main problem is that XPCOM is not easy, and the C API is not available on Windows, which means that you have to either get sick through XPCOM or you need to handle both C and MSCOM. I chose the latter, and it turned out to be a compatibility nightmare. Almost every minor release of VirtualBox (3.1, 3.2, etc.) changes the API in the backward incompatible form (a bit) and the large release, and you can completely forget about (3.0, 4.0, etc.). This simplifies the handling of older versions of VirtualBox .... This is definitely an extended use case.

• VBoxManage is a CLI-based interface for VirtualBox. Under the covers, VBoxManage , of course, just uses the COM-based API, but it provides a much more user-friendly cover. I found that for 99% of the uses of VBoxManage can cover it. VBoxManage also handles all error handling, does the correct exit status (0 for success, nonzero for everything else), etc. After 1.5 years of API C, I switched to VBoxManage because it is just easier to use and does what I need to do. The downside is that you have to use a subprocess to communicate with VBoxManage. The top of VBoxManage changes relatively rarely, and therefore it greatly simplifies support for many versions of VirtualBox.

Hope this helps!