On Wed, Dec 31, 2014 at 10:00 AM, J. Roeleveld <jo...@antarean.org> wrote: > > The thing lacking from KVM (and I believe also Containers) is that the memory > contents are not included in snapshots. Making the snapshots basically result > in an unclean-shutdown scenario. > Which is ok-ish as a backup, but not when testing different steps where a > quick > and easy roll-back is often required.
That is a very good point, and as far as I'm aware container memory can't be snapshotted (unless you count suspend-to-disk of the entire host). Processes in containers are really just processes on the host, and I don't think there is much support in linux for snapshotting a process. The best I could find was BLCR, but that didn't really seem too mainstream (maybe it is). Snapshotting of the disk is whatever you can do at the filesystem level - a container typically just looks like a chroot as far as the host is concerned - typically you stick it on lvm or btrfs for snapshotting. Now, a big advantage of containers is that startup/shutdown is REALLY fast. It isn't uncommon for me to run something like "systemctl stop container ; btrfs su snap container container-back ; systemctl start container" or something to that effect - often it takes less than a second to run. Containers are just processes in a separate namespace, so starting/stopping them is as fast as starting/stopping a service for the most part. Obviously if your process takes a while to shutdown and you stop it in a graceful manner then you'll be waiting - if your process takes a very long time to shutdown/startup then maybe VM-level snapshotting makes more sense. Depending on what your VM is doing snapshotting and restoring at the memory level may not be entirely graceful either - obviously any external connections are not going to be in the same state when it resumes. -- Rich
