This post is more than 5 years old
15 Posts
0
1449
October 29th, 2014 02:00
ViPR Provisioning Error
Hi there,
I hope someone can help me on this. I'm trying to provision a ESX datastore from ViPR but has encountered some issues related to the SMIS provider error. The creation of the volume looks okay but when it comes to creating the Export Group, it gets this error as shown below:
Error 12023: Export create operation failed. Encountered an error in export create: Encountered an SMIS error when attempting to query existing exports: Error when attempting to query LUN masking information: A general error occurred that is not covered by a more specific error code. (com.emc.cmp.osls.se.osl.Masking.StorMaskGroupShow():138 C:ERROR_CLASS_SOFTWARE F:ERROR_FAMILY_FAILED R:1200019 C:ERROR_CLASS_SOFTWARE F:ERROR_FAMILY_FAILED R:1200019 The internal database is in an inconsistent state, and must be fully synchronized before performing this operation.)
I've logged into my SMIS provider and checked with TestSMISProvider.exe but there are no abnormalities seen. I am currently managing VNX5500 with ViPR.
Does anyone has any idea how can i proceed from here?
Many thanks,
Michael
Y1Udba1GsO12085
71 Posts
0
October 29th, 2014 03:00
HI Mike,
Which versions of SMi-S and FLARE are you using? There is a workaround for this issue performing the following:
The issue is related to a bug in the Flare code. There is already a fix for this in the latest Flare release.
Regards
Velik1
36 Posts
1
October 29th, 2014 08:00
1 more to add to Javier's -
I have seen this SMI-S message before.
the problem is when there is a difference between what the DNS says HBA owner names are and what ViPR tells VNX array, such as when you request IPs for your ESX hosts as smth.company.com, but you add them into vCenter by their IP address.
the problem goes away when you remove your ESX from vCenter, and re-add them by their true network name.
It is documented in release notes under CTRL-1880 known limitation in ViPR/VNX/vCenter setups.
mike843
15 Posts
0
October 29th, 2014 18:00
Hi Javier,
Thanks a million for the fast response
.
Here are the details of my SMI-S as well as my VNX code:
SMI-S Provider version: V4.6.2.3
Flare Code: 05.32.000.5.215
I've managed to use the workaround without rebooting the VNX SPs. I've just followed steps 3-6 and managed to order without any errors. By the way, is there any KB article related to this issue? Just want to check out what exactly is the root cause. Thanks
Michael
mike843
15 Posts
0
October 29th, 2014 18:00
Hi Stanislav,
Thanks for your input
You could be right in this case. As my ViPR and vCenter are sitting on different domains, so the way in terms of reporting the information could be unmatched. But I can't seem to find any related information that states that both the ViPR and vCenter has to be in the same domain.
Best Regards,
Michael
Velik1
36 Posts
0
October 30th, 2014 06:00
when ViPR configures visibility on VNX, ViPR is looking to create SGs named after host names that ViPR knows, and ViPR takes them names from vCenter.
so if you added your ESX servers to vCenter using names different than the names you get running "nslookup [ip address]" (typically that happens when folks add using ip address as the name), you end up with a condition on VNX where HBAs are logged in and associated with host names that VNX got independently and not from ViPR. And when ViPR comes in, it starts looking like your HBAs are in the wrong host, so a conflict is hit, and provisioning fails.