[openstack-dev] [Nova] virt driver architecture

Russell Bryant rbryant at redhat.com
Fri May 10 15:20:42 UTC 2013


On 05/10/2013 10:55 AM, Armando Migliaccio wrote:
> I also think that cells, as a concept for allowing more complex systems
> like vCenter to tap into Nova, is worth exploring. We need a higher
> enough level-of-abstraction to achieve such integration, and the virt
> layer is clearly too deep down in the Nova stack.
> 
> Chris Behrens mentioned XenServer/XCP pools...these are managed via host
> aggregates: a concept that evolved in Nova over a few releases now, and
> it might be worth exploring too.
> 
> Moreover, if we look at other OpenStack projects, Quantum is a clear
> example of a common API (and yet extensible) that abstracts many
> heterogeneous back-end plugins: you have plugins that require certain
> services to run, whereas others do not.
> 
> Perhaps with little or even no work at all on nova-api, we can allow
> other cloud/virt management systems to integrate with OpenStack directly
> at the API layer. In the end, if these systems we're talking about
> (vSphere, oVirt, HyperV, etc) conceptually work just like Nova
> (providing their own scheduling, fail-over, etc), it might be as simple
> as providing an adaption layer in front of their API's, thus eliminating
> the need of implementing the full Nova stack (schedulers, conductors,
> queues, etc.).
> 
> I gather that this is what using cells would enable to a degree.

Indeed, that's where this cells idea is headed.

This cells approach has some really nice properties, though.  If it was
just about supporting the API, I'd argue it shouldn't be in Nova at all.
 It's overly complex to just be an API proxy.

Exposing these systems at the cells layer lets you support multiple
systems in the same infrastructure in a fairly clean way.  Suppose
you're standing up a new OpenStack deployment using KVM.  All of your
new libvirt+KVM nodes could live in one compute cell.  Let's also say
you have some legacy existing virt management infrastructure that you'd
like to take advantage of as capacity for your OpenStack cloud (oVirt or
whatever).  That could be exposed as another compute cell.  Cell
scheduling allows you to implement policy about which instances should
go to which cell of compute resources.

-- 
Russell Bryant



More information about the OpenStack-dev mailing list