You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Funs Kessen <FK...@schubergphilis.com> on 2013/02/18 15:36:35 UTC
OVM 3.2.1 support in Cloudstack
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
Re: OVM 3.2.1 support in Cloudstack
Posted by Chip Childers <ch...@sungard.com>.
On Tue, Feb 19, 2013 at 11:40:06AM -0800, Frank Zhang wrote:
> > >
> > > 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
> >
> > AFAIK, nobody has stepped up to "fix" OVM support in CloudStack yet..
> > and if you're willing to work on it great!
> >
> > Frank (cc'ed) had mentioned that he was working on it for CloudPlatform [1].
> > If that's the case, he may have working code... but it would have to be
> > donated to Apache for it to be included. I'm also not sure what version of
> > OVM he was working to enable.
> >
> > Frank - Can you comment, so that Funs is able to figure out where things
> > stand? Want to collaborate with him on an Apache re-implementation?
> >
> > -chip
>
> The main reason OVM not working in ACS is about license.
> I have multiple important patches to OVM agent which is LGPL licensed.
> Another reason is OVM2.3 is too old, it's Domain0 kernel is 2.6.18 which is approximately
> 6 years old that cannot work properly on recent hardware(the main issue we faced is
> vconfig doesn't support some networkcard).
>
> Given community is starting some effort on OVM3, I would suggest focusing
> on OVM3 rather than bring OVM2 back
>
>
Makes perfect sense to me!
-chip
RE: OVM 3.2.1 support in Cloudstack
Posted by Frank Zhang <Fr...@citrix.com>.
> >
> > 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
>
> AFAIK, nobody has stepped up to "fix" OVM support in CloudStack yet..
> and if you're willing to work on it great!
>
> Frank (cc'ed) had mentioned that he was working on it for CloudPlatform [1].
> If that's the case, he may have working code... but it would have to be
> donated to Apache for it to be included. I'm also not sure what version of
> OVM he was working to enable.
>
> Frank - Can you comment, so that Funs is able to figure out where things
> stand? Want to collaborate with him on an Apache re-implementation?
>
> -chip
The main reason OVM not working in ACS is about license.
I have multiple important patches to OVM agent which is LGPL licensed.
Another reason is OVM2.3 is too old, it's Domain0 kernel is 2.6.18 which is approximately
6 years old that cannot work properly on recent hardware(the main issue we faced is
vconfig doesn't support some networkcard).
Given community is starting some effort on OVM3, I would suggest focusing
on OVM3 rather than bring OVM2 back
Re: OVM 3.2.1 support in Cloudstack
Posted by Chip Childers <ch...@sungard.com>.
On Mon, Feb 18, 2013 at 02:36:35PM +0000, 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
AFAIK, nobody has stepped up to "fix" OVM support in CloudStack yet..
and if you're willing to work on it great!
Frank (cc'ed) had mentioned that he was working on it for CloudPlatform
[1]. If that's the case, he may have working code... but it would have
to be donated to Apache for it to be included. I'm also not sure what
version of OVM he was working to enable.
Frank - Can you comment, so that Funs is able to figure out where things
stand? Want to collaborate with him on an Apache re-implementation?
-chip
RE: OVM 3.2.1 support in Cloudstack
Posted by Frank Zhang <Fr...@citrix.com>.
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)
RE: OVM 3.2.1 support in Cloudstack
Posted by Funs Kessen <FK...@schubergphilis.com>.
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)
Re: OVM 3.2.1 support in Cloudstack
Posted by Ove Ewerlid <Ov...@oracle.com>.
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)