Hi There, Well to be honest this is something on my, ever expanding, shortlist.
There are a couple of "interesting" challenges here. The first and foremost is that an integration with OVM 3.2.X is different than 2.x. As Oracle decided to rewrite the entire API layer which renders the Cloudstack scripts that are injected in 2.x useless. My approach has been to write an API introspection script to extend the API (which is functional in my dev env) to be able to figure out which calls are valid to OVM with which they leverage xl (as it's simply xen with a 64bit redhat on top which uses xl as the toolstack underneath with a different API bolted on top of it which does some added "magic" with storage, NICs and copying of data). Besides this I've also added some bits to see what OEM (Oracle Enterprise Manager) literally does underneath to better understand how OEM sees the world, and to figure out a way not to deviate too much, but also not to fall into the same pitfalls and keep the thoughts in line with the way Cloudstack sees the world. Then there is the question of leveraging OEM, like they've sort of designed it opposed to leveraging the individual OVMs. The individual OVMs is the route I chose as OEM made me very unhappy with regard to implementation and quality of abstraction and integration with other bits and pieces. An example of the abstraction is that we have certain requirements (as SBP) from our hypervisors, and OVM comes with some of these parts, which we could potentially leverage, but not via OEM (OpenVswitch par example, which is not the default but you "could" use it). At this moment I'm at the point of having to provisioning all the bits separately with API calls so I understand how Oracle does their thing, as a certain order is crucial for the way things are done in OVM to be able to get a hypervisor "functional". I've naturally sniffed these bits and figure out the correct path of creation, and they're quite fairly reasonable in line to what one would expect a hypervisor to require except for some odd bits and bobs, but nothing major I've seen yet. This is where I am personally at the moment. The idea is to extend the API where required, but initially trying to keep everything as OVM native as possible, this makes upgrading a bit easier for people. In the end this will mean that we'll have to mimic certain bits here and there in Cloudstack with regard to the upgrading of the API, which OVM looks for at its management server, or the callback that's in there. All the bits that I extend I would love to give back to Oracle, so they can make life easier for other people trying to port things into, or onto their API :). Cheers, Funs -----Original Message----- From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] Sent: woensdag 3 juli 2013 17:04 To: dev@cloudstack.apache.org Subject: Re: Oracle VM Integration with CloudStack I'm curious, Chip, about what you said regarding OVM not currently being supported. In a production deployment, does OVM not show up as a hypervisor type (I assume I see it because I'm running a development build or something)? Thanks! On Wed, Jul 3, 2013 at 8:44 AM, Alexandre Sousa <alexandre.so...@oracle.com>wrote: > Hi Guys, > > I'm very interested on the integration of CloudStack with Oracle VM > 3.x or Oracle Enterprise Manager 12c. > > In the document Apache_CloudStack-4.1.0-Release_Notes-en-US-3.pdf I > didn't found Oracle VM 3.x on the list of the supported hypervisors > but I found a reference of a fix "CLOUDSTACK-368 OVM - cannot create > guest VM", so... The integration is possible? > > Cheers, > Alex > -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play> *(tm)*
