Description of problem: The idea of binding JON Agent identification to a [Agent Name | hostname], ip address and security token during Server<->Agent registration is no longer good enough when monitoring cloud instances. Cloud providers typically define a cloud profile/image to be a precise bundle of packages and configurations to be reliably created and destroyed on demand. The specific hostnames and ip addresses used by cloud instances are treated as transient identifiers and are frequently recycled/reused and forgotten with each restart/re-provision. *Note for this use case the JON Server is assumed to be a static/unchanging dedicated instance with the same hostname and ip throughout.* This means that to monitor the same 'class' or profile of cloud instance between multiple reboots or re-provisions involves a series of cumbersome steps: i)explicitly name each Agent instance ii)after successful registration of the agent with a static JON server, the agent security token in the (~/.userPrefs/rhq-agent/default/prefs.xml) needs to be saved off for use during successful reincarnation. iii)The previous two components needs to be stored off on an external machine and additionally associated with the same class of cloud instance. If there are multiple instances of the same profile for load balancing then repeat the first two steps N times. iv)During reincarnation and before agent startup the agent-configuration.xml must be modified to include the previous Agent Name and the previous agent security token from step ii. At this point you should have a consistent resource history, through cloud re-provisions, assuming you do not ever run with -cleanconfig or lose your security token through some other means. I think this process is too cumbersome and we should enhance the Server<->Agent registration process to additionally look for client certificates in agreed upon locations before defaulting to traditional registration. In such a case on a provisioned cloud instance, the RHQ Agent would use a client certificate to be a single secure identifier to reliably generate i)unique repeatable Agent Name and ii)the same 'security token' through N different re-provisions/reincarnations. The JON server would have to be modified to accept these client cert 'security tokens' instead of generating new tokens along with a few additional changes to ensure security. I think this enhancement would be an elegant solution to many of the issues alluded to in the following links: - http://community.jboss.org/thread/157005 - https://fedorahosted.org/pipermail/rhq-users/2011-May/000388.html - http://www.rhq-project.org/display/JOPR2/Running+RHQ+in+EC2 Version-Release number of selected component (if applicable): 3.0.1 How reproducible: N/A Steps to Reproduce: 1.N/A 2. 3. Actual results: N/A Expected results: N/A Additional info: