[openstack-dev] [Nova] virt driver architecture

Russell Bryant rbryant at redhat.com
Thu May 9 14:53:05 UTC 2013


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.

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.

Thanks,

-- 
Russell Bryant



More information about the OpenStack-dev mailing list