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
>