Objective 3.5 – Determine Virtual Machine Configuration for a vSphere 5 Physical Design

This objective is completely focused on Virtual Machine design considerations:

Let us understand what exactly a Virtual Machine is? You can say its a container which comprises of various different files, Virtual Machines have similar Hardware (Virtual Hardware) which a physical machine would have in the real world. It has a CD ROM, SCSI Controllers, Floppy Drive, Serial/Parallel Ports, Network Cards and so on…..

What size should a Virtual Machine be created of? 1vCPU 2 GB RAM or 8 vCPU’s 64 GB RAM? this really is driven by your application requirements, just because you can have highly configured VM’s doesn’t mean you really should. You should use proper tools to anaylze the application demand and as per stats you can decide on an appropriate VM size. For enterprise clients, the VMs are usually offered in tiered sizes, as in 1vCPU 2 GB RAM, 1vCPU 4 GB RAM or 2vCPU 8 RAM and so on…this helps to maintain a proper service catalog as well.

Virtual Hardware Consideration:

  • Install VMware tools, it provides optimized drivers, specialized memory driver (balloon driver) and required for VM/Application monitoring through HA
  • First and foremost, ensure the hardware version is complaint to the ESX/ESXi host’s version, until vSphere 4.x the hardware version was 7 and vSphere 5 has  the hardware version as 8
  • The best pratice is to always start with 1vCPU, unless you have a clear reason to provide more, the application should be able to use the extra CPU, otherwise too many vCPU will penalize the host and cause performance issues not only to that VM but all the other VMs on the host
  • RAM allocation is completely dependant on the Application and OS requirement, two important things to remember, do not forget to calculate the overhead memory and do keep in mind that any unreserved memory will create a seperate swap file which might impact your storage design
  • The memory for video card is usually 4MB by default which is enough for one screen with a resolution of 1176×885, but this setting can be quiet important for VDIs
  • Use Large Memory pages for your Tier 1 Apps
  • Floppies, USB Controllers, LPT and COM Ports are rarely used and should be removed from the VM
  • It’s undesirable to host swap files on the host’s local datastore as it will drastically slow down the vMotion. It should be hosted on a low-tier non replicated shared storage
  • Do not change the VM names in the vCenter Inventory as the name change doesn’t reflect the folder name in the datastore, if a change needs to be done, do it via Storage vMotion. So rename the VM in the vCenter Inventory and Storage vMotion the VM onto a different datastore so that the folder is created by the new name
  • Also avoid using spaces and special characters because it makes it easy working with the VM at the command line

Virtual Machine Network Consideration:

  • Usually VM’s require only 1 NIC, multiple NICs can be given for various reason such as.. Backups on a different subnet, Bridge networks, firewall appliance and so on….
  • vNIC drivers are selected automatically while choosing the guest operating system, vmxnet3 (VM needs to be at hardware version 7) is the latest paravirtualized driver and widely used these days. It offers features like TSO, Jumbo frames, large ring sizes etc…
  • Mac addresses are assigned automatically, should change them only for valid reasons, sometimes application licenses are tied to Mac addresses, so it’s better to have a static MAC
  • To use Virtual Guest Tagging, install the 802.1q tagging software within the guest OS and set the port group VLAN ID to 4095

Virtual Machine Storage Consideration:

  • Create one logical partition per VMDK
  • The VMDK’s are created as dependent disks which allow snapshots to be taken, If you want to skip disks from being snapshotted, you can select Independent Persistent, this is more applicable for DB drives, which shouldn’t be snapshotted rather a proper backup tool must be used
  • SCSI controllers are selected automatically based on the Guest OS selection. PVSCSI controllers are widely used these days as most of the latest Guest OS’es support it (Win XP defaults to IDE as it doesn’t SCSI controller drivers)
  • I/O intensive Apps should have a Eager Zeroed Thick disk as all the space is committed upfront and zeroed out
  • While using NFS mounts, the disk format is dictated by NAS device, its Thin provisioned
  • RDM’s can be used for various reasons, SAN management Agents, Migrating Data from Physical to Virtual, MS Clustering and so on….NPIV will only work with RDM’s. But RDM usage should be planned carefully as each host can have a maximum of 256 LUNs presented to it
  • Ensure you planned to leave enough free space on Source and Destination Datastores if you’re using Storage vMotion extensively, with large disks Storage vMotion can eat up large chunks of space on the source datastore
  • You can explore VM-Host Affinity must rule to tie the VM’s onto specific host if the VM has strict License restrictions
  • Do not set backups, virus scans cron/scheduled jobs to be run at the same time as it may cause heavy I/O

Other General Consideration:

  • Use one type of Time Sync, it’s usually the native NTP or W32time which generally works well within the OS
  • Use templates to provision new VM’s to ensure consistency, Templates should be updated quite often with latest patches and updates as required
  • While using NLB, use multicast node whenever possible, because you don’t need to make any changes on the hosts, and no broadcast port flooding will occur
  • If reservations are a requirement, use it at the Resource Pool level rather than on VM level, using VM level reservations can directly impact the HA slot size
  • Reservations can provide greater consolidation ratios and it also prevents the vswap file being as big as unreserved allocated RAM
  • Do not use limits as they reduce VM’s performance
  • Use Storage Profiles to place your VM’s according to datastore capabilities, these are driven by array using the VASA or manually configured Storage capabilities
  • It is by far recommended to have 1 App per VM rather than bundling too many things

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s