All attempts to clone this failed.  I tried cloning on the SAME host using both "clonehd" and "clonevdi" but when I would try to start up the host I would get many strange errors - although it would start - indicating that the machine was in an inconsistent state of some kind.  I think this had to do with the incident where the discard of snapshot operation ran out of space.

So then I tried copying the file to another host machine, and startup that way.  Still had same errors as above.  So that proved that the working image was making use of a snapshot to provide a consistent working machine because the errors were in the .vdi datafile itself.

So then I decided to take another snapshot.  Now there is a link to a snapshot I several days ago in the /home/gstanden/.VirtualBox/Machines/centos-4.7-A/Snapshots directory.  It points to the snapshot which never got applied, at least I think it's the one that did not get fully applied (disk ran out of space).  Well so I took another snapshot, and lo, it did not create a new snapshot; moreover, when I went to discard the newly "created" snapshot, it began applying the one mentioned above - the one that had never applied.

So I'm hoping that VirtualBox "knew" that that snapshot had not been applied and is reaccessing it and reapplying it.  I don't think there can be any other explanation.  That snapshot is the only one that is softlinked in the /Snapshots directory so it's the only one the system could "see" and it's the one it is applying now.  That snapshot is the only explanation for why the original machine is starting up ok.  The original .vdi file has this defect which is causing the error - probably caused when the snapshot did not finish applying correctly.  So I guess when you click "create snapshot" the software somehow checks to see if the current .vdi has already applied all previously-taken snapshots fully - and if not - it assigns the snapshot which has not yet been fully applied to be the "new" snapshot.  So when you discard that snapshot again, it hopefully re-applies it again - maybe starting from where it left off when the disk filled.  Anyway, I will find out soon today...