[openstack-dev] [Nova] virt driver architecture

Sean Dague sean at dague.net
Thu May 9 15:45:08 UTC 2013


On 05/09/2013 10:53 AM, Russell Bryant wrote:
> Greetings,
>
> I've been growing concerned with the evolution of Nova's architecture in
> terms of the virt drivers and the impact they have on the rest of Nova.
>   I've heard these concerns from others in private conversation.  Another
> thread on the list today pushed me to where I think it's time we talk
> about it:
>
> http://lists.openstack.org/pipermail/openstack-dev/2013-May/008801.html
>
> At our last design summit, there was a discussion of adding a new virt
> driver to support oVirt (RHEVM).  That seems inappropriate for Nova to
> me.  oVirt is a full virt management system and uses libvirt+KVM
> hypervisors.  We use libvirt+KVM directly.  Punting off to yet another
> management system that wants to manage all of the same things as
> OpenStack seems like a broken architecture.  In fact, oVirt has done a
> lot of work to *consume* OpenStack resources (glance, quantum), which
> seems completely appropriate.

+1

> Things get more complicated if we take that argument and apply it to
> other drivers that we already have in Nova.  In particular, I think this
> applies to the VMware (vCenter mode, not ESX mode) and Hyper-V drivers.
>   I'm not necessarily proposing that those drivers work significantly
> different.  I don't think that's practical if we want to support these
> systems.
>
> We now have two different types of drivers: those that manage individual
> hypervisor nodes, and those that proxy to much more complex systems.
>
> We need to be very aware of what's going on in all virt drivers, even
> the ones we don't care about as much because we don't use them.  We also
> need to continue to solidify the virt driver interface and be extremely
> cautious when these drivers require changes to other parts of Nova.
> Above all, let's make sure that evolution in this area is well thought
> out and done by conscious decision.
>
> Comments airing more specific concerns in this area would be appreciated.

I think we learned a really important lesson in baremetal: putting a 
different complex management system underneath the virt driver interface 
is a bad fit, requires nova to do unnatural things, and just doesn't 
make anyone happy at the end of the day. That's since resulted in 
baremetal spinning out to a new incubated project, Ironic, which I think 
is really the right long term approach.

I think we need to take that lesson for what it was, and realize these 
virt cluster drivers are very much the same kind of problem. They are 
better served living in some new incubated effort instead of force 
fitting into the nova-compute virt layer and driving a lot more 
complexity into nova.

	-Sean

-- 
Sean Dague
http://dague.net



More information about the OpenStack-dev mailing list