10 tips for a Happy Hyper-V or VMWare Network

Make sure your external out of bound access is working. (if you are lucky enough to have it that is) There is nothing worse than having to trek to a remote site or drag someone out of bed just to go and press F1 on a keyboard. So test your iLO or IP KVM now and make sure It works over your remote access solution as well.
Keep an eye on those disks. (or better yet have an automated solution to monitor them for you) Not just on the guest machines but on your cluster shared volumes. It is a lot better to forecast a growth trend and plan for disk growth than it is to run out unexpected and suffer an outage or worse, corruption.
Test those backups. Virtualization makes it easier than ever to take portable backups of all your servers but have you ever tested them? It is much better to find out there is a problem in your business continuity plan in a test when everything is working than after a disaster so go plan a test now.
How many hosts can you lose? It is tempting to use all the available CPU and RAM on all your hosts but what happens when you have a failure? Even keeping at least enough spare capacity for the loss of one host can be a risky situation. This is especially true with Hyper-v; if you want to upgrade to the latest 2012 Hyper visor you will need to start again with a new cluster and move hosts over one at a time, so if you only have N+1 spare hosts during a migration you may well have no spare capacity to cope with loss of a host at all.
So where will we restore all these backups to? For all but the largest and most cash rich organizations an off-site backup datacentre is likely to be a dream. Get an agreement in place now for new hardware in the event of a DR situation or have an account ready with Azure/Amazon/Rackspace etc. to host all your guest machines. Once again, test it as the devil is in the details and have as much as possible pre-configured, there is nothing worse than battling firewall rules when a configuration could have been prepared and tested earlier.
Updates, plan ahead how you are going to deploy updates and when. Are you going to have them install automatically or will you need to test them in a dev environment now and deploy them to production later? Either way think about it now and plan accordingly, no one likes downtime and its always a good idea to keep all of your hosts on the same patch level.
Document everything. Something which during the initial build you know like the back of your hand will be quickly forgotten in a few months when you need to re-visit it for a change. What happens when you leave for a new job or fall under a bus? Your current employer will still need to keep things running and its never nice for the newcomer to walk into an undocumented environment where everything has to be worked out from scratch.
Log changes. If you have an official change control procedure then use it, but even if your organization doesn’t have any official change control, write down any changes you are making, in a helpdesk call, email or anywhere you can refer to if required. Better yet try to make changes in a pair. If both you and a colleague agree on a change it is less likely that you have forgotten something crucial and when you leave for your 3 week jungle adventure holiday there is someone else in the team who knows what was done.
Licensing. Make sure your windows hosts are all activated and any VMware hosts have the required license keys installed. You don’t want to have your grace period run out and leave you in the lurch. You have bought licenses haven’t you?
Security, access and auditing. You should know exactly who has access to what and have auditing enabled for all changes. Not so that you can apportion blame but so you know who to talk to about a particular change or can easily spot unauthorised or unexpected changes should they occur. Also “have a go” at your hosts and guests, check what services they have available and if necessary get a professional in to check your security. It is a lot nicer when a penetration tester finds a hole than a malicious hacker.

Leave a Reply Cancel reply