Hi Funs, Responses inline...
> -----Original Message----- > From: Funs Kessen [mailto:f...@barred.org] > Sent: 25 April 2014 14:03 > To: dev@cloudstack.apache.org > 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 http://docs.cloudstack.apache.org/projects/cloudstack-installation/en/latest/qig.html#management-server-installation 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.
