A few weeks ago, I was working on a migration for VMware and utilizing Storage vMotion (VMFS FC LUN to same).
At the time, VSC 2.1.2 was installed. vCenter is version 5 (had upgraded from 4.1 a couple of months prior although there were no actual ESX migrations to 5).
My plan was to use the VSC to provision all of the datastores, and it worked incredibly well, except for on ONE controller out of six. One of the nodes in an HA pair (3210) was unable to utilize the provisioning and cloning portion to create a new datastore, so I did it manually (created volumes & LUNs, created igroup, mapped to LUNs, rescanned storage adapters, etc...). The LUNs came in perfectly fine and storage vMotion migrations took place without any errors.
My main issue now is that in using the VSC for run fully quiesced backup jobs of the VM's on the LUNs, we can only see the two LUNs that were created from within the VSC. The other two LUNs that were created manually cannot be backed up via the VSC.
Can the VSC only see datastores that you provisioned using the VSC plug-in or should it see all datastores no matter what? It seems to be able to see some NFS datastores that are part of another cluster, although they are not in question as being part of this specific backup job.
We took an outage this past weekend at the client during a maintenance window and I thought that perhaps removing the datastores that had been created manually and then mounting them via the VSC would resolve the issue, however the VSC did not recognize them as valid datastores.
Looking for some assistance on this matter to make sure all of the datastores in question are being backed up in the same VSC backup job.
VSC backup & Recovery has an Isolated Setup & Authentication. So it should ideally not depend on what was provisioned using VSC. If you right-click a datastore, are you able to see the NetApp Context Menu of Backup & Recovery for the datastore?
This is out of context but you can check if your manually created volumes/LUNs are being managed by VSC Provisioning & Cloning by Clicking on resources link on the upper right corner after you select Storage Controllers under 'Provisioning & Cloning'.
Thanks for the reply! Yes, if I right-click on one of the two LUNs, I a can successfully see the NetApp context menus (pic attached).
Also, when accessing the "Resources" option, the LUNs in question are there.
Some quick info for reference, LUNs 01 & 03 were created using the VSC P&C operation and are housed on controller 1 in the HA pair. LUNs 02 & 04 were created manually and are housed on controller 2 of the HA pair.
I tested the same in my lab here and I can see the manually created LUN under 'Entities'.When you select a Datacenter under the entities, do you see the LUNs listed under 'Available Entities'? Can you also try and create another test datastore manually to see if it is visible or not?
Meanwhile you can use the right click option to create a backup job for the affected LUNs.
I created a new test LUN manually and have the same results (not able to select as an entity in the VSC backup job).
Also, when right-clicking on the newly created test LUN in vCenter and trying to use the Backup feature from the NetApp context menu, I receive an error (pic attached). This same error occurs when trying to do the same on the other two original LUNs in question (attachments 4 & 5).
I then tried to use the NetApp P&C utility and was able to successfully provision a new LUN / datastore (attachment 6), however, now even that one doesn't show up when trying to create a new backup job (attachment 7) and when trying to perform a manual backup as noted above, I receive the same error (attachment 8).
Confirmed LUNs are on the right side in the "Resources' view.
So the problem is not related to manual creation of datastores. Is it possible for you to upgrade to VSC 4.0 and see if it fixes the problem. I have seen the error in the screenshot before and upgrading to VSC 4.0 has fixed this for some.
I upgraded to VSC 4.0 in an effort to fix this issue but it did not. VSC 4.0 was recently installed across all vCenter servers in this environment since it's the only version that "officially" supports vCenter 5.