Client/Server Frontend

[bundabrg]

Hopefully an easy question to answer.

I'm currently coding a Client/Server type frontend for VirtualBox. It currently runs under Windows, Mac and Linux. I mainly started it so that I can run a GUI "frontend" on a remote machine (of whatever OS, doesn't matter) that connects and can perform all the operations you can normally do in the normal VirtualBox frontend. I'm also making it pluggable so it supports other VM's than just VirtualBox (though I'm developing it primary for use with VB for now)

I've reached the point where I've finished most of the graphical side, the wizards, and settings, and I'm just about to start writing the client/server communication component.
Essentially the client looks similar to the VirtualBox frontend, except at the top there is a field to enter a server name to connect to. This makes an encrypted connection to the server daemon. I decided on this approach rather than ssh+execute commands remotely as there are additional things I want the remote to do (such as monitor and restart VMs, configure host network, etc etc). Also allows me to add on an Enterprise addon that monitors lots of different servers.

My original intention is to have the Server side accept data from the client, then "translate" this into calls to a helper program, most likely VBoxManage. IE, if in the client I create a new VM, the remote would create the VM, create the disks, and set it all up, even uploading a disk image if necessary. The advantage of this is its easy to plug in another VM. For instance, a KVM/KQEMU could run the equivalent commands.

My question is, would it be better to do it this way, by calling a helper program, or would it be better for the Server component to create a direct interface to VirtualBox through its API (which I've not yet been able to find, not that I've looked hard yet) and manage the VM's there?

I suppose ideally I'd also like to be able to access the remote VM's "screens" through the client (ie, click the vm, and its screen appears next to it), though its not quite as necessary for my needs. _This_ would require the Server side run a custom designed "frontend" that possibly exposes the screen to a virtual framebuffer (ie VNC).


- Brendan

[TerryE]

Brendan, the easiest way to do this is to use the SDK. If you want the API to transport over the network then you can use the SOAP service provider that is already coded up in the vboxwebserv executable which you just run as a daemon on you server. You can hand crank the client side in C++, Java, Perl or Python. Alternatively is you want to run this as a web GUI console under Apache then the easiest scripting language to use is Python and here you want to use XPCOM. If you want to understand the API sequences just download the OSE source and look at the code in the src/VBox/Frontends/VBoxManage directory (or you can browse this in svn). It's really quite easy to retro-engineer the API sequences since the VBox code also calls the API using XPCOM.

PS. How are the shitty nappies going

[bundabrg]

Thanks, I'll take a look at it. I'm writing in Python with wxPython to ensure its OS agnostic. Python also means its extremely easy to plug in other bits (I use a method of programming I generally use that I call "bubble programming" where the ENTIRE program is basically built up of plugins built on a reasonably flexible plugin api)

I'm thinking that I won't communicate directly with VirtualBox SVC from a remote side, but rather communicate with my own server process, which in turn communicates maybe directly with VirtualBox through the API rather than through Helper programs (and thus I can more likely get the framebuffer somehow). That way I can wrap my own stuff in, like setting a VM to use up % host mem, and wrapping a running VM in a script to restart it on failure (etc etc). Also, on the Client side, when I'm creating the VM, and I browse for "existing local hdd image", the client will upload the image to the server side as part of the process. This means it should work the same whether the client and server are on the same machine (so runs very similar to Virtualbox GUI), or if the server is remote.

One of the main reasons I did this was so I can control the Host from inside a running VM. IE, if I NX to a Linux Guest, or RDP to a windows guest I can execute the Client and add/delete/start/stop vms running on the host (who is itself will likely run my HostOS and thus really has no need for a console). I'll put all this stuff up somewhere when I get it running ok and have it to the point that anyone else can replicate my work (IE, a command to build a HostOS system, etc). JeOS as a guest looks interesting as well and I'll likely put in something that allows one to remotely 'bootstrap' a JeOS client from scratch.

As an aside, I must say I'm impressed by the fact KVM now allows you to change a running VM's allocated memory on the fly. I'm not really sure how the hell it manages that.. I'll definitely be adding it (or inviting someone whos more KVM savvy to write it) as a plugin once I'm done with the VB one since it has other neat options like migrating a running VM from one host to another (and with a Client/Server approach like I'm doing this would be easy to implement in the client as a GUI option... IE "Migrate to Host 'blah2'").

As far as the nappies, I think baby nappies are fine (apart from the first one . They don't smell and are easy to clean. Toddler nappies on the other hand...

- Brendan