Update VMware Data Adapter to use new xml file by replacing name in database possible?

[Kip_Lamb]

A customer is using the older version of the VMware data adapter and want to update to the new ESXi data adapters.

Is it possible to update the database for the data source params config to point to the new XML file?

The connection and server selects would be the same.

>KIP

[Legacy User]

Hi Kip

 

As we know, updating a data adapter XML definition file and restarting Tomcat will work.

 

However, if you are looking to do the opposite, I'm not 100% sure without testing, but here are some thoughts:

 

First question, what happens when you install the latest VMware solution kit?  Do you get a new set of datasource types, or are the definitions of the existing datasource types updated in place?

 

If the latter, there is nothing to do (beyond restarting Tomcat)...

 

If the former, my concern with your initial proposal to just change the reference to the XML file is that it will not respect the data source type.  Especially if there are new metrics or new maps in the XML, you may find that staging and / or migration will drop the new metrics.  Whether you would get errors or it drops them silently is an open question, as this is really going around the guard-rails that the gui enforces.

 

If we continue with the assumption that when you load the latest versions of the DAs, you will get a new set of datasource types, I think that your safer option is to change the datasource type within each of the datasource instances, rather than change the XML file pointed to by the datasource type itself.

 

Hope that makes sense - let us know how you get on if you choose to try it...

 

Adrian Johnson

CA Technologies

 

Office: [phone] | Mobile: [phone]

[Legacy User]

Hello, Adrian and Kip...

• I am the one who posed the question. I am not sure if this will help... I realize that I out of my league, so please be patient.
  • I would not expect existing rows in SERVER_FACT to be updated.
  • What I am hoping is that by changing TYPE_ID in the DATASOURCES_CONFIG table for the data sources in question from 24 (VMWARE_VC40_Weekly) to 100223 (VMWARE_ESXi_Weekly), all subsequent loads would pull the ESXi data. (I am not sufficiently familiar with the differences between the two TYPES to know the impact that this would have on the transformed data.
  • I am also hoping that this is the only place that TYPE_ID would need to be changed.
• I should add that for VMWARE data we are pulling CPU, Memory, Datastore, Resource pool and Cluster metrics... not Disk or Network. If this works, and it does not disrupt the semantics of the resulting data, I will discuss the possibility of doing a global change across all records in DATASOURCES_CONFIG.

[Legacy User]

Clarification: " global change across all records in DATASOURCES_CONFIG" should read, "change TYPE_ID = 100223 for all records in DATASOURCES_CONFIG where TYPE_ID = 24"

[Legacy User]

I am still awaiting a reply on this...

• Do we know who within CA is the SME regarding the Data Manager DB?
• We will work on our end to ferret out the relative value of the ESXi metric over the VC40 metric (i.e., is this change even necessary?)
• We can try to change the SOURCE_TYPE_ID on one or two of our Data Sources to see whether it works.
• We would prefer to have CA's insights before proceeding much further.

[Legacy User]

There are a few in Services that have done extensive research into the Data Manager Schema.

 

There are many dependencies between the XML data adapter Table(SOURCE_TYPE_CONFIG) Column(TYPE_ID) and the Metric_Names that are loaded into DM by that data adapter.

 

Recently I found that it goes even deeper than just the STD_NAMES for each Metric.

For metrics to be loaded into Data Manager there requires a match of the "SRC_NAME" and the "STD_NAME" for a specific "METRIC_SOURCE", which are columns found in the "Metric_DIM" table.

 

So if one metric being loaded by a data adapter doesn't match exactly on 3 fields, it will not be loaded by the data adapter into the DM fact tables.   One of our older VMWARE data adapters has an error like this in the "SRC_NAME" and so that one metric has never been loaded...it was fixed in a newer version of the data adapter.

 

There are other tables where the Metric_Dim_ID must be added so the metrics are Rolled up into Hourly,Daily, and Regression tables.

 

The risk of causing a problem that will go un-noticed for 3 months is VERY high if you implement your method.

- by the time you find the problem, the complete Database may be compromised.

 

While the implementation is harder, I recommend that you use the approach below:

1. Install the newest VMWARE ESXi data adapters, via a Solution Kit.
2. Add a new Data Source for each.
3. Add a new Scheduled Load for each.
4. Then disable the old scheduled loads.
5. In CCC adjust the PRIORITY of the DataTypes so that the new VMware Data Adapter is HIGHER than the old VMware Data Adapters.. . (SAVE the changes).

 

David - one of the services team who has worked with Data Manager since it was developed.

[Legacy User]

David - Thank you for your reply... and for your assurance regarding your background.

We have 50+ data sources encompassing 400-500 servers. If we are successful, it will be big win for us.

I will proceed with caution, document our steps, test it out and let you know how we make out.

Bill Brown

[Legacy User]

With the wild cards you can have one data adapter pull in all the ESX hosts for a single VCenter in blocks defined by a parameter in Data Manager.

 

Are you using one data adapter per Vcenter database?

 

David

[Anon Anon]

Kip_Lamb  hey Kip, do we need more discussion on this ?  not sure if resolved....

[Dirk Bleyenberg]

Hi Kip

 

Is there anything else you need to discuss for this thread

 

Cheers

 

Dirk