VMWare 5.5 ScratchConfig Syslog Etc.

Syslog and ScratchConfig in VSAN

After digging into the matter, I looked up some best practices, and this is what I've come up with.

1. The Host Syslog should not be on the VSAN Datastore
2. The ScratchConfig should not be on the VSAN Datastore, or on SD card.
3. Ideally there would be some local storage for these, but if VSAN claims all my local disks, what to do?
My proposed solutions are.

1. Sacrifice a HDD from each Host for Syslog and ScratchConfig.
2. Buy some smaller HDD's that are slower and cheaper.
3. Run without a local storage (in this case VMWare uses a ramdisk and data is not saved between boots).
4. ??

As it turns out during the initial install of 1 instance of VSAN I ended up with solution #1 and another instance ended up with solution #3. It took me a long time to figure out why 1 disk was missing from my VSAN setup, and then I began to see what happened. At some point during the install, VMWare made the decision for me and sacrificed one of my disks for Syslog and ScratchConfig. How I ended up with 2 different implementations is beyond me, but it actually helped me figure out the problem.

So next came the task of choosing my path. I could convert one instance or the other, but I could not abide having two different configs, so I chose to sacrifice a drive. I know, it might be ridiculous to use a 1.2 TB drive for 4GB space, but I couldn't find a better solution.

Then I had to reclaim a disk from VSAN, format it for local use, create a filesystem, then re-point Syslog and ScratchConfig to use this new space.

First I moved all of the Vms off of the machine that I wanted to reclaim a disk from and put the host in maintenance mode. Next, I went to the disk management portion of VSAN configuration, and made a note of the UUID of the disk that I wanted to remove. Then I clicked "remove". All is well, nothing exploded.

After the disk was free, I could get it ready for local vmfs filesystem.
Here is what the disk looked like in partedUtil when part of the VSAN.



Here is what the disk looked like in partedUtil after removing from VSAN.



If you run partedUtil showGuids, it shows you what the UUIDs mean, we'll need the appropriate UUID for creating the local 4.0GB partition



Next, I had to run

partedUtil setptbl

You might have to do a little math to get it right at 4GB.



Now I have a 4GB partition on a local disk that is not part of VSAN. Excellent. Without a filesystem mounted though, it will be useless. Running

esxcli storage filesystem list

You can see my currently mounted filesystems. Before mounting this new partition. I used the command

vmkfstools -C vfat "/vmfs/devices/disks/naa5000c5007f95b82f:1"

the :1 is for the first partition.



Now running filesystem check, I see my new mounted filesystem. Make a note of the mount point, we'll need it for the next steps. Note that this matches the UUID created in the previous step.



Next, copy the mount location and paste it into the Configuration->Advanced->ScratchConfig.ConfiguredScratchLocation.
You can see here that I'm still running on /tmp/scratch (ramdisk), and will have to reboot for the changes to take effect. Time to go get a cup of coffee.



Ok, now lets go back and check that same setting.



Next, enter the value

[] /scratch/log

in Advanced->Syslog->Syslog.global.logdir



Now, to see if that all worked. Login to the shell and navigate to the new scratch partition/log directory. You should see all the log files.



Scratch and Syslog files are not on the VSAN Datastore. Since they are on a local datastore, and not a ramdisk, they will persist between reboots. I believe this is as close to "best practice" as it gets with VMWare VSAN. Thanks for reading.