A couple of days back during a discussion in a class, someone asked me if it is possible to change the IP Address of a vCenter Server appliance.
Changing of IP Address is allowed. However changing of hostname (FQDN), also referred to as Primary Network Identifier (PNID) is not allowed.
So the long answer, yes it is possible to change the IP Address of a vCenter server appliance after the deployment. (It is also possible to change the IP Address after a vCenter migration from a Windows instance to an server appliance.) One can change the IP Address by connecting to the Virtual Appliance Management Interface (VAMI) located at https://vcenter_server:5480.
Remember after changing the IP Address don’t forgot to update the forward and reverse DNS records.
There one corner condition when changing IP Address is does not work, this is specifically when one has configured a vCenter server appliance with an IP Address (without DNS records). In such cases it is not possible to change the vCenter server appliance IP Address.
However I don’t recommend changing IP Address of a vCenter instance after it has been deployed. Very simply there are many dependencies to take care of which can potentially break things in your environment. Hence always spend some time before deploying a vCenter instance and come up with a long term design strategy of correct Hostname & IP IP Addressing policy.
Here are some thumb rules (best practices) for capacity planning of memory (RAM) allocation within your virtual infrastructure. These rules typically work 90 times of 100, however there would be exceptions:
- If you have over committed your available physical memory on the hypervisor, then the maximum memory configured on any single virtual machine should ideally be less than 40% of the total physical memory. The total memory configured on a single virtual machine in exceptional cases may exceed up to 60%.
- Over commitment should typically be not more 30% of the total physical memory on aggregate virtual machine basis. Remember only powered on virtual machines are considered for over-commitment.
- On a per virtual machine basis never over commit more than the available physical memory on the hypervisor.
- Its a good idea to reserve 30% of virtual machine memory for server virtualization projects, or increase it to accommodate active memory.
- Ensure memory assigned is vNUMA balanced.
On physical machines its a good practice to buy all the physical RAM from one single vendor with identical specifications. Physical RAM should be purchased in configuration to populate all the DIMM slots across all the physical sockets.
Here are some thumb rules (best practices) for capacity planning of virtual CPU (vCPU) allocation within your virtual infrastructure. These rules typically work 90 times of 100, however there would be exceptions:
- Don’t configure any single VM with more vCPUs than the total number of available physical cores on a machine. Also while allocating don’t consider hyper-threads (hyper-threading feature on Intel hosts).
- If you plan for over commitment of CPU then wherever possible do not assign more vCPUs than the number of cores found on a single physical socket (exceptions exist). Example: rather than assigning a 2 virtual socket, single core virtual CPU for a virtual machine, it would be better to assign a single virtual socket, dual core virtual CPU.
- Map physical NUMA to virtual NUMA. Avoid using a VM with wide vNUMA.
- Hypervisor (VMKernel) also has a overhead so ensure at any given point in time there is at-least one free physical cores to schedule the Hypervisor. So this will also effect what we stated in point 1, when considering maximum number of physical cores reduce the number by 1 for a single socket system and by 2 on a multi-socket systems (this is to consider for the Hypervisor CPU Overhead)
- For server virtualization projects the vCPU ratio to physical cores should not exceed more than 12/13 on per physical core basis. You can easily start with an allocation of about 7 vCPUs per physical core.
- For virtual desktop environment projects the vCPU ratio should not exceed more than 18/20 for each physical core. You can easily start with an allocation of about 12 vCPUs per physical core.
- Whenever possible consider not to over allocate vCPUs than what is required by your application or virtual machine. For example if possible to assign a single vCPU to your virtual machine rather 2 vCPUs. Over-commitment at a hypervisor level is quite different from over-commitment at a virtual machine level and the two things should not be confused with.
When considering virtualizing CPU intensive applications (presently running in physical), some things to remember:
- Assuming you have enabled Hyper-threading in both physical and virtual infrastructure. Remember that a single vCPU corresponds to a single hyper-thread in virtual world whereas in the physical world one core corresponds to two hyper-threads. So if you assign your virtual machine with the same number of vCPU as the number of physical cores you had for that application, then you are actually assigning half the CPU resources to the application/virtual machine instance in virtual world. As such your application under load will perform at 50% of the physical instance. Hence it would be better double the number of vCPUs assigned to your virtual machine.