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.
In vSphere, Virtual Machine Templates are:
- Virtual Machines that cannot be powered on
- Virtual Machines that cannot be modified
Templates are like gold images, you create a template and deploy multiple VMs from them. Templates configuration files use an extension VMTX (virtual machines configuration files have an extension VMX). There are two easy ways to create a template:
- Clone an existing virtual machine (VM) to a template.
– Creates a copy of an existing VM and registers it as a template.
- Convert an existing VM to a template.
– Unregisters existing VM and registers it as a template.
Workflow for modifying a template:
- First convert the template to VM
- Optionally, make changes to the VM hardware (increase RAM, disk size etc.)
- Power-on the VM and install any new applications or updates
- After installing the application and updates, shutdown the VM
- Now convert the VM back to a template
Deploying Virtual Machines from Templates and Guest Customization:
When virtual machines are deployed from the template, they will identical to the template, things such as Windows-SID and hostnames would same. If using static IPs, those would also be same. This can create software and network conflicts.
To avoid such network or software conflicts, its recommended to customize the VM Guest during the deployment process. For Guest OS customization of virtual machines deployed from templates, vCenter requires the following:
- If the guest OS is Windows, you need VMware Tools and Sysprep utils to be installed within the templates:
- You will need to copy Sysprep tools to vCenter for Windows 2000, XP & 2003. Starting with Windows Vista onward, Sysprep tools are part of the base OS install. Where to copy Sysprep utils, read the following KB#1005593 article
- For Linux VMs/Templates, along with VMware toools, you will also need Perl to be installed within your templates.
Best Practice: Always create templates for powered off virtual machines. Do not clone templates from a powered on virtual machines.
- It is very similar to an Active Directory Domain Architecture
- It is an authentication broker
- It configures a vsphere.local domain (in vSphere 5.1 the local domain was called as “system-domain”)
The Single Sign-on (SSO) Architecture part of vCenter in vSphere 5.5 has following features:
- It uses a Kerberos type (token based) authentication mechanism
- It uses a Secure Token Protocol for Authentication
- You can create one-way trust relationships with existing Windows Active Directory Domains or OpenLDAP domains
- You can have multiple such trust relationships defined. Being able to define multiple trust relationships is very useful in a cloud enabled era.
One of the important things that you should remember is (and hopefully that would remove a lot a confusion) this vCenter Single Sign-on infrastructure is only used for authenticating users/groups to vSphere Infrastructure and applications that integrate with vCenter. It does not provide authentication services for desktops or other desktop/user applications. Or to say more correctly it is not a replacement for Active Directory Domain. In fact it works as a complementary solution to authenticate Active Directory users/groups to vSphere infrastructure.
In Single Sign-on infrastructure the default Single Sign-on administrator user is firstname.lastname@example.org. This user is an administrator on both the vsphere.local Single Sign-on domain and the vCenter Server inventory.
- On a Windows based vCenter Server System, you set the password for this user (email@example.com) during the installation of Single Sign-on.
- On a vCenter Server Appliance (Linux based virtual appliance) the firstname.lastname@example.org get created and defined during the initialization/configuration of the appliance.
Virtual Appliances are portable virtual machines. One can export a virtual machine as a virtual appliance, and then you can also import the virtual appliance back as a virtual machine.
Virtual Appliances are available either as a folder of files – OVF (Open Virtualization format) or as a single (tarball) file – OVA (Open Virtualization archive).
Why use Virtual Appliances?
Since you already have a existing virtual Infrastructure, you can use the same for running virtual appliances. Virtual Appliances are essentially a VM which is pre-installed with a Operating System (OS) and an application. Virtual Appliances are built is such a way that you just import the appliance and start using it with a minimal network and application configuration.
Advantages of Virtual Appliances:
Both physical and virtual will require a approval from the finance team. However after the finance approval, implementing a virtual appliance will require no more approvals.
- No need for approval from the data-center team for rack space
- No need for approval from the networking team for free ports on network switches
- No need for approval for power requirement
- No need for approval for air conditioning or cooling needs
All these approvals basically increase your deployment time to anything about 4-6 weeks, whereas if using a virtual appliance that comes down to about 2 hours. Other advantages of virtual appliances include:
- Standard off-the-shelf server hardware used for running virtual appliances
- Reduces AMC costs as one less hardware vendor to manage
- Easy to standardize on a single hardware vendor
- Improves return on your investment in hardware infrastructure
You can find several free and paid appliances available from various vendors. VMware has something called as VMware Virtual Appliance Marketplace. Several free Linux based opensource virtual appliances are available from Turnkey Linux. You can also build your own virtual appliances using the SUSE Studio. You can also find a free Linux based L3 switch appliance at VyOS. You can also find the excellent Monowall Firewall as a virtual appliance for vSphere.
Overall I believe virtual appliances are here to stay and the easy of management and deployment is what makes them a very attractive form factor.
More about Snapshots
Snapshots are not backups, but backup software will leverage snapshots to take backups of the VM.
- When you take snapshots the delta disks can potentially grow to the size of the original disk
- When you take snapshots be careful because you can easily run out of storage space on the datastore
Snapshot Best Practices
If you plan to take snapshots
- Do not over commit the datastore capacity
- In fact you should be under commit by up to 30%
- Do not create more than 1 snapshot
- Do not keep snapshots for more that 1 day, in exceptional cases on production VMs (powered VMs) you may keep it up to 2 days
Difference between Clone and Snapshot
Clone is another copy of the virtual machine, where as a snapshot is a capture of point time state of the virtual machine. If you delete the virtual machine, the snapshot will also be deleted along with the it, however the clone will remain intact because its a separate copy.
What is a Snapshot?
- It is a point in time state of the virtual machine
- When you take a snapshot a delta disk gets created.
- If you create another snasphot another delta disk will be created
- The delta disk is mounted as ReadWrite (RW) whereas the original disk is mounted as ReadOnly (RO)
- This delta disk is thin priovisioned disk, and grows in chunks of 16MB
- After creation of Snapshot all disk writes within the VM go to the Snapshot-disk (delta disk) and not to the original disk (flat disk)
In vSphere, snapshots are based on “COW“
COW ==> Copy on Write Snapshots
In COW, all new writes always go to the delta disk.