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.



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

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: 

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

Reply via email to