Active IQ Unified Manager Discussions

OCI 7.3 ESX Hosts and virtual Adapters

sstrznwra
5,043 Views

Hello,

 

when I create a new Kernel Adapter(iSCSI) on ESX Host, the Host goes inactiv in OCI Java GUI and come back as new Host.

Why ? 

We use a Business Entity Structure and the Host lost the BE assignment and all annotations , applications.....

and we must Reassign all 170 esx servers. Smiley Frustrated

 

Is it possible to report virtual Adapters(iSCSI) from ESX Hosts in OCI DWH ?

 

Thanks

Michael

 

 

1 ACCEPTED SOLUTION

hotz
5,029 Views

Hi Michael,

 

This is pretty inconvenient, indeed.

In a world of many technologies I suspect it makes sense to look for the lowest common denominator. What I'm saying is, that since OCI has the capability to discover both hypervisors and non-hypervisors as far as physical hots are concerned, the lowest common denominator to keep track of both types of hosts the same way is their IP(s).

You can see this if you carck open one of OCI's vCenter recordings, which you can find in the ..\SANscreen\acq\log folder. Look for a file "foundation_<vcenter_datasource_name>_xxx_xxxx_xx_xx_xx_xx_xx_xxx.zip".

In this file, within the numeric folder, you should find the odata xml, which is a representation of the OCI data model.

Take the very first host at nearly the top of the file as an example. the OID is the OCI unique identifier of the host. As you can see it's IP addresses.

The recording file recording_<ip_address>.txt in the same numeric folder is the representation of the raw data that has been collected by OCI.

So taking the first host from the odata file, you could do the following on a bash prompt in order to verify it against the recording (the recording is a bit hard to read, so I prefer to use the bash prompt a lot for this sort of thing): grep <hostname> recording_<ip_address>.txt | sed 's/></>\n</g' | grep "\(HostSystem\|hostName\|ipAddress>1\)"

This should give you just the system name, the host name and any IP addresses for that host starting with 1- like 10.10.10.1 or 192.168.0.1

Anyway, plugging in a new kernel adapter means you'll have new IP addresses and OCI needs to re-identify the host.

View solution in original post

4 REPLIES 4

hotz
5,030 Views

Hi Michael,

 

This is pretty inconvenient, indeed.

In a world of many technologies I suspect it makes sense to look for the lowest common denominator. What I'm saying is, that since OCI has the capability to discover both hypervisors and non-hypervisors as far as physical hots are concerned, the lowest common denominator to keep track of both types of hosts the same way is their IP(s).

You can see this if you carck open one of OCI's vCenter recordings, which you can find in the ..\SANscreen\acq\log folder. Look for a file "foundation_<vcenter_datasource_name>_xxx_xxxx_xx_xx_xx_xx_xx_xxx.zip".

In this file, within the numeric folder, you should find the odata xml, which is a representation of the OCI data model.

Take the very first host at nearly the top of the file as an example. the OID is the OCI unique identifier of the host. As you can see it's IP addresses.

The recording file recording_<ip_address>.txt in the same numeric folder is the representation of the raw data that has been collected by OCI.

So taking the first host from the odata file, you could do the following on a bash prompt in order to verify it against the recording (the recording is a bit hard to read, so I prefer to use the bash prompt a lot for this sort of thing): grep <hostname> recording_<ip_address>.txt | sed 's/></>\n</g' | grep "\(HostSystem\|hostName\|ipAddress>1\)"

This should give you just the system name, the host name and any IP addresses for that host starting with 1- like 10.10.10.1 or 192.168.0.1

Anyway, plugging in a new kernel adapter means you'll have new IP addresses and OCI needs to re-identify the host.

ostiguy
5,024 Views

The root cause of what is happening here is that the unique identifier OCI is generating for the hypervisor is changing because the IP addresses are changing.

 

On x86 servers, there is really no such thing as a serial number - you cannot trust BIOS serial numbers (a lot of whitebox server makers ship 123456 as the serial number.... thanks guys!), so generating a reliable unique key for a host can be tricky.

 

If we used wwn, iqn or mac address, those could change the UUID when hardware failure + replacement cycles occur.

 

Just curious - what version of OCI are you running?

hotz
5,017 Views

 Matt, it says "OCI 7.3" in the title of this thread.

ostiguy
5,013 Views

I think I need to switch to a 4 day work week

Public