2009-11-06 02:23 PM
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...
2009-11-06 02:41 PM
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.
2009-11-06 03:03 PM
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.
2009-11-06 03:10 PM
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.
2009-11-06 04:36 PM
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!
2009-11-06 04:49 PM
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.
2009-11-08 08:23 PM
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)?
2009-11-09 09:30 AM
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.