Source: drive2.ru
Operating system. Choose modern distributions. If you take Windows 2008 R2 and older or Linux up to the kernel 4.19.x, wait for problems. Which ones? Well, for example, the vendor has already ceased to maintain the current status of Windows 2008 R2 already in 2013 (EOL). This means that he no longer develops drivers for the hardware that has since been released, does not modify the OS for anything new. With ancient OSes, you definitely cannot use all the features that a modern hypervisor provides. And already on these New Year holidays there will be an acute security problem, since January 14, 2020, extended support for Windows Server 2008 R2 ends and Security Update ceases to be released.
Cores per socket. Leave 1 core per socket, put as many sockets as you need virtual processors. Yes, it is logical on the contrary, but rightly so. Unless you have specialized licensing requirements. For example, you pay for a socket, and more sockets means more licenses. Do not bet 2/2 to get 4. Do 4/1. The hypervisor will serve such a machine in an optimal way. The hypervisor Scheduler will less penalize such VMs.
I will explain on the fingers. Imagine that the conductor seats passengers along the wagon, the wagon - as in Sapsan. In the role of conductor scheduler, passengers are VMs. The passengers who travel alone (single-processor VMs) are the easiest to distribute to them: they can be put in any place. A family of 4 people (4-processor VMs) is already more complicated. They need to find 4 seats in one car. Now imagine that everyone in the family wants to go only facing each other, and there are only 4 such groups of places around the table in the carriage. With a high probability, such a family will have to go to the next carriage (the next planning tick). This is just the situation, as if you chose 2 sockets with 2 cores to get 4. Most likely, you will have to wait for suitable places to be found. It is the same with VMs: it will have to wait longer than the less “whimsical" VMs with 1 socket and a bunch of processors.
Although this story is more relevant for older versions of ESXi. Starting with 6.5 (but not earlier!) The vNUMA mechanism is untied from the number of virtual sockets, and the old recommendation “do not produce sockets” is not so categorical. But it still depends on the application inside the guest OS.
Hot Add for CPU and Memory. This is an option to add CPU memory for a running virtual machine. It would seem to be a great function: you do not need to extinguish the car in order to drain resources. So, not everything is so simple, and it is not for nothing that they are disabled by default. It’s better not to include it if you don’t know what the NUMA topology is. Let's say we have a dual socket server under the hood of the cloud. Each socket has 4 cores. It works just like 4 + 4, not 8 cores. The same topic with memory: if there is 128 GB on each socket, this does not add up to 256 GB. Each processor socket has direct access only to specific memory slots. Each socket, together with the processor and memory due to it, is a physical NUMA node.
If the virtual machine breaks into the size of the physical NUMA node, then it runs inside that node. If the virtual machine does not fit in a NUMA node, for example, from memory, then it will use memory from a neighboring NUMA node. The path to the remote memory will be tortuous - through the interprocessor bus. This will not work as fast as if the virtual machine used the resources of one node.
When you enable the addition of virtual processors and memory to a hot one, all this goes only to the zero NUMA node. For example, 4 more processors were added, and on the NUMA-node 0 it became 6, and on the NUMA-node 1 - 2 processors. The car is a little skewed, and it also works obliquely. This is because when you turn on vCPU, the Hot-Plug vNUMA stops working, through which vSphere tries to optimize the NUMA topology for VMs. Therefore, when deciding whether to enable the Hot-Add CPU, consider the NUMA physical topology to ensure VM performance. This is very critical if for some reason the VM has several virtual sockets. In this case, the mismatch of the physical topology will cause a significant drop in performance: the CPU Scheduler will go crazy trying to provide processor time for such a VM, which will cause the CPU Ready and Co-Stop to grow.
All the added virtual processors (5-8) and memory got to NUMA-node 0.
A separate story is what will happen inside the OS and application after such “additions”. Therefore, if you decide to use this option, then check whether your OS supports this. Non-NUMA-Aware applications can greatly decrease in performance when located on multiple NUMA nodes.
If you still added processors or memory to the hot one, immediately plan to reboot the VM (not just the OS) for the nearest scheduled downtime.
We do not put checkmarks.
Disk controller (Bus type). For disks, select the Paravirtual Disk Controller. This type of controller requires installing drivers in the VMware Tools OS. Paravirtual is a special virtual device that was created to work in virtualization and does not emulate the operation of any other hardware device. Any emulation of a hardware device always runs slower.
If you do not want to use Paravirtual (but why?), Choose LSI Logic SAS. If the OS does not support it too - LSI Logic Parallel. Never use SATA and IDE. VM will work slowly, as a result, you will not get the performance that goes to the cloud.
When installing the OS, even the latest version of Windows may not find the driver for the Paravirtual adapter. In this case, mount two ISO files on the VM - your Windows boot image and the VMware tools disk. The latter has the necessary driver.
Network adapter The right choice is VMXNet3. VMXNet3, like the Paravirtual disk adapter, is a paravirtual device. It also requires drivers that are included with VMware Tools.
If suddenly VMXNet3 does not fit (some incompatibility appears), then in extreme cases, use the E1000E. But do not expect more than 1 Gbps from the E1000E.
In general, do not use the E1000E without explicit instructions from the vendors. It would seem that it is newer, but made to provide even greater compatibility with legacy.
Here it is not necessary E1000E.
VMware Tools Make sure that they are installed in the OS, running and up to date. VMware Tools includes device drivers and various other components that allow the virtual machine OS to communicate with the hypervisor, and vice versa. Through them, the OS time is synchronized with the virtualization host (disconnected), heartbeats go that show the hypervisor that the virtual machine is alive, and so on. To run the OS in a virtual machine, you need at least the drivers of the network card, disk adapter. Fresh versions of all of this are included in VMware Tools.
By default, current versions of Windows and Linux have drivers for working with VMware virtual devices, but if you have VMware Tools, these drivers will always be fresh. For Linux, using open-vm-tools is recommended. This is not just the best integration with the OS, but also updating drivers with the system.
Separate data drives. Use different virtual disks for data and operating system. Yes, and on physical servers it is worth doing this. You can separately backup these disks (with different schedules, for example), you can switch the data disk or its clone to another VM and so on.
In addition, the new virtual disk will also receive an additional quota for disk performance.
Customization When you turn on the VM for the first time, you need to customize it so that all settings from the cloud (for example, the IP address issued by the cloud) are applied to the OS. After that, remove this daw away from sin, in order not to accidentally reset OS settings: SID, administrator password, etc.
Of course, all of the above is a simplified picture, the words “captain O” and, in general, “still know this.” But, as practice shows, more than 70% of VMs in the cloud contain one or several described errors.