Presently, the VirtualBox Web Console "server side" has to run on the same computer that is running the VirtualBox instance to be controlled. Even though VirtualBox comes with a remote capable Web Services (SOAP) API, only the local API is supported. Over time, this will change and we also envision managing multiple VirtualBox hosts from a single instance of the VirtualBox Web Console sometime in the future.
The server components are written in the Python programming language and make use of the VirtualBox Python API which is now part of the standard installation of VirtualBox (previously you had to get the VirtualBox SDK and manually setup the Python bindings). On top of Python we chose CherryPy as a very lightweight and powerful web server. The server side code contained in VBoxWebSrv.py talks to VirtualBox using its API and to web clients over HTTP. It's a very thin layer taking requests from the browser clients, validating them and then making the appropriate VirtualBox API calls. Data is transfered using the JSON standard which is easy to parse in an AJAX environment. The Python module also registers for all VirtualBox events (such as VM state changes) and collects the changes for the AJAX module to pick up.
As the Sun RDP Web Control (the Adobe Flash module that can display the VM screens) is not part of the project, the Python module attempts to download it at startup directly from the Sun download server. It is unpacked automatically and will only be downloaded again if an update is available.
The largest part of the code actually runs in the browser. We chose jQuery and jQuery UI as our main AJAX toolkits. The usual mix of HTML, CSS and JavaScript is used to display the interface. As we deal a lot with the VirtualBox data model (e.g. a VM and its properties), we decided to automatically generate JavaScript code that contains suitable objects. The generation happens based on the VirtualBox API description (a custom XML format) and in order to make things simpler, we decided to checkin both the generator and the generated code to avoid any kind of dependency on the VirtualBox SDK.
Good work guys and thanks for taking the time to document the choices you have made so far and why. I haven't used the web interface yet but am looking forward to being able to roll it out in the future for some of my clients that I admin VirtualBox install for.
ReplyDeleteYou guys are really going all out to make VirtualBox a VMware Workstation/Server killer. Previously if your server did not support svm/vmx extensions and you wanted to host VMs users could remotely configure via a web interface, without using a Windows license on the host but having the ability to manage Windows guests, VMware Server 2.0 on GNU/Linux was the best choice. Maybe not for much longer.
ReplyDeleteThis scenario is common for test labs when using old server hardware where testers only have MSDN licenses. Add in support for branched snapshots to your product and VirtualBox wins hands down.
Nothing short of outstanding! Having benchmarked and evaluated Virtualbox against VMware/KVM/XEN and Sun's own XVM server, simply put VirtualBox held it's own. It's nice to see that Sun Marketing finally recognized VirtualBox as a capable server class hypervisor as well. The addition of the VirtualBox Web Console now adds yet one more piece of functionality to make a great product even better ensuring it's foothold right up there with the competition.
ReplyDeleteVirtualBox Rocks! Keep up the great work VirtualBox Team.
Hi guys, thanks for the overview. Any idea what ports the flash component uses? I'm SSH tunneling post 8080 for remote access, but the Flash console portion doesn't come over.
ReplyDeleteIf I instead VNC into the hosting machine, the Flash component works flawlessly.
Thanks
Hi Taylor, the Flash client connects to the hosting machine to the VRDP port specified in the VM settings.
ReplyDeleteAnonymous,
ReplyDeleteThis is between the Flash component and the server, but over what port is the control exposed to the connecting client?
The Flash component (SWF file) is loaded by the client browser just like any other web content, that is using port 8080.
ReplyDeleteThen the Flash component establishes the connection from the client machine to the VRDP port.
So, if I'm tunneling ports over SSH for access (i.e. 10.10.0.1:8080 to local port 8080 - giving me access to the website via 127.0.0.1:8080), there's not a way to utilize the Flash console, because it's trying to forge a connection to 10.10.0.5:3390 (for example), which doesn't exist locally. Furthermore, there's no way to force it to check a different IP/port that could be also be tunneled over like the webpage, i.e. 10.10.0.5:3390 to 127.0.0.1:3390. Obviously, I can port-forward the RDP port and manually RDC in if necessary.
ReplyDeleteIs this all correct? If so, are any workarounds being considered to allow this type of setup, or anything else I'm missing?
That is correct.
ReplyDeleteBTW, in principle it is possible to implement a workaround, because the web frontend can specify, which ip:port the flash client should connect to.
We will see if/how this can be implemented.
cool
ReplyDeletesome of my friends that are in this particular field have told me about this The VirtualBox Web Console project, and they say that it is a good project and they will try to do something very similar
ReplyDeleteThis is a very helpful post, i hope this really helps me to complete my project.
ReplyDeleteI’ve been browsing on-line rather more than three hours these days, however I don’t ever found any appealing posting like your site. It’s fairly price sufficient for me. In my opinion, if most of website owners and folks produced nice content material materials as you do, the net will probably be much way more useful than ever before.
ReplyDeleteWow, nice post,there are many person searching about that now they will find enough resources by your post.Thank you for sharing to us.Please one more post about that..Reed
ReplyDelete