Oh, did you have to open that can of worms ;) Network state needs to be migrated only if the hypervisor (or a kernel plug-in) provides the service (example: VMware vShield App/Zones, Juniper VGW, Xen OpenFlow-based filters). If you use physical or virtual appliances connected to a virtual L2 or L3 segment, then there's no need to move the state, as the appliance (where the state is) hasn't moved.
Interestingly, it's quite easy to move the session state(s) between hypervisors if they use OpenFlow like Open vSwitch (read the flows from the first hypervisor, copy them to the second hypervisor). Ivan > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Melinda Shore > Sent: Saturday, July 21, 2012 11:58 PM > To: [email protected] > Subject: Re: [nvo3] server2nve signaling: VM migration > > On 7/20/12 10:48 PM, Ivan Pepelnjak wrote: > > [M1b] The orchestration system *is not *involved in VM memory move. > > That would place unnecessary burden on the orchestration system and > > increase the latency/time-to-move. > > It is not clear to me that the amount of latency introduced would actually > be a burden given the existing time-to-move, but I think it's worth > considering how any associated network state (middleboxes, primarily - > i.e. firewalls) would be migrated in parallel with the VM, and which > network elements would need to be involved. > > Melinda > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
