cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donal Lafferty <>
Subject RE: Oracle VM (OVM) Server support
Date Sun, 27 Apr 2014 21:56:50 GMT
Hi Funs,

Responses inline...

> -----Original Message-----
> From: Funs Kessen []
> Sent: 25 April 2014 14:03
> To:
> Subject: Re: Oracle VM (OVM) Server support
> Hi Donal,
> Thanks for your thoughts, I've replied inline.
> On Thu, Apr 24, 2014 at 09:32:36PM +0000, Donal Lafferty wrote:
> > Start with something stable, yet recent, e.g. 4.3  and not Master... 
> >
> Sounds sensible! I'll stay on 4.4 for now and will try to follow that first.
> I did however get frightened a bit by the speed things move at, so was
> thinking it would be good to keep up a bit and make sure that the code
> would work with 4.5.
> > WRT system VMs, it sounds like you can run the existing Xen system VMs
> as is provided the template is converted to RAW.  Since you're using NFS,
> you'll have to seed the system templates, which suggests that the
> conversion is in the bash script that sets up the system VMs.  Is that correct?
> >
> It's not in the bash script now, but I can put it in fairly straightforward, for
> now I have a raw image just like there is a vpc, qcow2 etc image. But I could
> indeed just convert it on the fly.

IMHO, you want to avoid introducing manual steps.  If seeding system VM templates is already
automated, then it should be quite easy to hang your system VM setup off that.  See
for a reference to the script.

> > But... can you control OVM with libvirt?  If so, could you simply
> > reuse the KVM agent instead of writing your own?  It's a lot easier to
> > reuse than write from scratch :)
> >
> I'm sure you could to a certain failry limited extent, but with some bits really
> missing as they are not in the dom0 provided for OVM. Which you could in
> theory push in if you really wanted to.
> A reason I didn't go down that route is that I don't want to modify dom0, in
> the end to avoid a support discussion if it would come to that and be able to
> say that it's a completely stock OVM that is just centrally managed. Hence an
> as native as possible implementation.

IIRC, CloudStack modifies the Dom0 of every hypervisor it directly controls.  XenServer has
a plugin model that installs custom instructions, KVM has an agent, Hyper-V has an agent,
and VMWare isn't directly controlled.  You can double check with someone like Tim Mackey.

A plugin model or full blown agent is used to gain access libraries outside the scope of Hypervisor
control.  For example, the hyper-v agent gives you easy access to the file system APIs for
mounting primary / secondary storage and copying between the two.  IIRC, XenServer allows
scripts to be installed that can be accessed from XAPI.  Not sure how KVM does it.

Does the OVM API have an extensibility model like XenServer?  Ideally, you'd want to use it
to inject existing code either from the XenServer scripts or whatever KVM is using.  That
narrows the coding effort to the OVM hypervisor stack.

View raw message