We are trying to use SnapDrive 6.2 to create a RDM LUN within a Windows2003 guest VM within Vsphere4. I have looked through the IAG and I can't seem to find out how to accomplish this. As we go through the process, everything is working as normal except when we go to add an initiator. There are no initiators in the guest OS so it will not allow us to move past this point..
Is there a way that you make the HBA's from the ESX server show up as a device within the Guest OS? I am definitely missing something...
Install Snap drive with all necessary Fixes. (Windows Fixes, Network Card Driver, LSI Logic Driver)
On the Netapp Filer make the Volumes.
Make as well the LUNs (it has to be Windows) on the Netapp Filer and map it (remeber the LUN ID).
Change back to the VC and add the LUNs as RAW Disk Mapping (Take the same LUN IDs). This has to be done within the properties of the vm (Add disk wizard)
Start up the Machine. Go to the Computer Management and then go to Disk Management. If you see the Disk initialize them and format them. If not make a rescan. (Menu Action)
Open Snap Drive
Now you should see the LUNs, manageable by snapdrive.
Thank you for the reply.
We went through those steps but the LUN was made as VMware so we are going back and creating a new one. I will let you know if that works.
Looking at the IAG for SD 6.2 makes it look like you should be able to create the LUN using Snapdrive directly... Is this not true?
About this task
Unless the LUN is shared within a Windows cluster, the LUN must not be connected to more than
LUNs should be created using SnapDrive.
Perform the following actions to launch the Create Disk wizard:
Select the SnapDrive instance for which you want to create a disk.
From the menu choices at the top of MMC, navigate to Action > Create Disk .
Create Disk Wizard is launched.
In the Create Disk Wizard, click Next.
Provide Storage System Name, LUN Path and Name panel is displayed.
In the Provide a Storage System Name, LUN Path and Name panel, perform the following actions:
In the “Storage System Name” field, type the storage system name where the LUN will be created
or select an existing storage system using the pull-down menu.
Make sure to create the RDM LUN as type Windows - the filer owns the filesystem on the RDM. Unless things have changed since 6.0, if you want to use snapdrive within a VM and utilize your FC HBA connections you have to follow the steps I outlined. Maybe 6.2 changes that - I don't know I'm afraid. If you plan on using iSCSI as your protocol then yes, you create the LUN with snapdrive.
We were finally able to get things working.
It's pretty nice, in SD6.2 it will now create and connect to the LUNs automatically for you using the ESX host HBA's and RDM so that you do not have to go through the steps outlined above. For some reason the first host we were using had an issue so we created a new VM with a fresh install and everything worked great..
Thanks for the replies!
That is usually the result of not having the LSI drivers present. Seen commonly wit a P2V guest.
- - - - - - - - - - - - - - - - - - - - - - - - -
Please excuse typographic errors.
This message was sent via Blackberry device.
Thanks! We now have this working with Exchange running on ESX VMs in a CCR configuration. There's a couple of oddities, however they are not show-stoppers. One item of note: Occassionally when the VM reboots, SnapDrive loses visibility of the RDM LUNs, however the guest OS still sees/can access them. So far the work-around is simply to stop/restart the SD6.2 services (both of them). I suspect it's a timing issue as SD has to authenticate with the filer and the vCenter Server (which in turn needs to talk to the right ESX host) or at least with the ESX host directly (depending on how it's setup). Any thoughts on how to fix the 'disappearing LUNS from SnapDrive on a VM' problem (besides our stop/restart SD services work-around as above)?
Thanks! We were using SD 6.2 from mid-OCT, so it may have been an earlier build that exhibited this bug even when doing soft (clean OS shutdown/restarts) reboots. We did not try a hard power-off reboot.
I don't know if this is fixed or not. We have the same behavior on file version: 18.104.22.168 of SD6.2. We actually edited the Windows registry to make SD dependant on the MS Exchange IS process to make certain it starts before SD. We have on occasion seen the issue of the missing LUN, but what we actually have is a missing drive letter. The LUN is still present, but on reboots (sometimes but not always) the drive letter will be missing. Is anyone else having this problem, or is there a different version of SD we should be using?
The issue was supposedly fixed but it actually wasn't. I can confirm because I ran into the issue with a client 2 weeks ago and downloaded/installed the latest snapdrive 6.2 version (the one with bug fixes). The problem persists. Snapdrive doesn't see igroups that are manually created on the Netapp. This really needs to be resolved 100% once and for all.
Other then that, you can use snapdrive to create the RDM.
Thanks for this info Ian. I wish someone from NTAP would chime in here as this does still seem to be a pretty big problem (i.e. reboot your Exchange server and drive letters are missing). Do you know if using the "Manage Initiaor Group" wizard from SD and renaming the igroup will correct the issue? I would just try to create a new igroup, but the problem in ESX/vSphere is you can't use SD to create the igroup since it doesn't see every initiator for every server in the VMware cluster. We use DRS so this server could be on any one of 6 different servers.
I got a hold of the dev crew and here's what they said.
##### Dev writes:
For LUN missing issue, what we have observed is sometimes during a reboot of a VM it is not getting registered properly to Vcenter and SDW isn't able to get information from VI-SDK so we disable the communication with VC during startup so SnapDrive service can startup. In these cases, the work around is to enable VC communication again manually by calling VS_Config set command and restart the SDW service, so it can see the FC LUNs and initiators which are not enumerable due to non-communication with VC.
If you send me your SDW logs, I will forward this to the team to analyze the problem. If you haven't already, you may want to open a support ticket so we can track this internally.