Unsolved
This post is more than 5 years old
4 Posts
0
29607
Non-Inventoried Systems on OME 2.1
I've done some googling around, and haven't found a satisfactory answer..
We have ~15 servers that are discovered, but will not inventory, this is out of about 500.
The main ones I'm focused on, that are giving me issues all run XenServer 6.2, running OMSA 7.4. That said, we have roughly 90 servers that fit this description, and of those 90 a total of 5 show up under Non-Inventoried.
Discovery is via SNMP, I can run the SNMP test and return System Name, OMSA version(7.4.0), SM version(4.4.0), and the invcol version (7.4.1 BLD_273). Under the Manage -> Devices tab, the server is not under warning or error, and I can see proper Device Summary, OS Information, etc., and all is accurate, however under Manage -> System Update, it will remain under Non-Inventoried. This has an identical setup to a neighbor machine (same hardware, same software) which has been inventoried fine (it actually has 6 neighbors with same hardware/software, that are all inventoried correctly).
Thoughts?
DELL-Martijn G
291 Posts
0
October 26th, 2015 05:00
Are you only inventorying those machines through the XenServer OS or also through the iDRAC?
Officialy we don't support the inband upgrade through XenServer:
Added the protocol support matrix just in case:
schplat
4 Posts
0
October 26th, 2015 11:00
I got a reply that went to my email, but didn't show up here.. And I can't reply to the email so..:
> Are you only inventorying those machines through the XenServer OS or also through the iDRAC?
I've tried both. However, it shouldn't matter when I have all the neighbors working and 85/90 total working. This is a total one-off incident here, where everything has been setup the same.
DELL-Vijay B
183 Posts
0
October 26th, 2015 13:00
Thanks for the update.
Are you seeing the software inventory section when you go to the device details page in OME for that affected machine.
If no, can you try restarting the OMSA services on that server and perform a re-discovery in OME. If you are using only iDRAC, good to double check CSIOR is enabled.
Let us know if this helps in identifying your problem.
Thanks,
Vijay
schplat
4 Posts
0
October 26th, 2015 14:00
Very odd.. It worked this time. This server even went through a reboot yesterday, and wouldn't inventory. I'm pretty sure I had done the same restart OMSA re-discover, but no go. Maybe deleting it from OME changed something (but thought I had done that before too).
I'll give this a try on the other Non-Inv'd systems, see what happens.
schplat
4 Posts
0
October 27th, 2015 12:00
I'm not trying in-band upgrade, I just want it for seeing what patches are needed. I can then download them onto the server and install them as necessary.
Why in-band upgrades are Not Supported here is weird in itself. Since it's supported on RedHat (and XenServer is a Redhat Kernel). The method it uses to apply in-band updates on Redhat is the same you use on XenServer (scp/ssh), it uses the same .BIN files to perform the updates. The only issue you run across is the disk space limitations you potentially run across on DOM0, since it's limited to 4G. If you have a lot of logs, you could see as little as 512M of free space, or less.
DELL-Pupul M
1K Posts
0
October 28th, 2015 01:00
Hi,
The way OME performs inband update is through OMSA. There is some difference between OMSA system update support on Xen server and RHEL.
It is not something which cannot be done but would be a new requirement. Please keep it coming and we will look at it on what could be done about it..
As of now, if you just want to verify what updates are needed on the server, you can use iDRAC update method comparison report by performing an iDRAC WSMAN discovery+inventory. That would provide you packages for update through iDRAC. The same package will have a bin as well if you really want to perform the updates manually. Though OME gives you the liberty to perform system update on this server through iDRAC currently.