Open Stack

>> I also think there is value in exposing vGPU in a generic way, irrespective of the underlying implementation (whether it is DEMU, mdev, SR-IOV or whatever approach Hyper-V/VMWare use).
> 
> That is a big ask. To start with, all GPUs are not created equal, and
> various vGPU functionality as designed by the GPU vendors is not
> consistent, never mind the quirks added between different hypervisor
> implementations. So I feel like trying to expose this in a generic
> manner is, at least asking for problems, and more likely bound for
> failure.

I feel the opposite. IMHO, Nova’s role in life is not to expose all the quirks of the underlying platform, but rather to provide a useful abstraction on top of those things. In spite of them.

> Nova already exposes plenty of hypervisor-specific functionality (or
> functionality only implemented for one hypervisor), and that's fine.

And those bits of functionality are some of the most problematic we have. Among other reasons, they make it difficult for us to expose Thing 2.0, when we’ve encoded Thing 1.0 into our API so rigidly. This happens even within one virt driver where Thing 2.0 is significantly different than Thing 1.0.

The vGPU stuff seems well-suited for the generic modeling work that we’ve spent the last few years working on, and is a perfect example of an area where we can avoid piling on more debt to a not-abstract-enough “model” and move forward with the new one. That’s certainly my preference, and I think it’s actually less work than the debt-ridden way.

-—Dan