I'm thinking that initially we could have some sort of "exclude_list" file, but as I ponder the more general issue of all this "one off" image customization, do we trust image creators enough to have more than just a simple list of filenames or boolean go/no-go indicators in the image? Initially, having a 'vcl-capture-exclude-files' control to enable/disable parts of the capture process would be relatively safe, but I think eventually we could include more extensive user-exits that might override or extend default VCL functions like capture, preload, and image startup/shutdown, without having to modify VCL itself.
We could hide these image exits in /opt/vcl/ or whatever, but I'm thinking we might treat these per-image configuration extensions as files in a hidden directory like /root/.vcloptions or c:\vcloptions . The hidden / dot-file convention makes it like other image personalization configuration files, and makes it easier to hold onto changes if you create a new edition of an image and need to tweak things again. Most image customizers wouldn't touch any of this, but this mechanism could be very handy for handling edge-cases or bleeding-edge software. I think I like more comprehensive user-exits, it can also make adopting a new or strange Linux (or other OS) easier for end-users, rather than having them promote their code into VCL itself. Over time, VCL can adopt some of the better ideas into new base VCL modules so that the per-image customizations can be reduced. One additional feature might be to put some flag in the ImageProfile to indicate "disallow vcl user exits" so that if someone truly screws something up maybe we can recover without delving into raw VMware / KVM.