140 likes | 234 Views
The Top 10 Virtual Configurations You SHOULDN'T Implement. Tom Howarth Owner PlanetVM.NET. Pre-requisites for this presentation: 1) General understanding of Virtualization Level: Intermediate. About the Speaker.
E N D
The Top 10 Virtual Configurations You SHOULDN'T Implement Tom Howarth Owner PlanetVM.NET Pre-requisites for this presentation: 1) General understanding of Virtualization Level: Intermediate
About the Speaker • Tom Howarth is a seasoned IT Professional with over 15 years experience in the field. • He has over 4 years Virtualization experience and is considered one of the leading VDI experts. • Has had many lives, Soldier, Policeman, Lawyer, IT Professional, Husband and Father. • The last two are the hardest
Introduction • We all know the what are considered “Best Practice” when designing a Virtual infrastructure • However what is “Worst Practice” well to start it is not the opposite of “Best Practice” • This presentation will attempt to present a vendor agnostic view of what are the top 10 configurations that you should not implement • This may not always be possible due to vendor differences
1: vCPU More is Less • Virtualization software allows the creation of VM guests with Multiple CPUs. • Just because you can does not mean you should. • Yes vSphere has enhanced scheduling. BUT • You still need 2, 4 or 8 cores available to service your multi-threaded applications.
2: Guest Swap or Host Swap • We all know VMware ESX can over commit memory • But as before just be cause you can does not mean you should. • A Guests Operating System can better manage its memory than ESX. • Memory swapped by ESX could be any OS page, it is indiscriminate.
3: vCenter and Guest naming • vCenter can have a name that is up to 50 characters in length. • Sounds good, I can have very descriptive names • However on VM creation the file location for the VMDK file is based on the vCenter Name. • Best Practice is to just use the Machinename.
4: Storage • Extents – they are not funny • But they do have a place • Remember Consistency is the key • Name your Data-stores the same across the Cluster. • Remember it is about spindle count as well as speed of disk and RAID type.
5: Snapshots are not a backup • Do not run your guests on snaps. • Snaps are a very useful technology, use them but remember to commit.
6: Keys to the Kingdom • The Service Console is the master. Protect it • Even with as little as two physical NICs you should take precautions to separate traffic • VLANs are not a security mechanism, but if it is all you have got - use them
7: Remember your log files • During a ESX build, do not just accept the default partitioning table • You are an accident waiting to happen • Always create at least a /var partition • Always increase your /swap to 1600mb.
8: HA and Blade Chassis • We all Know that Blades are an excellent space saving technology, but they do create other major design issues in a VMware environment. • HA has 5 primary masters • Design to a maximum of 4 blades per chassis per cluster.
9: Live Migration with Hyper-V • R2 is just around the corner, Live Migration is here for the Microsoft users. • Remember to Right size your guests as you do not have memory over commit. • However do not expect to be able to Live Migrate your guests. • To migrate with Hyper-V you will need to leave space on your hosts for the machine to move into.
10: Linked Clones in VDI • I once went to a customer site and found that they had just suddenly run out of all space on their Data-Store that were running Linked Clones, Why? • Because somebody thought it a good idea to re-authorise the “Auto-Defrag” feature of Vista in GPO. • Moral – Virtualization is more that just the VI. • To do it properly it means “TRANSFORMATION”
I will be staying on so if you haveany questions, just tap me on the shoulder and ask.