When you create virtual machines on VMware ESXi in a production environment, it's important that these are correctly configured and adapted to the real needs of the latter.
In this article, you will therefore find a series of tips to follow to best size your virtual machines in relation to the use that will be made of them.
When you create a virtual machine, VMware ESXi adds a variety of virtual devices by default.
Nevertheless, it's very likely that you will not use some of them, such as a floppy drive, a sound card, a parallel port, a serial port, ...
So it's best to avoid using unnecessary devices (in your case) to potentially avoid a problem while migrating this virtual machine via vSphere vMotion to another VMware ESXi host.
Warning : using a physical device on your host via DirectPath I/O (PCI passthrough) from a virtual machine will prevent the virtual machine from being migrated to another VMware ESXi host.
It's therefore important to take this restriction into account in the event that you have several VMware ESXi hosts.
When you create a new virtual machine on VMware ESXi, the wizard automatically chooses hardware compatible with the operating system you want to install.
However, if you are updating an existing virtual machine or have specific requirements for a virtual machine, you may need to modify the virtual hardware used by it.
For the virtual network adapter of a virtual machine, you have the choice between various models of network adapters : E1000E, E1000, VMXNET, ...
Depending on your needs, you might want to use a different virtual network adapter model than the one chosen by default by VMware ESXi.
For example :
However, all models of virtual network adapters are not supported by all operating systems or not without the installation of VMware Tools.
To check the compatibility of a virtual network adapter with a guest operating system, go to the "VMware Compatibility Guide".
On the page that appears, select :
Then, click on : Update and View Results.
As you can see in this example, VMware tells us that the VMXNET 3 virtual network adapter is supported by Windows 10 on VMware ESXi 6.7.
When you create a virtual machine, the correct storage controller is chosen automatically based on the guest operating system you want to use.
Nevertheless, there are various storage controllers on VMware ESXi, including different models of SCSI controllers, a SATA controller, an IDE controller, ...
The main goal is to use a storage controller natively supported by the guest operating system and thus allow you to install the operating system easily without having to manually load a suitable driver.
Nevertheless, depending on the virtualized application or your needs, it may also be interesting to change this storage controller to use, for example, the paravirtual SCSI controller from VMware.
Indeed, this controller allows you to get better storage performance than other storage controllers offered.
However, it's rarely supported by default (except VMware ESXi which supports it by default) and therefore requires the installation of the driver provided by VMware.
To use a paravirtual SCSI controller with Windows as a guest operating system, refer to our "VMware ESXi 6.7 - Use a paravirtual SCSI (PVSCSI) controller" tutorial.
To check the compatibility between the desired storage controller and the guest operating system you want to virtualize, go to the "VMware Compatibility Guide".
On the page that appears, select :
Then, click on : Update and View Results.
As you can see here, VMware paravirtual SCSI controller is supported by Windows 10 on VMware ESXi 6.7.
To experience the best possible performance and access the latest features offered by your version of VMware ESXi (vSphere), it's important that you use the latest virtual hardware (vHardware) possible.
That is, the same version as your VMware ESXi host.
Indeed, the more you use a recent version of virtual hardware, the more features you will have access to and the lower the limits.
Warning : if you have different versions of VMware ESXi in your VMware infrastructure, make sure to use virtual hardware compatible with them to potentially be able to migrate these virtual machines in the future to these older versions of VMware ESXi.
Or update your old servers if the new version of VMware ESXi is officially supported by VMware for your physical hardware.
To upgrade the virtual hardware of your virtual machines, refer to our "VMware ESXi 6.7 - Upgrade virtual hardware of a VM" tutorial.
When you create a virtual machine, it's important to know what you really need and to know at least how the virtualized application works.
Indeed, when you virtualize a professional application (such as : Microsoft SQL Server, Microsoft Exchange, ...), there are some prerequisites to respect.
Whether it's an amount of RAM, a number of processor cores or the use of a specific storage controller.
If you don't allocate enough RAM or CPU cores, the business application you want may not install, fail to run, fail to function properly, or become unstable.
For example : if your virtual machines are part of an MSCS cluster (Failover Cluster on Windows Server), you will not be able to use VMware's paravirtual SCSI controller.
Conversely, it's useless, even contraindicated, to allocate vCPUs (virtual processor cores) to a virtual machine if the virtualized application is not able to use these cores simultaneously.
In addition, allocating too many vCPUs to a virtual machine can complicate the task of the VMware ESXi CPU Scheduler.
Which means that your virtual machine could be slower than if you had allocated fewer cores to it.
Several PDF files are available on the official VMware site for virtualization of known professional applications :
As we just implied in the previous point, you should allocate only the necessary resources.
Or more precisely, you must avoid allocating too much RAM and/or vCPUs to avoid penalizing this virtual machine and/or other virtual machines running on the same VMware ESXi host.
For how, if you allocate too much RAM to a virtual machine compared to what it consumes on average in reality, you risk penalizing the other virtual machines.
Indeed, depending on the physical resources of your host and/or the size of your virtual infrastructure, your other virtual machines may start to run out of RAM due to the excessive RAM allocation of this virtual machine.
To recover RAM, VMware ESXi will have to use certain mechanisms (such as TPS, ballooning, ...). Which could have been avoided by allocating only the RAM really necessary for the proper functioning of your virtual machine and the virtualized application.
Then, if you allocate too many vCPUs to a virtual machine when it only uses one or when its CPU load is very low, you risk penalizing this virtual machine and/or the other virtual machines present on your VMware ESXi host.
Indeed, the more vCPUs you allocate to a virtual machine, the more you risk complicating the task of the VMware ESXi Scheduler.
This means that your virtual machines will have less CPU cycles and therefore risk being less efficient than if you had allocated fewer vCPUs to it.
To save a lot of memory in the physical RAM of the host, it's better to use virtual machines that are similar : same guest operating system, same virtualized applications, ...
Indeed, among the memory management mechanisms of VMware ESXi, you will find transparent page sharing (TPS).
In summary, this feature allows virtual machines to share memory pages that are identical to each other.
This means that if you launch 10 virtual machines with an identical guest operating system in each of them, it will only be loaded once in the RAM of the host (for simplicity).
Thanks to the different network layers (port groups, virtual switches, ...) available on VMware ESXi, your virtual machines are able to communicate internally or with the outside.
Of course, if your virtual machines communicating with each other are on the same ESXi host, their network traffic will remain inside your ESXi host.
Which means that the transfer speed through this virtual network will be much higher than if your virtual machines were on different VMware ESXi hosts. In which case the network traffic would have passed through your physical network and the various intermediate switches and/or routers that would potentially be between the source virtual machine and the destination virtual machine.
When you virtualize a database server (such as "Microsoft SQL Server" for example) and a professional application based on a SQL Server database, it may therefore be interesting to place the virtual machines hosting these virtualized applications on the same ESXi host so that they can communicate internally through your ESXi host's virtual network rather than through your physical network.
Thus, access to your SQL database will be much faster.
Note that for network traffic to stay internal, the affected VMs will need to be on the same ESXi host and connected to the same port group.
Finally, we suggest you consult the PDF "VM Right-Sizing Best Practice Guide" from VMware.
® InformatiWeb-Pro.net - InformatiWeb.net 2008-2022 - © Lionel Eppe - All rights reserved.
Total or partial reproduction of this site is prohibited and constitutes an infringement punishable by articles L.335-2 and following of the intellectual property Code.