4 ms·
Live migrating a process from one host to another sounds fun on paper, until you run into all the caveats. And it gets even more fun when you try to do it on a
by ardel95 4y ago
Live migrating a process from one host to another sounds fun on paper, until you run into all the caveats. And it gets even more fun when you try to do it on a cloud provider, where your process state is coupled to the instance on which it runs (such as security group or instance metadata state).
- Twirrim 4y agoIt's crazy fun on the cloud provider side too. Live migrating entire instances between two hypervisors isn't exactly the simplest thing to do. SR-IOV, which you want for lower latency network connections can't do it cleanly. vDPA will hopefully save us from all that insanity.
- ilyt 4y ago> It's crazy fun on the cloud provider side too. Live migrating entire instances between two hypervisors isn't exactly the simplest thing to do. Migrating VMs works pretty decently actually, biggest latency is from telling the network equipment where the traffic should now go. The attached hardware is the issue, as you said. If all you talk is paravirtualized stuff it generally works, just need to make sure target CPU supports required stuff (we had to downgrade exposed CPU temporarily to migrate between intel and AMD hypervisors), but good luck with having GPU attached... Moving to "migrate the process" (which is essentially what is required to migrate containers) adds a whole level of mess to deal with.