We're open to suggestions on how the interface should look for this.

Right now, to elaborate on what Michael described, we'll have a "cloner" distro installed.  This will be generated from an actual distro, but modified to be a live environment with scripts to save off or load the hard drive over nfs.  Hence the "cobbler distro make-cloner command.
Specifically, this command could use the utilities in the livecd-tools package to create an iso or a pxeboot kernel/initrd that's purpose will be to save and load images.  This is what I'm currently looking into, any suggestions on this step are welcome.

The next step is to associate profiles with a cloner distro.  You'd create a profile for each image you want to save; profiles that are assigned to a cloner distro represent one image (but that image could go to several systems).  Systems that are assigned to the same "cloner" profile are intended to have the same image on them (or at least have the ability to reload the image from time to time).  In my use case, we'd equate profiles with projects, so we could save off an image related to a project and load another onto a particular machine as needed.

And the final step is to associate a system with a "cloner" profile.  When a system is assigned to a cloner profile and set to netboot enabled, its pxeboot file will point to the cloner distro kernel and initrd.  Additionally, kernel parameters will be passed to it to tell it to save or load, and where it should save/load to/from (nfs path), and the image name.  The computer boots, goes through the imaging process, and reboots back to the local hard drive when finished.


I thought this was relatively simple (compared to some of our initial ideas at least), and I like it since it follows the model for distro -> profile -> system pretty well.  This business of a cloner distro was chosen (over just including a pre-made kernel/initrd with the package like xcat does) for portability and compatability with all environments and arcitetures. 

The theory behind this feature is to be able to take a snapshot of a customized system.  Kickstarts are usually preferred, but in some environments it is desirable to be able to save a machine's current state off to an image.  Then perhaps something experimental can be tried, and the original image restored afterwards.  This is somewhat common situation in our lab.  The second useful situation is where we need to set up a machine in a very specific way: customize packages,  configs, files, and such, and then need to duplicate this to many other machines.  The customizations aren't always easy to compress down into a kickstart, and especially when the hardware is identical, imaging them is often easier and faster.  I know a lot of you probably don't need convincing that this is a useful feature, I just thought I'd share some of the more useful cases that I've come across for this kind of feature.

-Andrew