Deployment Architecture

Duplicate GUIDs for cloned forwarders - how to correct?

kristian_kolb
Ultra Champion

Have run into a minor problem when cloning virtual machines with a forwarder installed. Unfortunately, the guid (globally unique identifier) was not set to empty in server.conf prior to cloning, and we've ended up with several forwardes with the same guid values. This does not seem to affect anything but some graphs in the Deployment Monitor, e.g. the Forwarder Connections graph on the main page, which is based on a distinct count of guids, resulting in a lower reported number of active forwarders than there really are. (NB: the "all forwarders" view in DM shows the correct number of forwarders). There might however be other consequences not yet discovered.

What I want to do is to manually change the guid values for the cloned hosts, but I want to know if the guid is just a random string of hex, or if the string actually represents something, like OS version, IP-address, forwarder build #, hostname etc, or if there is some sort of checksum to be taken into account.

Can I just change the guid value in server.conf of an already installed forwarder, restart it, and expect it to work fine?

EDIT: Or even simpler - can I just remove the guid value altogheter and restart the forwarder - hoping that it will generate a new guid?

Any help appreciated.

/Kristian

1 Solution

gkanapathy
Splunk Employee
Splunk Employee

It doesn't mean anything, but yes you can just delete it and it will be re-generated.

View solution in original post

woodcock
Esteemed Legend

Check out this command:

$SPLUNK_HOME/bin/splunk clone-prep-clear-config

d3
Explorer

I ran into this issue as well. But running Splunk 5.0.2 the file was not server.conf. The file was instance.cfg under $SPLUNKHOME/etc. Removing the guid and restarting Splunk still fixed the issue.

ephemeric
Communicator

I have been through this. Just delete the GUID and restart as it will generate another.
Not sure how it is generated though. From what I can recall it has something to do with the
license type the hash is based on.

With license pools it affects your daily indexing volume too. If running two same GUIDS
for example you will have double the indexed volume if you cloned the indexer.

This happened to me when I didn't change the GUID after cloning an instance and starting with a clean index it still doubled the daily indexing volume in license manager.

Hope this helps.

gkanapathy
Splunk Employee
Splunk Employee

It doesn't mean anything, but yes you can just delete it and it will be re-generated.

View solution in original post

ckleiman_splunk
Splunk Employee
Splunk Employee

At the time this answer was written, duplicate GUIDs may not have meant anything (before my time working with splunk).  When using a deployment server, or looking anything up based on GUID, this becomes pretty important.  Please fix this issue by stopping splunk, deleting instance.cfg, and starting splunk:

1. Stop Splunk

2. Delete instance.cfg

(c:\Program Files\Splunk\etc\instance.cfg

c:\Program Files\SplunkUniversalForwarder\etc\instance.cfg

/opt/splunk/etc/instance.cfg

/opt/splunkuniversalforwarder/etc/instance.cfg)

3. Start Splunk

 

Problem solved.  

BTW, whatever the root cause, check the server.conf to make sure the system name is correct, otherwise you could have multiple systems sending logs as the same host.

0 Karma

yannK
Splunk Employee
Splunk Employee

Addendum :

  • in splunk 4.*, the GUID was in $SPLUNK_HOME/etc/system/local/server.conf
  • since splunk 5.*, the GUID is in $SPLUNK_HOME/etc/instance.cfg
0 Karma

BARNEYRUDD
Explorer

I tried this on cloned indexers in version 7.3.0 (in my lab) with the same GUID and it worked (deleting instance.cfg)

0 Karma
Register for .conf21 Now! Go Vegas or Go Virtual!

How will you .conf21? You decide! Go in-person in Las Vegas, 10/18-10/21, or go online with .conf21 Virtual, 10/19-10/20.