Duplicate entry '11' for key 'PRIMARY'

[kleemola]

I've been getting a recurring error which prevents my vcenter data source form loading.  The apparent source is a duplicate row in the vc.lun table.  Anybody else having similar errors?

Geoff

[girirp]

Hi Geoff,

What is the vCenter version you are using ? WFA supports only vCenter 4. Please have a look at Jira WFA-5215

Thanks

Giri

[kleemola]

I am using vCenter 4.0.  However, I have also used 5.x as a data source.  With both, this was the only issue I have encountered.

[goodrum]

I have seen this type of error when the native datastore in the vSphere hosts are all the same name.  The issue is a configuration in the vCenter database.  Since WFA uses the Lun ID as the primary key, it is going to through an error.  Personally, I don't think that the primary key should be based on a Lun ID.  Two storage controllers are able to present the same Lun ID to the same set of hosts and this is perfectly acceptable.  I haven't run into an issue in my testing of the Pirate Pack with multiple Luns of the same Id.

You can see which Luns are duplicated by running the sql command used by the caching table on the vCenter database directly.  This will give you the entries that are duplicated.

[yaronh]

Jeremy is correct.

We will release an updated query that would fix this situation tomorrow.

When you install an ESX server – the space left on the disk (after the used space for the installation is taken) can be used for a local VMFS datastore which usually customers use

For ISO files or just leaving them empty.

In most cases these would not be used for new VMs and thus might not be needed at all.

What's your take on this??

Best,

Yaron

[goodrum]

I agree that not having the local datastores selected would be ok... but there is something else to potentially consider.  If the customer is using WFA to migrate Virtual Machines from the local datastore to a remote datastore, then the local datastore would need to be available for selection.  The only unique identifier for a Lun is the NAA.  Two different storage arrays (same or different vendor) can present luns to the hosts with the same id.

Just my two bits... This should also eliminate an issue with the duplicate and the local datastore.

[yaronh · Accepted solution]

Hi Geoff (et all),

As conveyed via email, we have successfully tested a fix for this issue in our labs (Based on another customer backup).

What did we fix?

Cache query for Vcenter luns was updated. We found that in some cases when an ESX is being set up,

the local disk (The remainder not currently used) can be established as a local VMFS datastore (There's a check-box

to handle it during the set-up).

The local disk consoleDeviceName is populated in runtime, our query considered them as the same lun, which is not the case.

Since these datastores are most likely not used for operations (ie creating VMs on them) we elected to exclude those from

the datastore list at the moment.

What to do?

Go to the backup & restore page (Via the top-left “Tools” menu), select the attached file and

restore it. Try to acquire again and it should work (I tested this with a backup from Tom’s machine).

Note: A cache reset may be required. If you encounter a message stating "Unknown database vc" on acquisition,

you should right-click that data-source, right-click the "vc" caching scheme at the bottom part of that dialog and "Reset the cache".

Going back to the data source screen will show that clearly ("VC (reset)").

On the next attempt to acquire it will be reset and all will be well.

Please let me know if you require further assistance.

Best,

Yaron Haimsohn

WFA Team