incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frank Zhang <Frank.Zh...@citrix.com>
Subject RE: OVM 3.2.1 support in Cloudstack
Date Tue, 19 Feb 2013 19:33:06 GMT
Hi Funs:
	I think you are approaching the right way for OVM3 integration, the right way I mean is
using OVM3 hypervisor API.

	Though I didn't see the API yet(the time I checked Oracle document it said not ready),
from your description I feel Oracle indeed provides a way not messing with Oracle VM manager
which is preferred by IaaS software.

	The problem of Oracle VM manager (the same problem for other hypervisors which force
thirdparty  software to use its API middleware) is it introduces duplicated concepts that
IaaS already
has. For example, many XYZ manager has concept of cluster. Then IaaS software has to
write many glue code to make its own concept matching XYZ manager's that is quite ugly. 
and sometimes, it lacks some fundamental capability that IaaS needs, for example, 
OVM2.x manager API doesn't have vlan related API. this is the reason that KVM is most preferred
by
IaaS developer, though libvirt also introduces some concepts you are free to drop them. so
I strongly
suggest directly communicating with hypervisor itself as much as possible.

	As you have mentioned OVM3 has storage API, I would suggest also checking its network API
that is the same important as storage. However I am not worry about that much, as you have
said Oracle
supported plugin to its ovs-agent, we can do our own extension if its network API is not rich(e.g
lacking vlan
support). This also makes CloudStack security group gracefully possible for OVM.
 

> -----Original Message-----
> From: Funs Kessen [mailto:FKessen@schubergphilis.com]
> Sent: Tuesday, February 19, 2013 2:31 AM
> To: Ove Ewerlid; cloudstack-dev@incubator.apache.org
> Subject: RE: OVM 3.2.1 support in Cloudstack
> 
> Hi Ove,
> 
> Thanks for your thoughts.
> 
> I totally agree that using standardized APIs has a strong preference, and is
> the way to go. What you rightfully pointed out is the significant difference
> between OVM 2.x and 3.x in the ovs-agent, I already bumped into that one
> and indeed found out that figuring out what goes wrong where is a bit hairy if
> you're not familiar with the code or the concepts. So option B is for sure the
> one that I would prefer, and I gather from your reflections you do too.
> 
> My apologies for not elaborating initially. With "along the lines of 2.x" I meant
> leveraging the separate OVM 3.x Hypervisor  APIs, which seems supported
> by Oracle looking at the documentation, instead of using Oracle VM Manager
> in a vCenter style. Also being able to extend the ovs-agent where required to
> expose specific functionality if required, but rather not touching it if not
> required. Oracle supports plugins for the ovs-agent/API, an example of this is
> the Netapp plugin that is due somewhere Q2/Q3 in 2013, so there are
> possibilities there if need be.
> 
> ACS4.2 and the storage refactor is something that impacts multiple facets,
> and not only OVM 3.2.1 integration (wild speculation here though). I trust
> that the people that commit the code, when and if done, and use the code
> for OVM will also maintain that code, myself and the company I work for will
> be one of them. Looking at the automated testing we do here on 4.1 for
> example will also force the fixes and functionality.
> 
> At the moment we're also actively connecting with Oracle, so I trust we will
> get some more insight in what the OVM product development team thinks.
> 
> Cheers,
> 
> Funs
> 
> > On 02/18/2013 03:36 PM, Funs Kessen wrote:
> > > Hi There,
> > >
> > > At the moment I'm diving into OVM 3.2.1 Support in Cloudstack. I've
> > noticed that only 2.3 support is in there now and found some earlier
> > mails (June 2012) from people who were looking into getting 3.x
> > support in. There are several paths that could be taken with the
> > integration, my initial thoughts are to move along the lines the 2.3
> implementation followed.
> > >
> > > My question is if anyone else is thinking about this or working on
> > > this and
> > if  so, if it would be useful to collaborate on this?
> > >
> > > Cheers,
> > >
> > > Funs
> > >
> >
> > Some technical reflections on this topic;
> >
> > The OVM 2.x approach is about a significant update to the python agent
> > code in the OVM 2.x hypervisor. The state of the OVM 2.x API
> > presumably prompted the folks doing the OVM 2.x port to follow this
> > approach (there were no other path ...). In OVM 3.2.1 the API has
> > progressed further, there is a CLI type API on top off SSH and there
> > is a Java SDK
> > (REST/SOAP) and there is the OVM3 ovm_shell (jython) (this is not an
> > API, but means to control OVM3 using python code (v2.4)).
> >
> > CloudStack too has come a long way and the storage re-factor coming in
> > ACS4.2 adds important elements to orchestrate OVM 3.2.1 given how OVM
> > 3.2.1 handles storage and what means OVM 3.2.1 expose for external
> > control.
> >
> > The OVM 2.x approach would also modify OVM 3.2.1 hypervisor
> > implementation to a degree where issues can be difficult to
> > distinguish from OVM 3.2.1 itself vs the changes in the python agent
> > to facilitate
> > ACS4 integration.
> >
> > The python implementation of the OVM 3.2.1 agent is significantly
> > different from OVM 2.x so reuse there is unlikely, one reason is that
> > the XML RPC is more abstracted in OVM 3.2.1, a step in the right
> > direction (my subjective observation).
> >
> > There is a storage plugin architecture in OVM3, although today
> > primarily geared towards NFS/iSCSI services, this may be possible to
> > use to avoid diving into low level changes of the OVM3 hypervisor
> > agent to interface with ACS (and leverage "cloud" storage).
> >
> > In short, today there may be means to integrate  ACS4<->OVM3 that
> > avoids digging in to the python agent code in DOM0. Down the road the
> > ACS4 storage refactor today slated for ACS42 is also a factor.
> >
> > What pros and cons do you see with the two main approaches, A)
> > changing the agent on the hypervisor vs B) using the officially
> > published API's made available via OVM3 manager?
> >
> > /Ove
> >
> > NB; I'm not associated with the OVM3 product development, just a user
> > of the OVM3 product.
> >
> >
> >
> >
> > --
> > Ove Everlid
> > System Administrator / Architect / SDN & Linux hacker
> > Mobile: +46706662363
> > Office: +4618656913 (note EMEA Time Zone)

Mime
View raw message