Configure and test of ESXi Dump Collector

I have neglected this for a while.  But when you use SD like I do to boot your ESXi hosts, they do need a place to dump core files.  When VMware gets a PSOD – purple screen of death, it is important to have the ability for VMware to copy the memory to someplace else.  And, BTW, take a picture of any PSOD you see as there is often info in it that is not anywhere else!

So I need to get his done now.  In talking with others I realize that this is not that common for people so I am writing it down as I do it.

This is for vSphere 6, and of course, I am using the vSphere Web Client.  Plus I am doing this with a VCSA which is the same but for the dump collector log location.

Updated: This works mostly good in 6.7 but you need to NOT use the HTML5 client. You also need to have your account in System Configuration Administrators group.

Set Up of the Dump Collector

We need to start in the Home page.

  • We change to Administration, followed by System Configuration, Nodes, Related Objects, Services, and finally VMware vSphere ESXi Dump Collector.


  • We use the Actions menu need the top of the screen, and Start the Dump Collector service.


  • You also need to Edit Startup Type to change it from Manual to Automatic. Not sure why it defaults to Manual but that sucks.
  • Once started, you may see an error message.  Use the Refresh button to clear it and it should look like the following screenshot.


  • If you change to the Manage page you will see what little config is possible.


  • The defaults are good for us.

We now have the Dump Collector working and able to receive cores.  We now need to get the hosts configured to use it.

Setup of Host

While this can be done in Host Profiles we are going to do it at the command line.  Even for Host Profiles you should do it at the command line in your reference host.

We need to access the console of our ESXi hosts via SSH.

  • One on our host, the first thing we should do is check the status.

esxcli system coredump network get


  • Next we need to configure the host for remote coredump.

esxcli system coredump network set -v vmk0 -i -o 6500


  • My use of vmk0 here is representative of the management network which is normally vmk0.
  • The is my vCSA which is hosting the dump collector.
  • Now the host is configured we need to enable this functionality.

esxcli system coredump network set -e true


  • We can check out configure using the first CLI we did.

esxcli system coredump network get


  • Note how it looks a little different now?

How can we test this?

A very simple test would be to use the following command:

esxcli system coredump network check


Thanks to William (for sharing with me this article) I am able to confirm this is working. If on your VCSA you look into:


You will see something like below:


The three messages are from my three hosts where I tested things!

And, BTW, the info on this post back is from the article that William shared with me.  What I am  impressed about is that this was from a vSphere 5.1 based 2012 article.  It is cool the path is still the same in 2016 and vSphere 6.0 U1.

Yes, you can force PSOD and see if it moves the memory.  You can find out how to force a PSOD in this article.  Not sure if it will move memory or not, but it is fun to try.  Suggest to be careful with this!

Where do the coredumps end up?

While if this is not a play circumstance support will help with this, but just in case the location is:


But remember you will need to enable shell, and then use the shell to access it.  I will add the location for the Windows core’s when I find it.


You can find additional info in this KB article.


If you are using this as a reference while you are doing the work this should help.

esxcli system coredump network get

esxcli system coredump network set -v vmk0 -i -o 6500

esxcli system coredump network set -e true

esxcli system coredump network get

esxcli system coredump network check


I hope that this helps, and remember if you boot with SD like I do, or with USB like many of you, then if you PSOD – thank goodness so rare – and there is a core, you will need to have the process in this article done so that the core can be retained.


  • 10/20/19 – used this with vSphere 6.7 U2, and U3, and still had to use the FLEX client.  What a pain that was!
  • 3/17/19 – used this with vSphere 6.7 U1 and it worked pretty good.  Had to use FLEX client though.
  • 3/2/17 – used this with vSphere 6.5 and it worked fine and nothing was different.
  • 7/18/16 – added the comment about changing Manual to Automatic start. Also did this process on vSphere 6.0 U2 with no changes.
  • 4/11/16 – added some clarity on the path in the Web Client.
  • 1/20/16 – added the info from William about how to confirm the check worked.
  • 1/20/16 – Added the cheatsheet to help, and the clarification that the IP referenced is my VCSA.


=== END ===

11 thoughts on “Configure and test of ESXi Dump Collector

  1. Thanks for this great article…
    I have a question tough …
    Un the article above you are dumping the coredumps to a vCSA server.
    But if the vCSA server is actually running on the ESXi server that is getting the PSOD’s then this will be of no use right?

    1. Yes, Iwan, that would be true. If the host that was running the VCSA crashed at the moment that a core was to be delivered to it that would not occur. But I do not think that is enough of a worry to cause me to not do this. In my five host environment I have not had hosts crash often at all. Even when all running beta.


  2. Hi,

    Thanks for the article

    Is there a way to place/install netdump collector service on a different windows server instead configuring it on the VC (if I am running a Windows based VC) like in 5.5?

  3. Hi,

    Thanks for the article

    If I was running a Windows Based VC — in 5.5 I had the capability to install Dump Collector on a different server (and not neccesarily on VC server) … can this be done in VC6 ?


    1. Found the answer. The logs will be written to directory below in case of a PSOD.


  4. Noticed an issue w/ this service. Netdumper seems to have issues starting if its configured space is full or almost full. In almost full scenarios, the cron job doesn’t appear to work because it is always looking for “greater than (gt)” for cleanup. In full scenarios, the cron job will only work if the directory is larger than the configured max because it is “greater than (gt)” rather than “greater than or equal to (ge)”
    Also noticed that even then a “netdump” path is created, the default still places it in /storage/core, rather than /storage/netdump. Unsure if that’s by design, but seemed weird.
    Finally, the lack of API endpoint to modify this services configuration is an ultimate deal breaker for me. Seems to me that it is a little used function that hasn’t had a need for TLC for awhile.

    1. Hi Chris, been some time since we chatted. Hope all is good. Thanks for sharing, ans I did not know this. Hopefully someone will do something about this when they see your comments.

      Thanks again, and have a great day,


Leave a Reply