Posts Tagged ‘esx’

Using Nagios NIBs with ESX

Thursday, March 22nd, 2012

What is a MIB

A MIB is a Management Information Base. It is an index based upon a network standard that categorizes data for a specific device so that SNMP servers can read the data.

Where to Obtain VMware vSphere MIBs

VMware MIBs are specific to VMware Version, you can try to use the ESX MIBs for ESXi. They can be downloaded from http://downloads.vmware.com. Click on VMware vSphere > find the version of ESX that you are running under “Other versions of VMware vSphere” (the latest version will be the page that you’re on). Click on “Drivers & Tools”. Then click on “VMware vSphere x SNMP MIBs” where “x” is your version.

How to add VMware vSphere MIBs into Nagios

  • Download the VMware vSphere MIBs from http://downloads.vmware.com
  • Copy the MIB files to /usr/share/snmp/mibs/
  • Run check_snmp -m ALL so it detects the new MIBs

Editing snmpd.conf and starting snmpd on ESX

  • Stop snmpd: service snmpd stop
  • Backup snmp.xml: cp /etc/vmware/snmp.xml /etc/vmware/snmp.xml.old
  • Edit snmp.xml with your favorite CLI text editor to have the following:

<config>
  <snmpSettings>
    <communities>public</communities>
    <enable>true</enable>
    <port>171</port>
    <targets>127.0.0.1@162/public</targets>
  </snmpSettings>
</config>

  • Backup snmpd.conf: cp /etc/snmp/snmpd.conf /etc/snmp/snmpd.conf.old
  • Use your favorite CLI text editor and edit /etc/snmp/snmpd.conf
  • Erase everything in it.
  • Add in the following and save it:

load  99 99 99
syslocation ServerRoom
syscontact  “ESX Administrator”
rocommunity  public
view systemview included .1.3.6.1.4.1.6876
proxy -v 1 -c public 127.0.0.1:171 .1.3.6.1.4.1.6876

  • Change “syslocation” and “syscontact” to whatever you want
  • Save your work
  • Configure snmpd to autostart: chkconfig snmpd on
  • Allow SNMP through firewall: esxcfg-firewall –e snmpd
  • Start the SNMP daemon: service snmpd start
  • Restart the mgmt-vmware service: service mgmt-vmware restart

Determining OID

OID’s are MIB specific variables that you can instruct an SNMP server monitor to look for. These variables can be determined by reading the MIBs. One tool that assists with doing this is MIB Browser by iReasoning Networks http://tl1.ireasoning.com/mibbrowser.shtml. MIB Browser can run on Windows, Mac OS X, and Linux/UNIX. To obtain the appropriate OID’s:

  • Load the MIBs in MIB Browser by going to File > Load Mibs
  • Manually comb through to find the OID you want (it will be connected to a string that will be similar to wording used in VSphere).

Example:

  • SNMP MIBs was downloaded from http://downloads.vmware.com for ESX 4.1
  • Loaded MIB for VMWARE-RESOURCES-MIB into MIB Browser
  • Searched for “Mem” (Edit > Find in MIB Tree), found “vmwMemAvail”, the OID for this is .1.3.6.1.4.1.6876.3.2.3.0 (use the OID shown in the dropdown that is near the menu in the MIB Browser – it will show the full OID which will sometimes include a “0″ at the end that the OID listed towards the bottom of the window will not)
  • Add OID into remotehost.cfg (or linux config file) file in Nagios

define service{
use             generic-service ; Inherit values from a template
host_name           ESX4_1
service_description  Memory Available
check_command       check_snmp!-C public -o .1.3.6.1.4.1.6876.3.2.3.0 -m all
}

host_name: the name of the device (whatever you want to call it)
service_description: the name of the service you are monitoring (whatever you want to call it)
check_command: -C is to define the community SNMP string, -o is to define the OID to read, -m is to define which MIB files to load – to be more specific, for this example you can narrow “-m all” to “-m VMWARE-RESOURCES-MIB.MIB”

Once you’ve done the above you should be able to monitor “Memory Available” for ESX through Nagios.  Repeat the procedure, changing steps where applicable for the specific OID you want to monitor.  If you have questions, or need assistance, please contact 318, Inc. at 1-877-318-1318.

Low Cost Storage for VMware

Wednesday, July 15th, 2009

EMC owns VMware. EMC owns Iomega. As a great result of these two acquisitions EMC is now able to provide the StorCenter, a 1U shelf of storage with 4TB (~3TB with RAID5) of capacity that has been qualified to run VMware.  For environments looking to get started with Vmotion and some of the clustered aspects of VMware the Iomega StorCenter offers a nice alternative to the high dollar storage arrays that EMC offers under their own brand.

The StorCenter can provide iSCSI LUNs to host Virtual Machines.  It’s not going to get the same IO as storage of a higher class will get, but for smaller environments with 2 or 3 physical hosts and a number of virtual machines, the StorCenter allows a number of features that can’t be had through traditional direct attached storage.

As an EMC reseller, 318 can help guide you through the process of a containment or a consolidation project, whether you’re looking to deploy 300 TB of fibre channel based LUNs to accommodate your environment or 3TB, we’re here to help!

VMware vSphere 4 is Here!

Thursday, April 23rd, 2009

At a VMUG meeting in Minneapolis in December, VMware employees mentioned that Virtual Infrastructure would be getting a new name, vSphere.  A few days ago, VMware officially announced vSphere, the successor to the Virtual Infrastructure (VI) product line.  VMware is hailing vSphere as the first true cloud-based operating system, hoping to capitalize on the hype that surrounds cloud computing.

VMware has had products available for years that allow administrators to cluster resources and place virtual machines on a virtualized abstraction layer that spans multiple hosts, pooling RAM, CPU and other system resources.  When we had heard there was a raging debate about whether a private cloud was possible, we immediately though of all of our successful implementations of the VI product.  vSphere is designed from the ground up to sit on low cost and energy efficient computing resources and allow for the flexible deployment of systems onto the cluster.  This allows organizations ranging from small businesses to enterprise, from education to government to deploy new data protection and high availability resources, to pool IT assets in a manner not previously available.

The key components of vSphere all not all new.  ESX and ESXi are the hypervisor.  These sit on the physical machines (aka the Hosts) and build the virtualization layer.  Sitting on top of the hypervisors is vCenter Server, which allows for the actual provisioning, monitoring, physical to virtual conversion process and centralized management.  The vCenter Update Manager keeps all of the ESX systems updated (as well as some of the VMs themselves to help reduce the surface space of update management).  The VMware High Availability piece gives failover between hosts.  VMsafe is a another component that provides security APIs; while offerings from 3rd party developers are fairly immature expect this to grow rapidly as the virtualization industry moves into its next stage.

vSphere was built for microprocessers.  The Nehalem and its successor, Westmere, are designed with collaboration from VMware; as such, they are built for virtualization.  When you are looking to plan for a potential upgrade to vSphere, it’s important to keep in mind that each member of a vSphere cloud is going to run at the speed of the slowest host.  Therefore, you will have tiers of VMware virtualized clouds, each with a class of system in it (for larger environments).  The Nehalem and Westmere are designed for 8GB of RAM, so you’ll want to make sure to put plenty of memory into the cluster nodes, which have a diminishing return on investment (in terms of memory) around 120GB (so don’t be afraid of going hog wild on the memory front, those VMs need it!).

Overall, our tests of vSphere have shown a considerable performance gain for the guest operating systems running on hosts with newer hardware.  Older assets have a lower impact on performance, but still have a slight upgrade.  The biggest management features that we’re finding useful are an upgraded vCenter (for converting those physical systems over to virtual hosts), enhancements to Vmotion and automation.  With the latest tools it is fairly straight forward to automate nearly every task using vCenter, including the deployment of new virtual machines based on templates, restarting a virtual machine and migrating them using Vmotion.

While the vSphere product may seem overwhelming at first, it begins to bring into focus a contained and mature VMware based infrastructure.  There are a lot of new features; but there is bound to be a lot of marketing spin and while I’m sure it can, out of the box vSphere will not do your laundry.  In order to help guide you through the planning phases of the next generation of the data center (which is after all, the true target of vSphere 4), 318 is here to provide the experience you need with regards to VMware licensing, architecture and of course support – be it with the guests, the hosts, the storage layer or the virtualization layer itself!

ESX Patch Management

Tuesday, April 14th, 2009

VMware’s ESX Server, like any system, needs to be updated regularly. To see what patches have been installed on your ESX server use the following command:

esxupdate -query

Once you know what updates have already been applied to your system it’s time to go find the updates that still need to be applied. You can download the updates that have not yet been run at http://support.vmware.com/selfsupport/download/. Here you will see a bevy of information about each patch and can determine whether you consider it an important patch to run. At a minimum, all security patches should be run as often as your change control environment allows. Once downloaded make sure you have enough free space to install the software you’ve just downloaded and then you will need to copy the patches to the server (using ssh, scp or whatever tool you prefer to use to copy files to your ESX host). Now extract the patches prior to running them. To do so use the tar command, as follows:

tar xvzf .tgz

Once extracted, cd into the patch directory and then use the esxupdate command with the update flag and then the test flag, as follows:

esxupdate –test update

Provided that the update tests clean, run the update itself with the following command (still with a working directory inside the extracted tarball from a couple of steps ago):

esxupdate update

There are a couple of flags that can be used with esxupdate. Chief amongst them are -noreboot (which doesn’t reboot after a given update), -d, -b and -l (which are used for working with bundles and depots).

If esxupdate fails with an error code these can be cross referenced using the ESX Patch Management Guide.

You can also run patches without copying the updates to the server manually, although this will require you to know the URL of the patch. To do so, first locate the patch number that you would like to run. Then, open outgoing ports on the server as follows:

esxcfg-firewall -allowOutgoing

Next, issue the esxupdate command with the path embedded:

esxupdate –noreboot -r http:// update

Once you’ve looped through all the updates you are looking to run, lock down your ESX firewall again using the following command:

esxcfg-firewall -blockOutgoing