OVM3.0 integration

[Frank Zhang <Fr...@citrix.com>]

Recently I received lots of ping from people who want CloudStack integrates with OVM3.0.
CloudStack has supported Ovm2.3 in current code base, however, Ovm3 is generally treated as a more stable, enterprise-ready Oracle server virtualization solution, so I was thinking of making it work in CloudStack for a while.
However, I still have some concerns:
1. It will refactor whole OVM integration code in CloudStack. In terms of Ovm2.3, CloudStack extends ovs-agent running on OVM server to interpret commands from CloudStack management server, this bypasses the Oracle VM manager which provides web API with a java library. I made this decision based on my experience with Ovm2.3 manager, I felt it's not stable and the API it provides was not comprehensive to fulfill our requirements.  As Ovm2.3 allows directly talking to ovs-agent thru XML-RPC, extending its agent came to be the easiest and reliable way to me. 
     The story looks changed in OVM3. Oracle claims they rebuild the whole tool stack which makes me think using its SDK is the right way to go. The most attractive thing in Oracle claim is they said its manager built on Oracle J2EE server was capable of cancelling long run task anytime. As I also work at this area, I understand how much effort must be paid to implement this seemingly simple feature in terms of data integrity.  This convinced me that OVM3 manager has fair quality, it might be worth doing big refactor in line with OVM3.
     However, I didn't see its SDK yet, I was told its SDK was still in progress last time I visited Oracle forum. Any people on list has some fact of it? Or any people has experience of OVM3 and what your thoughts about it?

2. Even we go with OVM3 SDK, there is still some hacking having to be made on host. CloudStack has its own command hierarchy, some commands can match to hypervisor's API/SDK, while some cannot. For example, downloading template from secondary storage, checking primary storage statistics. Some hypervisor, like Xenserver, provides a command channel that you can plug your backend in the host. I don't know if OVM3 has similar thing as I haven't seen its SDK. If not, our solution comes to be a mixture of SDK and hand craft agent, which is viable but not perfect to me. Any people has thoughts here? 

And any thoughts and questions are welcome. I want to use this thread to discuss OVM solution in ASF CloudStack. Thank you
	

Re: OVM3.0 integration

[Chiradeep Vittal <Ch...@citrix.com>]

Frank, I didn't see any feedback on this. It seems to me from your
proposal that Ovm2.3 is still preferable?

On 6/21/12 11:28 PM, "Frank Zhang" <Fr...@citrix.com> wrote:

>Recently I received lots of ping from people who want CloudStack
>integrates with OVM3.0.
>CloudStack has supported Ovm2.3 in current code base, however, Ovm3 is
>generally treated as a more stable, enterprise-ready Oracle server
>virtualization solution, so I was thinking of making it work in
>CloudStack for a while.
>However, I still have some concerns:
>1. It will refactor whole OVM integration code in CloudStack. In terms of
>Ovm2.3, CloudStack extends ovs-agent running on OVM server to interpret
>commands from CloudStack management server, this bypasses the Oracle VM
>manager which provides web API with a java library. I made this decision
>based on my experience with Ovm2.3 manager, I felt it's not stable and
>the API it provides was not comprehensive to fulfill our requirements.
>As Ovm2.3 allows directly talking to ovs-agent thru XML-RPC, extending
>its agent came to be the easiest and reliable way to me.
>     The story looks changed in OVM3. Oracle claims they rebuild the
>whole tool stack which makes me think using its SDK is the right way to
>go. The most attractive thing in Oracle claim is they said its manager
>built on Oracle J2EE server was capable of cancelling long run task
>anytime. As I also work at this area, I understand how much effort must
>be paid to implement this seemingly simple feature in terms of data
>integrity.  This convinced me that OVM3 manager has fair quality, it
>might be worth doing big refactor in line with OVM3.
>     However, I didn't see its SDK yet, I was told its SDK was still in
>progress last time I visited Oracle forum. Any people on list has some
>fact of it? Or any people has experience of OVM3 and what your thoughts
>about it?
>
>2. Even we go with OVM3 SDK, there is still some hacking having to be
>made on host. CloudStack has its own command hierarchy, some commands can
>match to hypervisor's API/SDK, while some cannot. For example,
>downloading template from secondary storage, checking primary storage
>statistics. Some hypervisor, like Xenserver, provides a command channel
>that you can plug your backend in the host. I don't know if OVM3 has
>similar thing as I haven't seen its SDK. If not, our solution comes to be
>a mixture of SDK and hand craft agent, which is viable but not perfect to
>me. Any people has thoughts here?
>
>And any thoughts and questions are welcome. I want to use this thread to
>discuss OVM solution in ASF CloudStack. Thank you
>