Hi Keith, * Keith Mitchell (Keith.Mitchell at Sun.COM) wrote: > Forwarding out this message to caiman-discuss. > > Glenn Lagasse wrote: >> Hi Keith, >> >> So, let me just start out by saying this is Great! Thank you for >> looking into this and double kudos for getting this done so quickly. >> It is all useful information and answers a big question we had in terms >> of how to interface with VB. >> >> * Keith Mitchell (Keith.Mitchell at Sun.COM) wrote: >> >>> I have been looking into the options available for accessing VB via a >>> "stable" API as opposed to a command line interface. There are a >>> surprising number of options, which gives us a good chance of finding >>> one that works well with what we want to do. Let me start by >>> describing the API "structure" as I understand it after reading the >>> VB technical docs. >>> >>> The VirtualBox program can only be directly contacted via a COM >>> (Windows) or XPCOM (non-Windows) API. This is the API that the >>> VirtualBox GUI uses, for example. >>> >>> VirtualBox provides a web server that sets-up a web service providing >>> access to most (not all) functions available via COM/XPCOM. This web >>> service can be accessed (locally or remotely) through any >>> programming language that has the ability to interact via HTTP / >>> SOAP. >>> >>> VirtualBox also provides an object-oriented backbone for talking to >>> the web server in both Java and Python flavors. >>> >>> The Python set-up can also speak directly to the COM/XPCOM API if the >>> connections are configured that way. >>> >>> And finally, the existing CLI for talking to virtual box makes use of >>> Python via COM/XPCOM. >>> >>> I went through the documentation and examined as many of the methods >>> that might be needed/desired as I could. From what I saw, everything >>> we need is accessible through the web server - no necessary >>> functionality requires use of the COM/XPCOM interface. >>> >>> The SDK for VB includes code for the Java and Python web services; it >>> also includes sample Perl (which I did not look into). The Python >>> code requires Python 2.5 or higher. >>> >>> Comparing the COM/XPCOM to the web service: >>> Web service can be accessed remotely >>> Web service can be accessed by any programming language capable of >>> making basic web service calls >>> COM/XPCOM is faster compared to web service calls. >>> COM/XPCOM has access to a wider array of functionality. >>> >>> In terms of functionality, everything we need should be available, >>> including: >>> Creating and naming a new VM >>> Setting the OS type, RAM, Video Ram, and 3D acceleration states of the VM >>> Creating and attaching a virtual hard disk to the VM >>> Gaining handles on the VMs CD, DVD, Floppy, USB and network devices >>> Powering up, sending a power down signal, and "forcibly" powering >>> down the VM >>> Mount and unmounting CD/DVD/floppy images >>> Exporting the VM to an OVF file >>> Importing an OVF file to a VM (would be useful to provide a finalizer >>> of some kind that can be bundled with the exported OVF; the user >>> could then import the OVF file into their VB set-up without manually >>> running VB and importing the file) >>> Access to and information about the host machine, including installed >>> RAM, available RAM, OS type, and access to CD/DVD/USB/floppy devices >>> as well as the network interfaces (this may be useful for "sanity >>> checks" ensuring that the machine running the VM constructor - or >>> receiving the VM image - has sufficient memory and disk space >>> available). >>> >> >> >>> I have some additional thoughts that came to mind while looking into >>> this as well. >>> >>> The web service method requires authenticating a user before allowing >>> access. This can be disabled - though that of course could mean a >>> malicious user could gain access to the web service remotely. >>> >> >> I'm not terribly inclined to use the web service. Mostly because I >> don't think it provides us any capabilities that we need over what the >> XPCOM interface gives. Not to mention that the XPCOM interface is >> faster, allows access to more functionality, is extensively used already >> in the VB CLI tools and fits in with what we're likely to be writing the >> implementation in (Python). But, let's keep it in mind. >> >> > After playing around with the webservice a bit, I definitely agree. >>> Depending on implementation, the VM constructor could theoretically >>> run from a non-OpenSolaris environment (e.g. Windows) - or at least, >>> require minimal changes for users so inclined. >>> >> >> The VM constructor is merely a part of the Distro Constructor. So, we'd >> have to port DC to Windows which other than the previously talked about >> 'Web Factory' I don't think we're likely to do. >> > Ok, this makes sense now. I had it in my head that the .iso supplied was > always external, but of course making the image via DC and loading it > into the VM all at once is the more logical method.
Agreed. We will however allow the deployer to supply a pre-constructed bootable AI iso if they'd rather not build one from scratch. >> >>> Is there any reason we can't use the guest's virtual network adapter >>> to communicate with the install process? This of course requires the >>> install process to either monitor the network or send signals out >>> along the network. I'm not yet familiar enough with AI to know if it >>> already does this yet or not. >>> >> >> No reason I can think of. The issue becomes what does AI provide in >> terms of observability. Right now, I don't know if it provides anything >> client side. But for the bootable AI ISO we should come up with some >> requirements for observability and get something implemented that the VM >> construction project could then utilize. >> > I didn't get deep enough into it, but there are some API hooks for > determining system state that we may be able to use as well. The ideal > solution is active feedback from the AI ISO, but alternatively or > supplementally we could make use of those. These hooks are not exposed > to the web service, so all the more reason to push for XPCOM. Yep. I know that the CLI allows you to determine the 'state' of the VM such as 'shutdown', 'starting', etc. But it's pretty rudimentary. In order to get any meaningful status of what's going on inside the VM we'll need the bootable AI iso to provide observability mechanism that we can hook into. Cheers, -- Glenn
