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