This message indicates that the data_engine is unable to insert a QoS sample into the database because the attributes of the sample and the attributes of table do not match. Typically, the mis-match is due to the samplemax column.
Some QoS, such as CPU usage, has a natural samplemax of 100%. Other QoS, such as url_response does not. The probes publish two kinds of QoS samples -- those with samplemax and those without. The probe also publishes the table definition when it begins a new series. So, in principle, the definition will establish the proper table and the samples will match the definition. A few of the probes allow the admin to change the definition of the maximum or setting the maximum. (The flag internally is known as "hasmax"). If hasmax is set, then the sample will contain a samplemax column. The problem here is that either the sample contains a samplemax value but the table does not contain the column or vice versa. The sample is dropped on the floor and the data_engine continues. It drops the qos because samplemax is missing on the pds packet usually an old version of the probe causes this, e.g., vmware. It has to do with a problem with QoS definitions overlapping between vmware and CDM probes. These errors are actually from the vmware probe, see the errors showing Guests/Hosts references below:
Dec 22 12:48:39:275  de: QoSInsert::CheckDataIntegrity - message dropped; samplemax is missing. qos=QOS_MEMORY_USAGE source=PHLEGALKEY (NEW LegalKey) target=GuestMemoryUsage Dec 22 12:48:39:275  de: QoSInsert::CheckDataIntegrity - message dropped; samplemax is missing. qos=QOS_MEMORY_USAGE source=PHEXMB01 target=GuestMemoryUsage Dec 22 12:48:39:282  de: QoSInsert::CheckDataIntegrity - message dropped; samplemax is missing. qos=QOS_MEMORY_USAGE source=virtualcenter target=SRSY-Philadelphia.PHL.Resources.MemoryOverallUsage Dec 22 12:48:39:290  de: QoSInsert::CheckDataIntegrity - message dropped; samplemax is missing. qos=QOS_MEMORY_USAGE source=PHEVDA01 target=GuestMemoryUsage Dec 22 12:48:39:290  de:
To work around these what you'll need to do is go into the vmware.cfg and find the appropriate QOS, and change "hasmax=no" to hasmax=99999999999999. This will basically 'disable' the behavior, as the number is so high it will never be reached, but this probe doesn't really "do" anything with that number -- data_engine just expects it to be populated with "something". for example: name = QOS_MEMORY_USAGE desc = Memory Usage unit = Megabytes abbr = MB group = QOS_MACHINE hasmax = 999999999999 isbool = no asynch = no Or upgrade your older vmware probes to the later/most recent version.