Datastore [datastore] conflicts with an existing datastore...

[MattGoddard]

Hi folks, I'm tearing my hair out over this one and I don't have much as it is, so I'm hoping you can help! Thus far, my googling has gotten me nowhere. (This involves Cisco UCSB-B200-M4 blades and a Nimble SAN, connecting via Fibre Channel.)

---

I'm in the process of moving six ESXi 5.5 hosts out of vCenter 5.5 and into vCenter 6.5, where I'm upgrading them to ESXi 6.5. No VM downtime is permitted. The problem is that when I try to add a host to VC 6.5, I get this error (for example):

Datastore 'MyDatastore' conflicts with an existing datastore in the datacenter that has the same URL (ds:///vmfs/volumes/58e7c84b-122de5b1-44be-0025b511a08c/), but is backed by different physical storage.

The error is wrong: there is no different physical storage involved here. The hosts are all members of the same initiator group on the same SAN, pointing to the same LUNs. Also, weirdly, this error only shows up when adding some of the hosts. And when it does show up, it consistently refers to same three datastores; the other datastores are apparently not problematic, for some reason.

Since I have plenty of redundancy on this cluster, I evacuated three hosts of their VMs, unmounted/detached/unpresented all the datastores, moved the hosts into VC 6.5, did a clean install to ESXi 6.5, then added the datastores back again. However, when adding the other three hosts I continued to get the same error.

Next step: since this is a datacenter-level problem, I created a new datacenter and added the other three hosts to it. I then tried to do a cross-datacenter vMotion to the upgraded hosts (I'm licensed for that, so that's not an issue). This produced a different (but probably related) error:

Unable to access the virtual machine configuration: Unable to access file [MyDatastore] MyVM/MyVM.vmx

So basically, vCenter still thinks the datastores on [host A] are different from the identical datastores on [host B]. So when it tries to vMotion and checks whether the destination host can see the VM's storage, the check fails.

Now I'm thoroughly stumped! What can I do to resolve this?

[Nawals]

In Both vCenter environment having same datastore name on hosts causing the problem.  Login into the individual host and rename the datastore and then try to add hosts. Make sure datastore name on hosts in vCenter should be unique. If not will continue getting conflict the name. In case both environment on hosts have unique datastore name then you need to follow this article for same issue.https://virtuallyvtrue.com/2020/02/21/datastore-conflicts-with-existing-datastore/

[MattGoddard]

Login into the individual host and rename the datastore and then try to add hosts.

Unfortunately, this isn't going to help as I would then end up with the same datastore in vCenter with two different names. This would prevent vMotion from working correctly for several hosts.

Whatever the solution is, the end goal needs to be for the VC 6.5 instance to allow all hosts to recognize all these shared datastores the same way, just as they do on the VC 5.5 instance. It's baffling because it *does* recognize some of the datastores that way; it's only three of them that are problematic.

https://virtuallyvtrue.com/2020/02/21/datastore-conflicts-with-existing-datastore/

That link describes a different problem: not being able to remove a datastore. It also involves VM downtime - removing VMs from the inventory - which is not an option for me at this time.

[sjesse]

Try following this guide

https://infosight.hpe.com/InfoSight/media/cms/active/public/pubs_VMware_Integration_Guide_NOS_50x.wh...

and make sure you resignture the datastore when you add it. Then migrate anything out of there if it works, then what I'd do is disable the problematic one and do a rescan of all hosts so it disappears. If it stays stuck you may need to do rolling restartings of the hosts, but normally putting the volume offline in the nimble array has worked for me in the past.

[MattGoddard]

https://infosight.hpe.com/InfoSight/media/cms/active/public/pubs_VMware_Integration_Guide_NOS_50x.wh...

This is a  promising workaround. However, as I understand it, it's not possible to disassociate a cloned Nimble volume from its parent, which would cause problems later on. Do you know if that's still true? (This is a Nimble CS700 running software version 3.9 - yeah, it's fairly old!)

Although I guess another solution might be to just to create three brand new datastores, storage vMotion the VMs there and hope that they don't also produce duplication errors later. That would take a long time though.

[sjesse]

Pretty sure you can't remove the parent relationship till, we use a nimble array in our DR vdi environment so I don't use I that often, but it was that case a few years ago when we ran one in our production VDI environment. Ours is in the 5 version level, and its not there. Its an option if you need the data and can't get the datastore to mount, just move the virtual machines out another volume, and then just deleted the parent and the clone.