1 |
On Wednesday, December 31, 2014 10:35:04 AM Rich Freeman wrote: |
2 |
> On Wed, Dec 31, 2014 at 10:00 AM, J. Roeleveld <joost@××××××××.org> wrote: |
3 |
> > The thing lacking from KVM (and I believe also Containers) is that the |
4 |
> > memory contents are not included in snapshots. Making the snapshots |
5 |
> > basically result in an unclean-shutdown scenario. |
6 |
> > Which is ok-ish as a backup, but not when testing different steps where a |
7 |
> > quick 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). |
12 |
|
13 |
Which is what I was afraid of and is what is keeping me from using it. |
14 |
|
15 |
> Processes in containers are really just processes on the host, |
16 |
> and I don't think there is much support in linux for snapshotting a |
17 |
> process. The best I could find was BLCR, but that didn't really seem |
18 |
> too mainstream (maybe it is). Snapshotting of the disk is whatever |
19 |
> you can do at the filesystem level - a container typically just looks |
20 |
> like a chroot as far as the host is concerned - typically you stick it |
21 |
> on lvm or btrfs for snapshotting. |
22 |
|
23 |
As a chroot-on-steroids inside a VM, it sounds usable, but not as a |
24 |
replacement for VMs. |
25 |
|
26 |
> Now, a big advantage of containers is that startup/shutdown is REALLY |
27 |
> fast. It isn't uncommon for me to run something like "systemctl stop |
28 |
> container ; btrfs su snap container container-back ; systemctl start |
29 |
> container" or something to that effect - often it takes less than a |
30 |
> second to run. Containers are just processes in a separate namespace, |
31 |
> so starting/stopping them is as fast as starting/stopping a service |
32 |
> for the most part. Obviously if your process takes a while to |
33 |
> shutdown and you stop it in a graceful manner then you'll be waiting - |
34 |
> if your process takes a very long time to shutdown/startup then maybe |
35 |
> VM-level snapshotting makes more sense. |
36 |
|
37 |
Some of the software we deal with can take up to 30 minutes to fully shutdown |
38 |
and re-initialize. (Gotta love those huge enterprise-level BI applications) |
39 |
|
40 |
> Depending on what your VM is doing snapshotting and restoring at the |
41 |
> memory level may not be entirely graceful either - obviously any |
42 |
> external connections are not going to be in the same state when it |
43 |
> resumes. |
44 |
|
45 |
Most of the snapshots I take are during the installation and configuration |
46 |
steps. Not many external connections exist during those stages. |
47 |
And the few that do exist generally re-establish themselves when the snapshot |
48 |
is restored. (All nodes of a single instance will be snapshotted near- |
49 |
simultaneously.) |
50 |
|
51 |
-- |
52 |
Joost |