I have the same question regarding the RDM mapping files not placed within the same folder as the virtual machine we are testing out SDU with. At this time we are using SDU 5.2, I think that's the latest and greatest. I didn't see anywhere in snapdrive.conf where this could be set. It just seems to be placing the mapping files/folder in a datastore not related to where the VM sits on its datastore.
I've seen this type of behavior in the VMware console where when you do a DRS operation, you can choose whether or not to also move the swap file for the VM. Sorta related because if you don't say, leave with virtual machine, it just picks the first datastore in the list. And the one our Linux vm is choosing when we do SDU operations is exactly that, choosing the first datastore in that list.
This is our first experience with SDU and VMware, we do have experience with SDU and physical servers on 5.0 and 5.1, SD 4 Windows and SD 4 SharePoint, this behaves very differently. Like one difference I've noticed is that SDU on VMware interacts with my VSC on vCenter... but SD 4 Windows and SD 4 SharePoint doesn't. Also noticed that the docs, TR-4212 and the 5.2 admin guide must not be up to date, since we are able to do things like vMotion the VM to different hosts without dropping the RDM first... and we are also using Paravirtual SCSI adapters. Both are labeled as "limitations" in both the 5.2 docs as well as TR-4212 Best Practice guide.
The VM is RHEL 5.5 is that matters, on vSphere 5.5.
VSC is 4.2.1
As far as iGroups go, we are just manually going into System Manager and mapping the rest of the hosts after the SDU operation. That isn't great automation, but it works for now.
Although the issue is still outstanding, if you storage vMotion the virtual machine to another datastore and choose to also move the RDM mapping files, it puts all virtual machine files together nicely. That is until you wish to use SDU again, then you will have to storage vMotion yet again.This happens to be my work around at the moment.