Where does SDU keep vmware RDMs pointers?

[#1]

Hey,

I ran into an issue where I allocated a few RDMs to a virtual linux server via FC (rhel 6.2, sdu 5.2, ESXi 5.0) and sdu created a vmdk for each lun that is presumably a pointer with the rdm info.

The problem is that sdu placed these vmdks in my swap datastore and the question is how does sdu decide where to place the vmdks and can this be defined.

In addition, sdu mapped the rdms only to the specific esx host the virtual server resided on at that moment and not the whole cluster. Can this be configured as well?

Thanks.

[#2]

Hello,

I had the same issue. Have a look at the following BUG

http://support.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=600206

Usually, RDM pointers should be placed with the VM configuration file. You can try a newer version of SDU (5.2P1).

Regards,

Mladen

[#3]

Thanks Mladen, it seems to be the same problem but it relates to snapdrive for windows and I have the issue in a linux environment. No registry to edit.

Was your problem in windows or linux?

I'll try 5.2P1 although this issue doesn't in appear in the list of fixed bugs.

Thanks,

[#4]

I think it was windows, but in your case (linux) I would even try an older version of snapdrive. Once I had a situation where SDU 4.x was a solution.

You should check IMT (compatibility matrix) and see if vsphere,linux and sdu versions all match.

Mladen

[#5]

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.

[#6]

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.

[#7]

An RFE was opened with support... to be continued.