Open Stack

On Tue, Oct 21, 2014 at 11:52:26AM +0000, Tim Bell wrote:
> 
> It would also be interesting if the features of KVM could be made
> available through OpenStack around the same time.. virtio-blk data
> plane would be an example where we can't work out how to exploit it
> out of the box under OpenStack.

The rate of change in QEMU (KVM) is pretty enourmous and many features
are not entirely relevant to OpenStack needs. The hard bit though is
actually figuring out how to best expose new features via OpenStack.

With the cloud paradigm we explicitly want to avoid the end user (the
VM instance / image owners) from knowing anything about the compute host
hardware. The result is that they will typically not have sufficient
knowledge of the system to be able to know whether some new QEMU flag
or feature is appropriate to use. So we have to try to design things
so that Nova either makes an self-driven policy decision, or define a
way for the user or cloud admin to provide hints/preferences via image
metadata and/or flavour extra specs, then use this hints to influence
the policy decision indirectly.

The NUMA work is a good example of this. QEMU provides a feature to let
the app define mapping between guest NUMA nodes and host NUMA nodes. The
cloud user has no knowledge of the host NUMA topology, so it is impossible
for them to take the simply approach to using QEMU's NUMA feature. Instead
we have to provide a way for the user or admin to define characteristics
of the guest NUMA topology, and then have teh Nova schedular figure out how
to map that into the host NUMA topology. This is a pretty major bit of work
over & above what QEMU provides, so there's inevitably going to a delay
between a feature appearing in QEMU and it being available in OpenStack.

On your specific point about the virtio blk dataplane option. Libvirt has
explicitly not provided any supported way to turn that feature on in the
guest XML config, on advice from the QEMU maintainers. This is because
the dataplane option is considered a short term hack/experiment to prove
a general conceptual idea. Libvirt does allow for QEMU command line option
passthrough, but that "taints" a VM instance as being in an unsupported
state. The reason for this is that the dataplane option will be removed
from QEMU in favour of a different supportable long term solution, so
neither libvirt/QEMU maintainers wish it to be used by production facing
apps right now.

The long term replacement for dataplane is a new "I/O threads" option
that was recently wired up into QEMU and libvirt. It would be appropriate
to look at how to support this I/O threads option in OpenStack now, so
please feel free to file a bug requesting it. If you have specific info
about usage/deployment scenarios in which dataplane has proved a benefit
(or equally a negative), then would be useful to have in the bug too, so
we can figure out how to best support it. Ideally we'd not hve to expose
this to end users and Nova would just "do the right thing" to maximise
the performance win.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|