HEAT Discovery - When a virtual machine is cloned the ClientID may be duplicated

Version 1

    Details

    When a virtual machine is cloned the ClientID may be duplicated causing an update to the same CI record within HEAT


    Resolution

    In some virtualized environments the ClientID of a discovered device may be duplicated if the UUID of the virtual machine and digest of disk model/serial number will match if using clone options or copy options to create new virtual machines within an environment.


    The following are options to generate a new ClientID for discovery use by modifying the C:\Program Files (x86)\Frontrange Solutions\InventoryClient\AUDIT\client.xml file:


    [UUIDforClientId]

     

        <at n="Global/Generic/Enable/UUIDforClientId" v="0" />

     

    This setting will stop the client agent from ever using the motherboard UUID for the client id.

     

    The effect it has on the list of possible client id sources:

     

    1. DISABLED: Motherboard UUID + digest of disk      model/serial number
    2. DISABLED: Motherboard UUID alone
    3. Digest of computer make, model and      serial number + digest of disk model/serial number
    4. Digest of computer make, model and      serial number alone
    5. Digest of disk model/serial number      alone
    6. The client id already present in      local.xml
    7. A “random” number

     

    Note that in all these settings the Generic term may be replaced by any one of these values in order to make the setting specific to that platform:

     

    AIX/PowerPC

    HPUX/PA-RISC

    Linux/i386

    OSX

    Solaris/SPARC

    Win/i386

    WinCE/ARM

     

     

    [IgnoreUUIDinComputers]

     

      <nlist n="Global/Generic/List/IgnoreUUIDinComputers">

        <node n="Compaq/Evo N" />

        <node n="Big Computer Company" />

        <node n="/XYZ123" />

      </nlist>

     

    If you know that you never want to trust the motherboard UUID on any computer you can stop the client using it with the UUIDforClientId setting. If, on the other hand, you only want to stop the client agent using the UUID on certain computers you could add an entry to this list. The format of each entry in this list is:

     

    [optional computer make][/optional computer model]

     

    In the example shown in the first list entry both make and model are specified. Note that the specified strings may be substrings and still match. So in this example “Evo N” matches “Evo N400c”, but does not match “Evo D400” (the problem was with Compaq Evo notebooks only, not with the Evo desktops).

     

    The second list entry will add all models of Big Computer Company computers to those whose UUID will be ignored.

     

    The third list entry will add any computer with “XYZ123” in the model name, regardless of manufacturer.

     

    Notes:

    1. If no IgnoreUUIDinComputers setting      is present in client.xml the built in default value of "Compaq/Evo      N" will be used.
    2. If any IgnoreUUIDinComputers      setting is specified in client.xml the built in default value of      "Compaq/Evo N" will not be used. Therefore it is recommended      that if an IgnoreUUIDinComputers entry must be specified, the      "Compaq/Evo N" entry is also specified.

     

     

    [ComputerSerialNumberforClientId]

     

     <at n="Global/Generic/Enable/ComputerSerialNumberforClientId" v="0" />

     

    This setting will stop the client agent from ever using a digest of the computer make, model and serial number for the client id.

     

    The effect it has on the list of possible client id sources:

     

    1. Motherboard UUID + digest of disk      model/serial number
    2. Motherboard UUID alone
    3. DISABLED: Digest of computer make, model and      serial number + digest of disk model/serial number
    4. DISABLED: Digest of computer make, model and      serial number alone
    5. Digest of disk model/serial number      alone
    6. The client id already present in      local.xml
    7. A “random” number

     

     

    [DiskSerialNumberforClientId]

     

      <at n="Global/Generic/Enable/DiskSerialNumberforClientId" v="0" />

     

    This setting will stop the client agent from ever using a digest of the disk model and serial number for the client id.

     

    The effect it has on the list of possible client id sources:

     

    1. DISABLED: Motherboard UUID + digest of disk      model/serial number
    2. Motherboard UUID alone
    3. DISABLED: Digest of computer make, model and      serial number + digest of disk model/serial number
    4. Digest of computer make, model and      serial number alone
    5. DISABLED: Digest of disk model/serial number      alone
    6. The client id already present in      local.xml
    7. A “random” number

     

     

    [CombineDiskSerialNumberWithClientId]

     

      <at n="Global/Generic/Enable/CombineDiskSerialNumberWithClientId" v="0" />

     

    This setting will stop the client agent from forming the client id from a combination of the motherboard UUID or a digest of the computer make, model and serial number and a digest of the disk model and serial number.

     

    The effect it has on the list of possible client id sources:

     

    1. DISABLED: Motherboard UUID + digest of disk      model/serial number
    2. Motherboard UUID alone
    3. DISABLED: Digest of computer make, model and      serial number + digest of disk model/serial number
    4. Digest of computer make, model and      serial number alone
    5. Digest of disk model/serial number      alone
    6. The client id already present in      local.xml
    7. A “random” number

     

     

    [MACforClientId]

     

      <at n="Global/Generic/Enable/MACforClientId" v="0" />

     

    This setting just stops the client agent using the computer MAC address when creating the “random” number last resort source for the client id.

     

     

     

    [ClientIdRevision]

     

    You could divide the methods the client agent uses to determine the client id into two types: type A is one where the id is generated from data read from the system each time the client agent starts; type B is one where the id is generated once and recorded on-disk to be reread on subsequent client agent restarts. Motherboard UUID, computer make/model/serial and disk make/model/serial are all type A methods and the last-resort pseudo-random + MAC address is the only type B method.

     

    These two method types have pros and cons. Type A is good because it does not rely on any value stored on-disk (which may be a duplicate of the id on some other computer or missing – both possible consequences of “re-ghosting” the disk), and is bad because it relies on the value obtained from the hardware being unique and unchanging – sadly not always the case. Type B is good for the reason A is bad and bad for the reason A is good.

     

    If you have client agents already deployed, and you subsequently change the client id generation method to, or between, type A methods, the client agents should generate the new id and start using it. Job done.

     

    However, if you have client agents deployed, and you subsequently change to the type B method, the agents will not generate a new client id, but will simply continue using the id they previously generated using the original type A method. This is because the client id will already exist in local.xml and will be reused as if it had been a previously generated pseudo-random number.

     

    You may be changing to type B specifically because the type A generated client id is not unique, so you really want the client to generate a new id and use that forever after. To achieve this, as well as disabling the type A methods with the settings described above, add this line to client.xml:

     

      <at n="Global/Generic/ClientIdRevision" v="123" />

     

    The value is an arbitrary 16-bit integer; any time you want the client agents to generate a new pseudo-random id just change the value.

     


     

    Note 1

     

    If you would like to the client agent to only use the local.xml/random method of generating the client id you should add these three settings to client.xml

     

    <at n="Global/Generic/Enable/UUIDforClientId" v="0" />

    <at n="Global/Generic/Enable/ComputerSerialNumberforClientId" v="0" />

    <at n="Global/Generic/Enable/DiskSerialNumberforClientId" v="0" />

     

    The effect of adding these three settings on the list of possible client id sources:

     

    1. DISABLED: Motherboard UUID + digest of disk      model/serial number
    2. DISABLED: Motherboard UUID alone
    3. DISABLED: Digest of computer make, model and      serial number + digest of disk model/serial number
    4. DISABLED: Digest of computer make, model and      serial number alone
    5. DISABLED: Digest of disk model/serial number      alone
    6. The client id already present in      local.xml
    7. A “random” number

     

     

    Note 2

     

    The settings in client.xml are case sensitive; they must appear exactly as shown here.

     

    A useful way to ensure you get the setting right is to use the client agent built-in hint option: run the client agent (in a DOS box on Windows) with this command line parameter:

     

    cagent32 /templatexml

     

    This will create a file template.xml in the same directory as the client agent containing all possible client agent settings. You can then cut the setting you need and paste it into client.xml, changing the value from 0 to 1, or vice versa, if necessary, and replacing the %PLATFORM% with Generic, or the specific platform name of your choice.

     

    You can do the same thing on other supported operating systems:

     

    cagent --templatexml

     

    and the generated template.xml file will be put in the /etc/centennial/audit directory.