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.
>
>> 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.
>
>> Final question: Should I be sending this email to caiman-discuss? I'm
>> still not certain on what I should be putting out there and what should
>> remain internal.
>>
>
> Yes. For something like this that is related to the project but doesn't
> contain anything confidential should go to the list.
>
Good to know - sending this out then :)
> Of course, it doesn't hurt to ask if you're unsure :-)
>
> Cheers,
>
>
