Okay...updated, and it seems to be working!
First, had to delve into the settings a bit. I uploaded a RIP (rescue is possible) CD to the datastore along with one of our XP install disks.
Second, the bootup was impossibly fast. There's a setting to control that, and to control forcing it to go to the BIOS setup at boot, from the edit settings for the VM. Need that to change boot order to work with the CD before the hard disk.
Third, attach CD ROM image from datastore (RIP CD) to the CD drive.
Fourth, remember to "connect at startup" for the CD drive. Whoopsie.
That's how to get it to boot from another source. I booted RIP and had it run Testdisk, which did some repairs to the partition but it kept detecting that the number of heads was misset (I'd change it in the geometry menu but it just wasn't "saving" the new settings...haven't figured that one out.) Reboot, this time it got to the point where it would blue screen. Progress!
Next was a trip to Windows XP's bootable ISO and from there into the recovery console. I ran fixmbr, then fixboot, then chkdsk c: /p twice. Did a quick dir to see if files looked intact (like ntdetect and ntldr) and then exited, shut down the VM and removed the disc from the virtual drive (disconnect at powerup) and crossed fingers.
The VM booted up. YAY!
Thank you to all who offered suggestions!
Where shared NFS storage is mounted on Node01?
I think it is better to mount NFS share in /var/lib/mysql (default for RedHat) instead of configuring paths for server and clients.
I don't know what do you want to achieve. But if you try clustering mysql this way you are wrong and could couse data inconsistency. This setup is only valid, if mysql service on Node01 is started after Node00 failure.
If you want to have 2 instances of mysql accesing data concurently, you should use NDB cluster. If you start two mysql instances accesing the same datadir, you get data inconsistency.
For stand-by purpose you should better use DRBD replication or mysql replication (probably with MMM).
Best Answer
The easiest way of accomplishing this on v3.5 is to run the VM through the VMWare Converter software again, this time picking a smaller disk size.
You'll have to have enough space to hold both the original VM and new VM while the conversion completes, but once the new VM has booted successfully, you can remove the old copy.