2007-01-15 Originally added: 1.0.7 VMware Virtual Infrastructure Plugin Contents 1. System Requirements 2. VI Perl Toolkit Installation 3. Unnoc Configuration -- service_url 4. Unnoc Configuration -- console statistics 5. Examples Unnoc now supports VMWare's Virtual Infrastructure. It currently supports ESX and Virtual Center servers. It has been tested against: ESX 3.0.1 Virtual Center 2.0.1 It can either talk to a VCMS (VirtualCenter Management Server) server or it can directly talk to an ESX server. It will discover all VM's that are valid on all servers and will graph CPU and memory usage for all Virtual Machines. New to 1.0.10, the plugin now graphs Disk Usage and Network traffic as well. These counters are read as 'real-time' from the ESX/VCMS host, and will place those in graphs. You can see the traffic if you click on any of the Network Adapters or Storage Adapters. The current VI implementation is designed to be used as a simple overview of how each ESX server is performing. It is not intended to replace any of the current reporting functions, or other 3rd party reporting programs. It is merely to be used as a "first line" of efficiency and utilization. This has not been tested on any previous versions. Unnoc currently only knows about VirtualCenter servers and ESX servers. 1. System Requirements Initially the plugin was written with using 100% pure SNMP, however the report functionality is very limited with the SNMP module that ships with ESX server. The data was not entirely acurate and much of the data was not retrievable from SNMP (CPU Mhz usage, for instance). So I re-wrote it with the VI Perl Toolkit, available from Sourceforge: http://sourceforge.net/projects/viperltoolkit It uses standard interface (SOAP) that VMWare provides and recommends. VMWare provides many different toolkits and standardized way of polling VCMS and ESX servers. I didn't find too much information on the SNMP modules, but there's lots of information about their SOAP interface. It logs in with a valid VI Client username and password, so this means that the same exact information that is available from the VI client, is now available through the SDK. This makes writing a plugin for it much, much easier. 2. VI Perl Toolkit Installation Download the toolkit from SourceForge: http://sourceforge.net/projects/viperltoolkit See the docs on installation, it will require a few more perl modules. 3. Unnoc Configuration -- service_url Unnoc configuration is very easy. First, Unnoc needs a valid user to be able to login to the ESX/VCMS server. I highly recommend creating a dedicated user with READ-ONLY access. There are two approaches to configuration: a. With a VirtualCenter server b. Without a VirtualCenter server Use only one of the two approaches. a. With a VirtualCenter server If you have a VCMS server that you use to manage your ESX servers, then the recommended approach is to simply point Unnoc to your VCMS server and let it figure out what VM is associated with what ESX server. To do this, create a RO user on your VCMS server and tell Unnoc about it in the unnoc.conf file: host { hostname = vcserver123 service_url = https://vcserver123/sdk/vimService type = vcms user = vcms_user_name password = vcms_password } The above service_url is the default service_url for ESX and VCMS out of the box. See the VMWare documentation for more information on it. The service_url field is required. b. Without a VirtualCenter server If you only have a few ESX servers and do not use a VCMS server, then you can also use Unnoc to monitor each VM's CPU and Memory usage on the ESX server. To do this, create a RO user on your ESX server and tell Unnoc about it in the unnoc.conf file: host { hostname = server123 service_url = https://server123/sdk/vimService type = esx user = esx_user_name password = esx_password } host { hostname = server345 service_url = https://server345/sdk/vimService type = esx user = esx_user_name password = esx_password } The above service_url is the default service_url for ESX and VCMS out of the box. See the VMWare documentation for more information on it. The service_url field is required. The "service_url" is the magic configuration option that tells unnoc to login to the VI service console of the server. REMEMBER: only use one of the two approaches, otherwise you will have unpredictable results. 4. Unnoc Configuration -- console statistics You can also monitor the actual console of each of your servers as well (i.e. the disk usage, CPU usage, memory usage and network traffic of each VCMS and ESX server, in the same way that you monitor all other servers on Unnoc). To do this, you must enable SNMP on each ESX server and on the VCMS server. SNMP is only required if you plan on doing this. To tell Unnoc that you want to also check the console statistics of each of the VCMS/ESX server, simply specify the 'community' line: For VCMS: host { hostname = vcserver123 service_url = https://vcserver123/sdk/vimService type = vcms user = vcms_user_name password = vcms_password community = public } For ESX: host { hostname = server123 service_url = https://server123/sdk/vimService type = esx user = esx_user_name password = esx_password community = public } 5. Examples Below are a few configuration examples. -------------------------------------------------------------------- Scenario 1: Components: 1 VCMS server - vc1 3 ESX servers managed by vc1 - esx1, esx2, esx3 user information: username: unnoc password: unnoc1monitor You want to: - Monitor VM usage - Monitor console statistics on all ESX servers - Monitor console statistics on the VCMS server (first enable SNMP on vc1, esx1, esx2 and esx3) host { hostname = vc1 service_url = https://vc1/sdk/vimService type = vcms user = unnoc password = unnoc1monitor community = public } host { hostname = esx1, esx2, esx3 community = public type = esx } Notice how the service_url is only specified on the VCMS server. -------------------------------------------------------------------- Scenario 2: Components: 1 VCMS server - vc1 3 ESX servers managed by vc1 - esx1, esx2, esx3 1 standalone ESX server - esx4 user information on vc1: username: unnoc password: unnoc1monitor user information on esx4: username: unnocmon password: monitor55monitor You want to: - Monitor all VM's - Monitor console statistics on VCMS server - Monitor console statistics on all ESX servers (first enable SNMP on vc1, esx1, esx2, esx3 and esx4) host { hostname = vc1 service_url = https://vc1/sdk/vimService type = vcms user = unnoc password = unnoc1monitor community = public } host { hostname = esx4 service_url = https://esx4/sdk/vimService community = public type = esx user = unnocmon password = monitor55monitor } host { hostname = esx1, esx2, esx3 community = public type = esx } Notice the service_url is specified on the VCMS server vc1 and on the ESX server esx4 because esx4 is standalone -------------------------------------------------------------------- Scenario 3: Components: 3 standalone ESX servers: esx1, esx2 and esx3 user information on all ESX servers: username: unnoc password: unnoc1monitor You want to: - Monitor VM usage - Monitor console statistics on all ESX servers host { hostname = esx1 service_url = https://esx1/sdk/vimService community = public type = esx user = unnoc password = unnoc1monitor } host { hostname = esx2 service_url = https://esx2/sdk/vimService community = public type = esx user = unnoc password = unnoc1monitor } host { hostname = esx3 service_url = https://esx3/sdk/vimService community = public type = esx user = unnoc password = unnoc1monitor } Notice how each of the ESX servers gets its own service_url directive. -------------------------------------------------------------------- Scenario 4: Components: 1 VCMS server - vc1 3 ESX servers managed by vc1 - esx1, esx2, esx3 user information on all ESX servers: username: unnoc password: unnoc1monitor You want to: - Monitor VM usage only (first enable SNMP on vc1, esx1, esx2, esx3 and esx4) host { hostname = vc1 service_url = https://vc1/sdk/vimService type = vcms user = unnoc password = unnoc1monitor } Notice how we only specify the VCMS server. You can still use the standard 'group' and 'description' variables to indicated HTTP groups for the index.php file. VMWare information SDK Reference Guide: http://pubs.vmware.com/vi30/sdk/ReferenceGuide/ vim:tw=72:wm=1