I am trying to configure SMVI to use shared storage as per the TR released in Jan 10 (section 5.3). I am using SMVI 2.0, vSphere with vCentre 4.0.0 build 208111 on a Win2k3 server. I can start the GUI and log in if I leave it as a default config with the files on the C: partition. I can also execute smvi cli commands like smvi servercredential list.
I have created a vol on the filer and a LUN with Snapdrive and mapped it to H:\. I have stopped the SMVI service, and I have created the directories as specified in the TR. I edited the smvi.config and smvi.override files as specified in the TR and copied the cred file to the new H:\ directories. I restarted the SMVI service and now when I enter the GUI and use the same login/password as before it doesnt log into SMVI. If i use SMVI CLI and execute the same command it tells me "Connection to the server refused: Ensure that the server is running".
I created the user with the smvi servercredential list that I wanted to log in with, and i checked that this user can log into vCentre.
Anyone done this and got it working, and have any ideas what could be wrong ?
I am not sure I understand completely, but I created a vol and qtree on the Netapp, then installed DSM MPIO and Snapdrive on the vCentre/SMVI server and created a LUN using Snapdrive and assigned it the drive letter H, and then Snapdrive created it and formatted it. Is this the wrong way of doing it ?
EDIT: I just saw your reply, sorry if it was unclear, I meant the SMVI v2 TR dated Jan 2010 (you probably know this document well 😉 )
Do you need DSM? It can cause problems if you have only one path. Also are you trying to install on a cluster resource owned by another node? We would need to take a look at the ONTAPWinDC logs to be certain of the exact problem. You could log a case since we were able configure SMVI in our lab without running into this.
We need DSM MPIO as the FC SAN is a dual switch and redundant path configuration. The H drive LUN was created as a dedicated LUN and not a shared MSCS LUN.
It seems to be something to do with when it needs to look at the cred file that has been moved to the H drive location that it is failing. I have checked permissions on the drive/folders and this is OK.
I can log a case for it.
Yes, that could be a problem. For Windows users, SMVI expects username in the format <DOMAIN-Name>\<UserID>. If you are logging in as local user then, you should use local host name in the place of domain name.
The only thing that is making me think that isnt the problem, is that when SMVI was configured to hold everything on the C:\ drive as per a normal install, I didnt use the domain\username to log in, just the username, and this worked fine. I am not sure that just changing the location of the configuration files would make any difference, but I will try it.
I am in the process of building a Win2k3 server, AD server, vCenter/SMVI server and ESX server as VMs to replicate the customer environment, and present a LUN from the 7.3.2 simulator via iSCSI to see if I can replucate the problem.
If it worked without domain name when files were on C: then it should work the same way when files are on shared drive. I tried to repro this problem in my lab and I couldn't. So let us know if you could repro it. BTW, did you get chance to get the logs?
Right, seeing as though I am a sad techie geek, I have spent this weekend setting up a test environment....
Win2k3 SP2 x86 Enterprise server, with vCentre server and vSphere client 4.0u1, ONTAP DSM for MPIO 3.3.1, Snapdrive 6.2, SMVI 2.0, iSCSI initiator 2.08 build 3285 (admittely I am using iSCSI instead of FC like at the customer, but i still see the problem).
Netapp simulator 7.3.2
I installed it all in default locations (C:\) and was able to log into SMVI with the user I set up in vCentre (computer admin account that is not called administrator), and see the ESX server. I ran smvi servercredential set to create my cred file. I could still log in at this point. I stopped the service, created the LUN with Snapdrive and mounted as H: and created the directory structure. I moved the cred file, edited the smvi.config and smvi.override files, and restarted SMVI.
I could not log into the GUI and got the same error from the CLI about connection refused, check the server is running (i checked the service and it is).
I have attached the log files, for what its worth.
I created an aggregate with System Manager, then created a flexvol and a qtree (with mixed security style). I then created the LUN with snapdrive onto the qtree.
Thanks Dave. Apart from the steps in the BPG what are the other steps that you are using to create shared storage? We're trying to reproduce the configuration in our lab to get this error.
Based on your description, it appears that SMVI is not able to locate credentials or keystore file. Can you please confirm the value for the key http.ssl.keystore.file in smvi.override file? The value of this key should be valid path for smvi.keystore file. If that doesn't solve the problem, we need to investigate further and will need to check smvi.config, smvi.override files as well as log files.
I configured the shared storage LUN as the H drive as it was consistent with the TR and easier that way !!!
credential.persistence.file.path=H:\\NetApp\\SMVI\\\server\\etc\\cred (i copied the cred file to this location after SMV successfully started with the config on the C drive)
http.ssl.keystore.file=C:\\Program Files\\NetApp\\SMVI\\\server\\etc (i tried this as the C drive and then the H drive and neither worked)
I am not on site at the customer now but I will ask them for the log and add this to case 2001265952 and put it here.
I too am having the same problem. I have SMVI/vCenter as a virtual machine, with the MS iSCSI initiator and access to an iSCSI LUN on the NetApp. When I follow the TR and try to move to shared storage, I too cannot login to the SMVI GUI. I've done this before with SMVI 1.0, but this is my 1st attempt with 2.0. I have a case open with NetApp. Has anyone made progress with this?
Another quick question you mentioned "TR released in Jan 10 (section 5.3). " Did you mean Jan 20? We have updated the older version of this TR with updated steps for SMVI on shared storage.