[Sblim-issues] [ sblim-Bugs-1565458 ] gather: CIMOM crashes on gi of invalid xen metric instance

[SourceForge.net <no...@so...>]

Bugs item #1565458, was opened at 2006-09-26 04:11
Message generated for change (Comment added) made by mihajlov
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=712784&aid=1565458&group_id=128809

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Provider
Group: Function
Status: Open
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Gareth S Bestor (bestorga-oss)
Assigned to: Viktor Mihajlovski (mihajlov)
Summary: gather: CIMOM crashes on gi of invalid xen metric instance

Initial Comment:
Running Xen metrics against Director tier 1 agent (aka
Pegasus 2.5).

This is a copy of CMVS defect 79896

-------------
    <Note by tokunbo (TOKUNBO ADESHIYAN), 2006/09/25
18:34:26, seq: 1 rel: 0  action: open>
This defect was observed while running CAM.  The CIMOM
crashed when a request for metrics, more specifically, the 
ExternalViewTotalCPUTimePercentage metric, was made. 
It appears that as soon as a VM is powered on, it does
not necessarily 
have all of the metrics available to it.  It appears
that this crash can occur with any metric that does not
exist.  To 
reproduce, just do a GetInstance of
Linux_XenMetricValue and supply a bogus value for
InstanceID.  For example:

#CLI gi -n root/ibmsd
'Linux_XenMetricValue.InstanceID="ExternalViewTotalCPUTimePercentage.180.<non-existent_VM>.
Note from Wayne to VSM GUI developers:

Dan, George,

Toks looked at the problem we were having on CAM with
the CIMOM crashing.  The scenario on CAM is that it had
a script that did an xm list and then it immediately
asked for the SBLIM metrics.   

The CIMOM will crash apparently under two scenarios:

1.  The virtual system does not exist and a metric is
requested.  I don't think this would be a problem on
VSM since it knows the VSes for which it is getting
metrics exist, unless there is a potential issue on a
delete.

2.  The VS exists but the metric is not yet there.

During a create of a VS, there is a period of time
where the VS exists, but the metrics may not yet be
present.  This makes sense, but, apparently, if the
metric for that VS is requested before it is there, the
CIMOM crashes.  This could be a problem on VSM, but I
do not know what the window might be.  How soon after a
create, do you get the metrics for the web UI?  I would
assume almost "immediately" but one would think that
the interaction between the server and agent would be a
sufficient time lapse.

Although we had not completely investigated the CAM
problem on Friday, #2 is why I asked the testers this
weekend to be particularly observant about any crashes
coincident with CreateVS on the web UI.

There is more investigation that is required, but I
wanted to send a note asap to see how exposed we are.

Wayne
---------------------

----------------------------------------------------------------------

>Comment By: Viktor Mihajlovski (mihajlov)
Date: 2006-10-27 13:04

Message:
Logged In: YES 
user_id=1198711

After some investigations, I found that two kinds of
problems can potentially occur:
a) the metric value id has a valid format, but the
repository doesn't find the matching instance
b) the metric definition/value id is invalid

Regarding a)
1. The providers for MetricDefinition and MetricValue don't
report a CMPI_RC_ERR_NOT_FOUND in this case. This seems to
confuse Pegasus. I didn't see the crash but experienced a
hang situation. This is a robustness issue and will be fixed.
2. I am wondering how you can run into such a situation. Are
you constructing an metric value instance object path in the
client? This would not be a valid approach, because a client
may not make any assumptions about the metric value
identifier structure. Rather use an associators call on the
metric definition instance in order to obtain metric values.

Regarding b)
1. There's a missing check in the utility library, which is
a robustness issue and will be fixed.
2. see above

----------------------------------------------------------------------

Comment By: Oliver Benke (obenke)
Date: 2006-10-09 17:40

Message:
Logged In: YES 
user_id=1458587

Viktor - I just verified this problem on my Xen system. It
seems to me that whenever the object path of a
CIM_BaseMetricValue or the object path of a
CIM_BaseMetricDefinition instance is incorrect (rrepos_get()
returns 0), Pegasus crashes.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=712784&aid=1565458&group_id=128809