cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ove Ewerlid <>
Subject Re: OVM 3.2.1 support in Cloudstack
Date Mon, 18 Feb 2013 16:18:21 GMT
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?


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)

View raw message