When I run mbralign (in ESX host) of a guest vmdk the align works great for the boot partition. Two things happen though.
1. My guest starts with a .vmdk and flat vmdk files. When completed I only have a .vmdk file, the flat file is gone.
2. I have had two server, a SQL server and a Exchange Server that had C and D drives, and then iSCSI map points (outside of vmware for the map points). Anyhow the C drive aligns fine, but the D drive (probably any non boot partition) goes through the alignment process fine, but shows up blank in Windows. Note the flat files are gone.
In the case of the exchange server and I had to do a snap restore through the vmware netapp snap tool. With the SQL server it was brand new so I just formatted the drive.
I am no afaid to use this tool for fear of losing data.
Here is a pic of the a XP VM after the tool has run. Notice the flat file is gone, but you can see there was a backup of it.
even though this post is quite old, it may still be relevant. Just a quick understanding of what you're doing because I've had something similar-ish:
You have a SQL/Exchange server. Do each of these servers have a single vmdk with multiple partitions, or do they have seperate vmdks for each partition/drive that's configured?
The reason I ask is because I believe I had something similar happen...
I have a SQL server configured with 3 seperate vmdks representing each disk drive in the O/S. I ran the mbralign tool against all the vmdks seperately with no incident, but when I rebooted the VM I found that SQL wouldn't start. After some investigation I noticed that except for the boot partition, the LOG and Database drives were not even showing in the VM - hence SQL may still be installed, but the databases and log files don't exist any more.
What I believe is happening is that when you run the mbralign tool against the boot partition/vmdk, it aligns it, and somehow updates the identifier for the vmdk. No problem when you have a single vmdk, or when the vmdk you're aligning is the boot partition, however, when you align your secondary and tertiary drives, they are also somehow modified so that the vSphere configuration no longer shows those drives and doesn't load them ie:
drive1 = id1
drive2 = id2
drive3 = id3
drive1 = id4
drive2 = id5
drive3 = id6
but the configuration of the VM itself, expects this:
drive1 = id4
drive2 = id2
drive3 = id3
My experience with this was quite strained as my SQL server also contained the virtual center database which in itself had it's difficulties. I still haven't re-aligned this particular SQL server but when I do, I believe that aligning just the first drive will do the trick.
The *.vmdk & *-flat.vmdk isn't necessarily needed -- the *.vmdk is just a text descriptor file with some info that then points to the *-flat.vmdk. So mbralign merging the two isn't a definite problem (as long as the remaining file is big -- i.e. isn't just a descriptor file).
mbralign always makes a backup file before it starts - if any issues rerun mbralign, it will detect the backup files are still there and offer to put them back. If things work fine after the alignment, you'll have to come back later and remove the backup files. My regular process is to run mbralign, boot the VM to make sure things are fine, and then make a note to come back in a couple days to remove the backup files manually.
I am running the one that came with the latest host utilities (5.1 May release of the host utils).
So if I start the VM and I have say a blank D drive (windows thinks so) then I just shut it down and run mbralign again to restore them? I thought about just renaming the backup files and then renaming the new files, but as this was my production Exchange server I went right for the snapvi restore.
Which by the way the snapvi says its completed the restore in the gui but in reality the vmdk file takes a while to restore. The snamvi interface is done with its command but the actual restore is not, you notice this when your VM wont start:( I can live with that problem right now.
I always thought the flat file was created when you created a large vmdk over 2gig or whatever.