Effective December 3, NetApp adopts Microsoft’s Business-to-Customer (B2C) identity management to simplify and provide secure access to NetApp resources.
For accounts that did not pre-register (prior to Dec 3), access to your NetApp data may take up to 1 hour as your legacy NSS ID is synchronized to the new B2C identity.
To learn more, read the FAQ and watch the video.
Need assistance? Complete this form and select “Registration Issue” as the Feedback Category.

Active IQ Unified Manager Discussions

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

1 ACCEPTED SOLUTION

yaronh

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

View solution in original post

6 REPLIES 6

yaronh

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

View solution in original post

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.

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.

Announcements
NetApp on Discord Image

We're on Discord, are you?

Live Chat, Watch Parties, and More!

Explore Banner

Meet Explore, NetApp’s digital sales platform

Engage digitally throughout the sales process, from product discovery to configuration, and handle all your post-purchase needs.

NetApp Insights to Action
I2A Banner
Public