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
It doesn't mean anything, but yes you can just delete it and it will be re-generated.
I am facing similar issue these days with many Servers as Splunk forwarder was installed on Template Server . I was not able to find guid in server.conf however there is surely an instance.cfg . What do you all recommend . Should I try below command OR just remove the instance.cfg file .However those cloned serves are getting wrong host name as well so I need to remove two things .
$SPLUNK_HOME/bin/splunk clone-prep-clear-config
Check out this command:
$SPLUNK_HOME/bin/splunk clone-prep-clear-config
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.
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.
It doesn't mean anything, but yes you can just delete it and it will be re-generated.
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.
Addendum :
I tried this on cloned indexers in version 7.3.0 (in my lab) with the same GUID and it worked (deleting instance.cfg)