Has anyone experienced that after a vCenter 5 upgrade all datastores are renamed with “(1)” added to the datastore name? It happened to both all local stores and iSCSI stores. Any know what happend?
Name before upgrade: ”cen-sa-emc-01-vmfs05”
Name after upgrade: ”cen-sa-emc-01-vmfs05 (1)”
vCenter upgrade was done from vCenter 4.1U2 to v5 build 455964
This can happen if you mount the datastores under multiple names on different hosts. The mounts have to be EXACTLY the same. Don't even mount from Nas01.example.com and nas01.example.com and expect vSphere to figure it out even though they resolve to the same IP address.
Did you run the upgrade checker before you did the upgrade? I think it catches stuff like this.
I did run "Host Agent Pre-Upgrade Checker", and had all host compliance without any errors. And of course I understand that same name need to be used for datastores on different hosts. As we not running any NAS or NFS stores but only iSCSI, all stores had identical names. And that would not explain why it would rename the local stores as they only exist on that specific host.
I typically only see the (1) appended when a datastore exists and another is added with the same name. This is common for local storage, which is why you get a datastore, datastore (1), etc. when adding fresh ESX hosts.
As to -why- that specifically happened when you upgraded, I'd suggest grabbing the logs and submitting to support to see if there's a bug. I know there is already an iSCSI bug floating around that was patched on the host (ESXi) side, but haven't heard of anything on the vCenter side.
I would understand if any of the stores was name by default that it renamed the datastore name but we have a namestandard on local stores aswell, for examle host_localstore_01, that is uniqe to every host.
Seen that iSCSI bug aswell, but as you saying its releated to ESXi host and not vCenter.
I try to contact support and ask what happend, thanks.
I just upgraded to vSphere 5 across the board as well and see the same exact bahavior with my datasotres. They have all been appended with a (1). All datastores have identical names across hosts, and I don't see a reason for it. What's also interesting is that I'm unable to rename the datasotres back to their original names, and wen I attempt to view datastores in the storage view using a map, I get an error stating An internal error has occurred: Failed to serialize response. I know that's a topic for another thread, but it may help. Anyone have ideas?
Exact same thing on all the Datastores. Local, ISCSI and FC over 3 DC controlled by the vCenter server that was upgraded.
I can rename my Datastores to their original name (remove the (1)) without problem though.
Another thing I have noted is that the Datastores with a template on them have duplicates, one that works (renamed with (1) the other that kept the original name, only has the templates and the store path is sanfs://vmfs_uuid... is empty.
Same issue on our upgrade this weekend. It did not hurt the VMs. However if you are using VMware View it breaks all of the pools because the datastores no longer exist. You have to go in and re-list them all. My fear of renaming all the datastores back to the original name was I did not want to take the chance that the vmx files might get confused.
Has anyone opened a case with VMware on this? If so please post thier results, if not let me now and I will. Seems like a bug.
I upgraded 2 farms from 4.0 u2 to version 5. First farm upgraded fine - no issues. 2nd one had issue described in this post - all datastores were renamed to x (1) and datastores with templates on them had 2 instances (where the x was inactive and x (1) working and available). I was able to rename all the (1) datastores to the original names that did not have duplicates. With the inactive unmanageable datastores I recorded the templates on them and then removed them from the VC inventory. As soon as they were removed from VC the corresponding inactive datastores disappeared automatically. I was then able to rename the remaining datastores to their original names.
I also upgraded from vSphere 4.1U2 to vSphere 5.0 and have experienced the same issues (those being the (1) appended to each datastore name and a duplicate datastore containing only templates with the sanfs:// prefix). I managed to rename all the datastores OK and as soon as I removed all the templates from inventory the sanfs:// datastore was removed automatically.
I am unable view storage maps - I receive the error "An internal error has occurred: Failed to serialize response" (see attached .png).
VMware has to post some soft of KB article on this. I have to admit that the upgrade from vSphere 4.1U2 to 5.0 has been nothing but a headache, nothing like moving from 4.0 to 4.1.
I opened a ticket with VMware in regards to this issue. This is the reply I initally received from the tech:
"This issue usually happens when there are orphaned templates or orphaned view replica VM's. Before upgrade to vSphere5, either unregister all the templates from the virtual center or unprotect all the orphaned replicas from the virtual center. Even after upgrade which caused the duplication of the datastore, unregistering the templates or replicas and doing a rescan will make the duplicate datastores to disappear from inventory. To unprotect the orphaned replicas, Please follow the below mentioned KB article."
This is part of the answer as I did have the issue with the templates. This did not, however, answer the question about why ALL of the datastores were renamed. The tech could not reproduce the problem but is aware of all of the posts in the community and they are looking into it. We assume it must have something to do with the database upgrade portion. Unfortunatley I did not have a log of the upgrade since it is deleted when you reboot theVsphere server. The logs are in the temp folder (Maybe they need to put them in another folder so they do not get removed on reboot [dbupgrade.log])
Anyway, no answer form me or VMware as of yet. If anyone figures out what happend please post!
I have performed 10 upgrades to vCenter 5 in 10 different environments (FC, iSCSI, NFS) and I would say that about 8 of the 10 environments ended up having all their datastores renamed with "(1)" at the end. In only 1 or 2 cases was there an "orphaned" template, and in none of the cases were there NFS datastores with different IP addresses. Fortunately in all cases I was able to rename the datastores to their correct name without any problems, even in the View environments. But it's still very odd that it happens in the first place.
The link does not address how to resolve the Map view errors “An internal error has occurred: Failed to serialize response.”
Do you know how we can resolve this? I have seen the link below.
This message is found in the release notes:
With software FCoE enabled, attempts to display Storage Maps fail with an error message
This problem affects only those ESXi hosts that have been added to vCenter Server without any previous software FCoE configuration. After you enable software FCoE adapters on these hosts, attempts to display Storage Maps in the vSphere Client fail. The following error message appears: An internal error has occurred: Failed to serialize response.
Workaround: Configure software FCoE on the ESXi host first, and then add the host to vCenter Server.
Maybe this resolves your problem?
Just have my vCenter 4.1 upgraded to 5, and the same thing happened to my datastores. And when I tried to rename it by removing those "(1)", only some worked, while the rest said The datastore 'datastore name' already exists. In the Datastores and Datastopre Clusters inventory view, I found inactive datastores. These are the datastores that I couldn't rename it back to what it was before the upgrade. After restarting the VC service, the "inactive" status is gone, although the number of hosted connected to it is zero. This is the only place I can see it. I can't see it through SSH, or vSphere client to host directly. I renamed it to something else, so that I could rename those LUNs ending with "(1)" to its original names. Looks like it is something hanging around in database. And I cann't find a way to delete it.
I organized them into folders in the Datastore Inventory view, and they are no longer in those folders after the upgrade's (1) rename.