The idea of saving a complete running system to disk was present in the 1970s RSX-11 family of operating systems for the PDP-11 (RSX-11D, RSX-11M). In fact, it was originally the only way to create the system in the first place.

In RSX-11M, which is the system I am most familiar with, you first generated the system kernel. This was then booted, and then you could install programs, create memory partitions, etc., and do any other configuration you needed. Finally, the entire memory image was saved to disk as a contiguous file, overwriting the original file from which you booted. Subsequently boots read the fully-configured system into memory.

Subsequent configuration changes could be saved by the same method.

For this to work, the SAVe problem arranged to quiesce the system, ensuring that there was no I/O in progress. Files remained open, which required that in-memory pointers to on-disk structures remained valid. Task execution was blocked.

Of course, SAVe was running in the image that it saved. This allowed it to unblock task execution and reverse any other changes made to in-memory structures during the save. It also gave a route to run any startup commands that were not appropriate to freeze in the system image.

In later versions of the system, this approach of setting everything up 'live' gave way to doing it on a disk image. A program called VMR (virtual monitor console routine) implemented as set of commands to operate on addresses in the disk image similarly to commands in MCR (monitor console routine, the command interface) operating on addresses in memory. But the resulting disk image was the same - a 'frozen' execution of the OS.

For all I know, DEC systems before the RSX-11 family did similar things.

The idea of saving a complete running system to disk was present in the 1970s RSX-11 family of operating systems for the PDP-11 (RSX-11D, RSX-11M). In fact, it was originally the only way to create the system in the first place.

In RSX-11M, which is the system I am most familiar with, you first generated the system kernel. This was then booted, and then you could install programs, create memory partitions, etc., and do any other configuration you needed. Finally, the entire memory image was saved to disk as a contiguous file, overwriting the original file from which you booted. Subsequently boots read the fully-configured system into memory.

Subsequent configuration changes could be saved by the same method.

For this to work, the SAVe program arranged to quiesce the system, ensuring that there was no I/O in progress. Files remained open, which required that in-memory pointers to on-disk structures remained valid. Task execution was blocked.

Of course, SAVe was running in the image that it saved. This allowed it to unblock task execution and reverse any other changes made to in-memory structures during the save. It also gave a route to run any startup commands that were not appropriate to freeze in the system image.

In later versions of the system, this approach of setting everything up 'live' gave way to doing it on a disk image. A program called VMR (virtual monitor console routine) implemented as set of commands to operate on addresses in the disk image similarly to commands in MCR (monitor console routine, the command interface) operating on addresses in memory. But the resulting disk image was the same - a 'frozen' execution of the OS.

For all I know, DEC systems before the RSX-11 family did similar things.