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 :| _______________________________________________ OpenStack-dev mailing list OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev