error after updating from 0.99a to 0.99c #87
Comments
|
could you send us the ViPullStatistics.pl log file so we can have a look? |
|
Sure, here's a recent snippet: [2016/08/27 19:50:05] /root/ViPullStatistics.pl line152 - [INFO] Processing vCenter vc01xxx.mgmt.company.com clusters in datacenter xxx The first line (vc01xxx) is the troublesome one where we aren't getting the VM data that we'd like. I think it's getting to that step in the "standalone hosts" section and failing but obviously the log output isn't particularly effusive there. Thanks! |
|
Any thoughts on troubleshooting? |
|
the error is at the end or at the begining ? |
|
The end. I could isolate the issue a bit by disabling polling for the other clusters and just try the troublesome one if that log output would be more valuable? |
|
sure, anything
|
|
Here's two polling cycles: [2016/09/01 23:00:01] /root/ViPullStatistics.pl line60 - [INFO] Start processing vCenter vc01xxx.mgmt.company.com |
|
is there any non-alphanumeric characters in one of the the cluster's name? |
|
Nope. The only cluster in that vCenter is named 'pod3' |
|
and the datacenter name?
|
|
It's a 3 letter airport code like 'jfk' or 'lax'. It's named very similarly to the other clusters that aren't having the issue. There are a lot of VMs with parenthesis and dashes and that sort of thing, but that also exists on the other clusters as well so even after searching for something out of the ordinary, I haven't found anything unique yet. |
|
any vm or datastore name that is "anormaly" long? |
|
No datastore names longer than 5 characters. The VM name is interesting. This is a vCloud environment (as all our others are), so VMs are saved in vApps with very long paths like 'customeridnumber-customernamethatcanbelong-vdc/vappidnumber-customernamethatcanbelong-computerhostname (very long guid that is 36 characters)/vmidnumber-customernamethatcanbelong-computerhostname (very long guid that is 36 characters)' It's important to note that I just went through and verified that no individual VM name is longer than 90 characters, but if you add the full path together, I could see how it could get above 256 characters. Just not sure if that's what the code is looking at or if it is truly just VM name. Also, our other datacenters have much the same patterns but I'd have to write a script to find the longest vm or path names to see if this troublesome cluster has longer names. Moreover, the older version of sexigraf didn't have this issue either so I'm still kind of stumped. |
|
It makes sense because the previous version did not include vm stats so the path length of the vms was not an issue. From: wifinerd [mailto:notifications@github.com] No datastore names longer than 5 characters. The VM name is interesting. This is a vCloud environment (as all our others are), so VMs are saved in vApps with very long paths like 'customeridnumber-customernamethatcanbelong-vdc/vappidnumber-customernamethatcanbelong-computerhostname/vmidnumber-customernamethatcanbelong-computerhostname' It's important to note that I just went through and verified that no individual VM name is longer than 90 characters, but if you add the full path together, I could see how it could get above 256 characters. Just not sure if that's what the code is looking at or if it is truly just VM name. Also, our other datacenters have much the same patterns but I'd have to write a script to find the longest vm or path names to see if this troublesome cluster has longer names. Moreover, the older version of sexigraf didn't have this issue either so I'm still kind of stumped. — |
|
Ah yes, well that does make sense. I would like VM stats if possible, of course, as that was my primary reason for upgrading. :-) |
|
Thanks for all the attention on this, guys. I quite like Sexigraf and I very much appreciate all the work you've put in. |
When viewing the ViPullStatistics.pl log, I am getting this error just before it's about to run the "Processing vCenter vcxxxx.xxxxx.com standalone hosts in datacenter yyyyyy" step.
/usr/lib/x86_64-linux-gnu/perl/5.20/IO/Socket.pm line284 - DIE Wide character in send at /usr/lib/x86_64-linux-gnu/perl/5.20/IO/Socket.pm line 284.I have the original appliance, which was updated to 0.99a and then today directly to 0.99c. The cluster that is failing to run as a result of that error does not show the proper number of VMs in it's inventory list, so my guess is that there is something weird about one of the VMs it's trying to inventory (maybe too many characters?). But we have a few other clusters running the exact same versions with the same long file names throughout and no issues with reporting on those.
Thanks for any assistance!
The text was updated successfully, but these errors were encountered: