@VictorKiwi
Generally I’d recommend sticking with the default configuration set by Foundation. Any product qualification testing within Nutanix is going to run on this out-of-the-box config.
If you make changes, please ensure you note and save the steps so they can be re-applied after host boot-disk replacement or other scenarios which may re-write the host OS.
The scratch partition is used during upgrade workflows so it needs to meet some requirements, detailed in these KB articles “LCM Pre-check: test_esxi_scratch_space” and “NCC Health Check: esx_scratch_setting_check”. So long as the conditions described there are met, it should be workable.
@JeremyJ
Thank you for the recommendation Jeremy.
Also thanks for the links, although I of course checked them before asking.
While I understand that out-of-the-box configuration will surely work, there’s a hesitation with each of the options.
- Leave default. It leaves the Scratch on the SATADOM/M2/BOSS device, which is not intended for intensive writes (i.e. ESXi logs), and therefore will be degrading at a higher pace.
- Redirect to a shared datastore (i.e. DFS). In an event of “cluster stop” or HCI layer otherwise being unavailable, the Scratch will become unavailable.
Also, for point 1, there’s a sub-option to redirect the scratch from default VFAT partition to the local VMFS volume where the CVM is. In VMware’s opinion, this will ensure the logs are preserved over reboots and are easier available.
Are there pros and cons from your point of view?
Thank you.