Friday, November 28, 2008

VMware Infrastructure 3: Install and Configure Day 4

I just finished the fourth and final day of the VMware Infrastructure 3 course. I think overall it was pretty worthwhile. Definitely picked up a few good tips and learnt more about some of the more detailed features/functions of the products - especially the newer stuff. And best of all - I just got a nice new VMware bag :-) Cool. It's quite a good one too (better than the Cisco one from Networkers this year!).

Now to study for the VCP exam! (And maybe build myself an ESX Server lab machine at home to help me revise)

Here are my notes on the topics we've been through today.

Resource Management
  • VMotion network can be used as a secondary heartbeat network for HA
  • The final thing the VMkernel does after a VMotion is a Reverse ARP, ensuring the switch knows the Virtual Machine's MAC address is accessible via the 2nd ESX Host
  • The time between VMotion and scheduling instructions on the 2nd ESX Host's CPU is typically between 50 and 200ms.
  • For VMotion to work there must be a virtual switch and port group with an identical name (case sensitive) on the 2nd ESX Host.
  • As CPU affinity can cause incompatibility with VMotion only use in a lab/testing environment.

Resource Monitoring

  • HEC = Hardware Execution Context. An HEC is typically a CPU core (today), but also a HT CPU.
  • vmmemctl = Balloon Driver. Takes RAM from guest machines when physical RAM in host is scarce, causing Guests to Page/Swap more.
  • By default the Balloon Driver will not expand beyond 65% of the VM configured memory.
  • Use iometer to generate artificial disk load for testing purposes

Data and Availability Protection

  • Service Console backups are in reality limited to a small amount of configuration settings, 3rd party software/agents, and logs in /var/log partition.
  • ESX Host restore can be scripted using anaconda kick-start files, using a finish script to recreate Virtual Switch settings etc.
  • VMware HA does not increase availability, it decreases downtime.
  • VMware HA restarts virtual machines when physical machines fail.
  • VMware HA network ports:
  • Incoming - TCP/UDP 8042-8045
  • Outgoing - TCP/UDP 2050-2250
  • VMware HA best practices: http://kb.vmware.com/kb/1002080

Posted by at
Labels:

2 comments:

Steve Chambers said...

Hey mate, can you please clarify your comment about vMotion, CPU compatibility and "only use in test/lab environments".

You _don't_ mean just use vMotion in test/dev, right?

vMotion is critical to prod (for DRS, and for zero downtime maintenance).

Just checking... :-)

4:57 am
Clint said...

Hi Steve, the note refers to careful use of the 'CPU Affinity' setting - not VMotion itself. The point was, configuring CPU Affinity on a VM can lead to problems when you attempt to VMotion that VM, reducing the effectiveness of having a VMotion-capable environment. So CPU affinity is only usually used/recommended in a test or lab environment (e.g when wanting to force one or more VMs to run on the same CPU or CPUs). Does that help to clarify it better?

7:02 am

Post a Comment

Subscribe to: Post Comments (Atom)