[CRIU] CRIU LXC Container Live Migration Concerns

[Deepak Vij (A)]

Thanks for your quick response. I appreciate it.

Regards,
Deepak K. Vij

-----Original Message-----
From: James Bottomley [mailto:jbottomley at parallels.com] 
Sent: Thursday, May 08, 2014 2:17 PM
To: Deepak Vij (A)
Cc: Pavel Emelianov; criu at openvz.org
Subject: Re: [CRIU] CRIU LXC Container Live Migration Concerns


On Thu, 2014-05-08 at 19:45 +0000, Deepak Vij (A) wrote:
> Hi folks, I am back with the following few additional questions. I
> would look forward to your response/feedback on these. Thanks.
> 
> Regards,
> Deepak K. Vij
> 
> =================================
> 
> 1) Live Migration & Network Addressing: Hypervisor based VM Mobility
> environment is typically restricted to a Layer 3 subnet and a Layer 2
> domain (for VLANs) because the underlying network will support the VM
> operating outside of the local scope of those addresses. Needless to
> say, the network addressing scheme in a cloud operated by an entirely
> different service provider is not only a different subnet but a
> different class B or class A network altogether. At the time of live
> migration of VMs, routers and switches simply would not know how to
> cope with the "rogue" running system at the time of live migration.
> One alternative is to extend the L2 segment using L2overL3
> tunneling/SDN based protocols.
> 
> Although container based virtualization (LXC etc.) has a notion of
> Network Namespaces, wouldn't container based live migration have the
> same issues as the above mentioned hypervisor based VM Mobility across
> subnet. From that standpoint, shouldn't this be the same for any
> container environment, be it LXC/Docker, OpenVZ, Parallels, BSD Jails,
> or Solaris Zones etc.

Yes, but it's not just a Container or VM problem.  HA software doing
failovers has the same issue.  In fact the migrate to another cloud
problem was foreshadowed by geographically distributed HA, which had
exactly the problem that the applications fail over not only to a
different L2 segment but to a different L3 connection as well.  That's
why most people in the cloud love SDN ... it's an acronym which allows
you to get away from the problem.

But you also have to remember that like a VM, a container can actually
reattach the network interface across migration, so it could be simply a
tunnel back to the previous net environment.  This seems to be the way
most cloudbursting implementations are set up.

> 2) Live Migration & Storage/Databases: For any Live Migration
> (Hypervisor based VM Mobility or Container based Live Migration),
> storage replication across LAN & WAN environments needs to go along
> with the live migration process - such as SAN storage (LAN) or maybe
> EMC VPLEX like replicated storage (WAN). One could also choose to move
> just the VM state while keeping storage in the original data center,
> but that will impact application performance.

Yes, for our commercial product, we have a cloud storage system that
means the storage connection remains as the container migrates.  Since a
lot of container systems use chroots of underlying shared filesystems,
NFS mostly is the way they maintain storage connections.

James