Hi Luke Good question on KVM live migration - short answer is we don't know. We're aware of some work done recently to ensure live migration converges by slowing down the VM until its memory page write rate can be real-time sent to the migrated instance, but haven't played with it enough to know what impact that has on network apps (is adding latency really any cleaner than stop/restart? discuss...). What is certain is that operators have to be able to manage and maintain their cloud, including replacing/upgrading hardware, so they need some strategy for being able to do that consistent with providing live service. If live migration were genuinely practical and non-disruptive then that would clearly be helpful, but you're right that there's a major question mark there. I think you're right to make this a lower prioritity.
cheers Calum From: Luke Gorrie [mailto:l...@snabb.co] Sent: 27 January 2014 09:25 To: snabb-de...@googlegroups.com Cc: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [snabb-devel] RE: [Neutron] Building a new open source NFV system for Neutron On 23 January 2014 17:42, Calum Loudon <calum.lou...@metaswitch.com<mailto:calum.lou...@metaswitch.com>> wrote: That sounds fantastic. As an NFV application developer I'm very pleased to see this contribution which looks to eliminate the key bottleneck hitting the performance of very high packet throughput apps on OpenStack. Thanks for the kind words! A couple of questions on features and implementation: 1. If I create a VM with say neutron and Open vSwitch then I get a TAP device + Linux bridge + veth device between the VM and the vSwitch, with the Linux bridge needed for implementing anti-spoofing iptables rules/ security group support. What will the stack look like with your NFV driver in place? Will your stack implement equivalent security functions, or will those functions not be available? Snabb NFV will implement equivalent security functions, and these will be configured via the standard Neutron APIs for Ports and Security Groups. Our goal is to offload most of these functions to the NIC using hardware features like Intel's Flow Director. Standard NICs actually have hardware sitting idle that can do most of the work that iptables/ebtables/ovs/bridge is doing for OpenStack -- we hope to put this hardware to work and free up the CPU for running VMs. The Snabb Switch traffic plane is internally structured as a network of "apps" that each implement one networking function and are connected by virtual Ethernet links (shared memory rings). This is a fairly accurate illustration of the internal components of Snabb NFV: https://github.com/SnabbCo/snabbswitch/blob/snabbnfv-readme/src/designs/nfv/README.md#snabb-switch-operation 2. Are you planning to support live migration? Good question! This is a priority if-and-only-if KVM's basic live migration mechanism is adequate for NFV applications. Do you know? (are some operators evaluating KVM for live migration and concluding that it is practical?)
_______________________________________________ OpenStack-dev mailing list OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev