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)
