Based on what I saw in the vmware.log file the base virtual hard disk "Windows 7.vmdk" file is severely corrupted and also the "Windows 7-000002.vmdk" file points directly to the "Windows 7.vmdk" without the "Windows 7-000001.vmdk" file in play.
Anyway I'd suggest restoring from a proper* backup if you have one.
Otherwise before preforming any other operations on the Virtual Machine/virtual hard disk I'd back it up first. Then try using vmware-vdiskmanager on a copy of the "Windows 7.vmdk" file and see if it reports it's okay or not. The "Windows 7-000002.vmdk" file is ~13 MB and almost not worth bothering with however if the "Windows 7.vmdk" file can be repaired the VM can be reestablished/recreated.
Have a look at, 
Work with Virtual Machine Packages and Repairing a sparse virtual disk in Fusion (1023888).
==========
*It is a known fact that Time Machine is not 100% reliable backing up/restoring Virtual Machines under all circumstances/conditions. Also backing up Virtual Machines via Time Machine is disk/time intensive and wastes a tremendous amount of space for something that may be corrupt and worthless come time to restore it. At a minimum I would exclude Virtual Machines from Time Machine and with the Virtual Machines shutdown, not suspended, and VMware Fusion closed then manually copy the Virtual Machines Package(s) to an alternate location, preferably on to a different physical hard disk. Then keep the User Data that is stored within the Virtual Machine backed up off of the Virtual Machine on a regular basis so as to always have a current User Data Backup. If you have to restore a properly backed up Virtual Machine that is not as current at least you'll have a working Virtual Machine and current User Data to go forward with when you find out your Time Machine Backup of the Virtual Machine fails.
Also have a look at: Best Practices for virtual machine backup (programs and data) in VMware Fusion (1013628)