This might help you out, and for certain it helps me remember things. Not all here is good for all people but certainly it is all worth thinking about. I have a best practices article that has lots of great info and which helps out this article. But here is a list of things and you can always ask questions or leave comments.
- FQDN and IP’s already decided and defined in DNS
- I like to make sure the BIOS is right - a nice thing about where I buy these (WiredZone - this is what I got) means the BIOS is already done. But I like to check some of these things:
- PXE type network stuff off
- Virtualization enabled.
- Disabled serial and parallel if there is anything like that
- I like to do a memory test overnight - using MemTest86.
- I connect the network. For me I have four connections. Mgmt, VM, and various storage.
- I connect via DRAC or iKVM and install vSphere and do basic network and password.
- I connect the new host to the appropriate cluster. I always use the FQDN to do that.
- I now use VUM to update the host. In my case that is for patches, but also for two different network drivers I need to update / add - one for my 10 GB and one for my 1 GB networks.
- I add the storage - love how easy it is to add NFS. But I have both NFS and iSCSI to add.
- Now the vSphere tweaks
- I add my syslog destination - and I use tcp://123.456.789.abc:514 to do it. TCP is better than UDP as it keeps track of its packets!
- I configure NTP - using 0.ca.pool.ntp.org but also 0.us.pool.ntp.org also works - and I do 0., 1. and 2.
- I do an external Core dump location - using this article to help.
- I tweak HA and DRS now.
- For example I make sure things like VM to Host groups include the new host if appropriate.
- I get rid of the management network redundancy missing network stuff.
- I now make sure I see no errors in the new host Summary screen or the cluster Summary screen.
- I register VMs now as appropriate.
- I now check Log Insight vSphere dashboards to see that this host - or cluster - has no errors. More confirmation really.
Make sure you check out my vSphere Best Practices - they are pretty useful and I implement them all and keep an eye on them. I update the article as necessary too.
And yes, you should absolutely automate all this stuff. Make sure understand and do it a few times manually first! Dell’s OpenManage Plug-in for vCenter can automate some of this nicely - including install vSphere. I have seen several customers that use PowerShell and PowerCLI to automate all this very nicely indeed. Host Profiles would help with a lot of this and are a very cool feature.
BTW, I just worked on this with my new Supermicro hosts. See this for more info on the setup of them.
=== END ===
4 thoughts on “Setting up a new vSphere Server”
re. TCP logging: it’s a bad idea. Some reasons are given at https://rainer.gerhards.net/2008/05/why-you-cant-build-reliable-tcp.html and the associated discussions, the one that bit me personally was when I was using TCP syslog to a remote syslog receiver that crashed and stopped reading from the stream, but didn’t break the connection. After a few days my own OS buffers filled up and my server went down hard too… UDP doesn’t do that.
Thanks Paul, I was told by some very smart logging R&D guys that TCP was better than UDP as no packets would be dropped. But you example is very interesting so thanks for sharing, I will have to think about this.
It would be better, if the protocol allowed for the receiver to acknowledge when it had received a log message (not just TCP ACKs). But since it doesn’t, you can end up losing a ton of messages without realising it or getting issues like the one I had. I agree it does feel like a better idea, but in practice it isn’t.
Thanks Paul, good to know.