Let's dig deeper into that process.įirst, implement timestamps in ploop messages, raise the log level and see what is going on here. Why it is so slow? Apparently, ploop mount takes some noticeable time. Basically, it shows timing of vzctl restore command. Total suspended time: 4.33 4.16 3.54 5.01 4.68 4.85 4.428Īpparently, the first suspect to look at is that "undump + resume". We ran a few iterations migrating a container back and forth between two OpenVZ instances (running inside Parallels VMs on the same physical machine), so there are a few columns at the right side. Typical timings obtained via vzmigrate -t -live look like this. In order to do that, one needs to dig into details on what's happening when a container is frozen. This time (shown if -t or -v option to vzmigrate -live is used) is what needs to be optimized, making it as short as possible. There is a short time period, usually a few seconds, during which the container being migrated is frozen. But let's not jump to resolution yet, it's a long and interesting story to tell.Īs you know, live migration is not quite live, although it looks that way to a user. It's time to write some more about it, since we have managed to make ploop live migration yet more effective, by means of pretty simple optimizations. It has been almost two years since we wrote about effective live migration with ploop write tracker.
0 kommentar(er)
