Topic
  • 4 replies
  • Latest Post - ‏2012-12-12T16:16:01Z by thomas.quadflieg
thomas.quadflieg
thomas.quadflieg
31 Posts

Pinned topic mapping problems with zEnterprise HWAdapter

‏2012-12-11T13:30:02Z |
Hello,

we are using zEnterprise HW Adapter to control our zBX virtual servers by AppMan. Currently, we have the following situation:
One virtual server (zdst005) is defect and does not start because of a zEnterprise microcode problem. As a workaround we renamed the defect virtual server (zdst005OLD) and created a new virtual server object (zdst005) with exactly the same attributes and started this new virtual server object.
From the zHMC / virtual server perspective the server starts and everything is OK, now.

But on the Application Manager site, we have a problem with mapping. AppMan still maps the (old) defect virtual server (zdst005OLD) to the running ALA node name.

This leads to the ugly situation, that all applications on the node are state "online", but the virtual server status itself is "not operating" ;-)
Unfortunately, we also are not able to stop / start this virtual server via AppMan.

We already changed the host ip for the defect virtual server in zHMC and restarted the eezhwadapter, but the problem still exists.

Do you have any ideas, what we can do to get out of this situation?

Thanks,
Thomas
Updated on 2012-12-12T16:16:01Z at 2012-12-12T16:16:01Z by thomas.quadflieg
  • IsabellSchwertle(IBM)
    4 Posts

    Re: mapping problems with zEnterprise HWAdapter

    ‏2012-12-11T16:08:02Z  
    Hi,

    interesting scenario :)
    SA AppMan solely maps based on the information it gets from zHMC - and it works like this:
    The eezhwadapter gets a list of hostnames from the automation J2EE framework and is asked for a mapping to virtual servers for those. Now it queries the zHMC Web Services API for Virtual Servers (or checks its local cache) and searches for a mapping.
    What I suspect from reading your description is that the zHMC returns two guests for the original hostname of zdst005 and our adapter takes the first one - which probably is zdst005OLD. We require unique hostnames for our setup and automatic mapping to work.
    Since you restarted the eezhwadapter, we can exclude a cache problem. I need the eezhwadapter trace to further analyze this and confirm my initial thought. Please set the trace level to max using cfgeezdmn and restart the eezhwadapter, then wait until you see the mapping in the Operations Console.
    Can you please send the files to me directly?
    Thanks a lot!

    Kind regards,
    Isabell
  • thomas.quadflieg
    thomas.quadflieg
    31 Posts

    Re: mapping problems with zEnterprise HWAdapter

    ‏2012-12-11T17:14:12Z  
    Hi,

    interesting scenario :)
    SA AppMan solely maps based on the information it gets from zHMC - and it works like this:
    The eezhwadapter gets a list of hostnames from the automation J2EE framework and is asked for a mapping to virtual servers for those. Now it queries the zHMC Web Services API for Virtual Servers (or checks its local cache) and searches for a mapping.
    What I suspect from reading your description is that the zHMC returns two guests for the original hostname of zdst005 and our adapter takes the first one - which probably is zdst005OLD. We require unique hostnames for our setup and automatic mapping to work.
    Since you restarted the eezhwadapter, we can exclude a cache problem. I need the eezhwadapter trace to further analyze this and confirm my initial thought. Please set the trace level to max using cfgeezdmn and restart the eezhwadapter, then wait until you see the mapping in the Operations Console.
    Can you please send the files to me directly?
    Thanks a lot!

    Kind regards,
    Isabell
    Hi Isabell,

    thanks for the fast response.

    I checked traceFlatHardwareAdapter.log and it tells me:

    +2012-12-11 17:30:57.876+01:00 EEZzEntHardwareAdapterPlugin cacheHardwareResources IBM SAAM hardwareAdapter lde5012q IP Multiple virtual servers have matched node name: zdst005.generali-gruppe.de. Virtual server previously known to match has URI: /api/virtual-servers/e311c008-7a71-11e1-8e0d-f0def11ccced. Virtual server that also matches has URI: /api/virtual-servers/a7318148-3797-11e2-a783-f0def11ccced+

    So, eezhwadapter found both servers.

    I tried to find out, why zdst005OLD still has attribute hostname = zdst005.generali-gruppe.de

    Actually, I cannot find any attributes that map the hostname zdst005.generali-gruppe.de to zdst005OLD.
    The IP-Adress which refers to this hostname was already changed for zdst005OLD under "Virtual Server Details" --> "Options" --> "IP address".

    I thought, that the hostname would be provided by GPMP. Is this hostname attribute cached on zHMC as long as the virtual server is "not-operating"? This would explain, why it did not change, because the virtual server is not startable...
    Or is there any caching of hostnames in EAUTODB at the AppMan site?

    I restarted eezhwadapter. The traceFlatHardwareAdapter.log is attached.

    Thanks,
    Thomas

    Attachments

  • IsabellSchwertle(IBM)
    4 Posts

    Re: mapping problems with zEnterprise HWAdapter

    ‏2012-12-12T15:32:05Z  
    Hi Isabell,

    thanks for the fast response.

    I checked traceFlatHardwareAdapter.log and it tells me:

    +2012-12-11 17:30:57.876+01:00 EEZzEntHardwareAdapterPlugin cacheHardwareResources IBM SAAM hardwareAdapter lde5012q IP Multiple virtual servers have matched node name: zdst005.generali-gruppe.de. Virtual server previously known to match has URI: /api/virtual-servers/e311c008-7a71-11e1-8e0d-f0def11ccced. Virtual server that also matches has URI: /api/virtual-servers/a7318148-3797-11e2-a783-f0def11ccced+

    So, eezhwadapter found both servers.

    I tried to find out, why zdst005OLD still has attribute hostname = zdst005.generali-gruppe.de

    Actually, I cannot find any attributes that map the hostname zdst005.generali-gruppe.de to zdst005OLD.
    The IP-Adress which refers to this hostname was already changed for zdst005OLD under "Virtual Server Details" --> "Options" --> "IP address".

    I thought, that the hostname would be provided by GPMP. Is this hostname attribute cached on zHMC as long as the virtual server is "not-operating"? This would explain, why it did not change, because the virtual server is not startable...
    Or is there any caching of hostnames in EAUTODB at the AppMan site?

    I restarted eezhwadapter. The traceFlatHardwareAdapter.log is attached.

    Thanks,
    Thomas
    Hi Thomas,

    thanks for the fast feedback!
    We discussed this internally, and what we're thinking at the moment is that zHMC still "remembers" the hostname of the old server zdst005OLD - and this is still zdst005.generali-gruppe.de - so you're suspicion below would be correct.
    We do cache hostnames in the EAUTODB, but those are cleared on eezhwadapter restart.
    We need to talk to zHMC development about this - will do that and send you feedback asap.

    While we do this - the trace you sent me seems to be wrapped around - I can't see the phase where the eezhwadapter has started. Can you please check whether there is another file available that contains events before 2012-12-11 17:30:48.910+01:00 EEZHardwareAdapterCmd main IBM SAAM hardwareAdapterCmd lde5012q IP Entry, parm 1 = -MONITOR?

    Thanks for your patience and support,
    Isabell
  • thomas.quadflieg
    thomas.quadflieg
    31 Posts

    Re: mapping problems with zEnterprise HWAdapter

    ‏2012-12-12T16:16:01Z  
    Hi Thomas,

    thanks for the fast feedback!
    We discussed this internally, and what we're thinking at the moment is that zHMC still "remembers" the hostname of the old server zdst005OLD - and this is still zdst005.generali-gruppe.de - so you're suspicion below would be correct.
    We do cache hostnames in the EAUTODB, but those are cleared on eezhwadapter restart.
    We need to talk to zHMC development about this - will do that and send you feedback asap.

    While we do this - the trace you sent me seems to be wrapped around - I can't see the phase where the eezhwadapter has started. Can you please check whether there is another file available that contains events before 2012-12-11 17:30:48.910+01:00 EEZHardwareAdapterCmd main IBM SAAM hardwareAdapterCmd lde5012q IP Entry, parm 1 = -MONITOR?

    Thanks for your patience and support,
    Isabell
    Hi Isabell,

    thanks for the response.
    I think, we have a very specific scenario here (zEnterprise Microcode defect in combination with AppMan zEnterprise Hardware Adapter). So -with regards to more important problems/RfEs- don't handle this issue with highest priority ;-)

    Regarding the trace file: I recreated the scenario and attached a new one.

    Cheers,
    Thomas

    Attachments