Bug 642556

We have spun up an upstream subproject to implement SNMP support and have created a proof-of-concept implementation, which we've discussed with interested members of the community who have expressed interest in participating.  We expect an initial implementation in the next 6 - 8 weeks.

Created attachment 475478 [details]
initial proof of concept implementation

created a new sub-project libvirt-snmp:
   git://libvirt.org/libvirt-snmp.git

it is currently being reviewed by upstream community. If everything goes well, we could have the package for 6.2.

The sub-project made it through Fedora package review process and there will be package for F15 (in updates repo)

https://bugzilla.redhat.com/show_bug.cgi?id=681558

https://koji.fedoraproject.org/koji/packageinfo?packageID=11739

[Reposted original request, customer-identifying information removed]

   2. What is the nature and description of the request?
 Provide full snmp functionality for libvirtd

   3. Why does the customer need this? (List the business requirements here)
 We run a telco here at [...] We monitor our vast network using snmp and all
performance information is in one place. This allows us to create views of
entire platforms end to end, as well as archive historical data and even
provide billing. Having all information in one place also allows for
isolating faults using highly accurately correlated events end to end
through a platform or platforms.

We can also generate alarm based on data from a single polled oid, or from a
number of conditions in different locations on different devices.

SNMP is the standard for monitoring and is extremely well understood as well as
computationally efficient. Most vendors provide outstanding SNMP agents with
well conceived MIBS. Allowing us an excellent view of performance and of
events.

We would like to monitor our kvm hosts thoroughly and bring their statistics
together with those from network and storage to provide single page overviews
of our platforms. Additionally we want to be able to correlate performance.

We also want our kvm hosts to send snmp traps on events so they can tell us
through our monitoring system when hypervisor events occur. 

   4. How would the customer like to achieve this? (List the functional
requirements here)
A. We require libvirtd to be enhanced such that metrics for the status and
performance of the hypervisor (KVM) are available via snmp. Most likely this
would be created as an extension of the net-snmp daemon.

Net-snmp allows three methods to add new data. Those are running an external
command, embedded perl, or proxying to another agent. Our preference is either
an external command or embedded perl.

This would include listing the vms on the host, their status, the status of the
host (ie details not otherwise available via snmp standard mibs) as well as
hypervisor settings and so forth.

B. We require that libvirtd be configurable to send snmp traps on events. This
should be flexible enough to send traps to a number of targets simultaneously,
and to send traps to clear alarms.

C. Extending libvirtd so that it can be controlled via snmp would also be
desirable. For example, stopping and starting vm's with an snmp set - migrating
vms with an snmp set.

D. OUI RedHat mibs should be supplied and published for the above. 

   5. For each functional requirement listed in question 4, specify how Red Hat
and the customer can test to confirm the requirement is successfully
implemented.

   6. Is there already an existing RFE upstream or in Red Hat bugzilla?
 No

   7. How quickly does this need resolved? (desired target release)
 Major

   8. Does this request meet the RHEL Inclusion criteria (please review)
 Yes

   9. List the affected packages
 libvirtd, snmp

Monitoring features
===================
1. Status of a specific guest(running, suspended, stopped etc).
2. Status of all guests (should be able to function as a 'list all guests'
command)
3. Resource utilization of a specific guest (memory, CPU, per network device,
per block device, per character device)
4. The same in a table for all guests
5. Configuration of a specific guest


Traps
=====
1. hypervisor started
2. hypervisor stopped
3. guest started
4. guest stopped
5. guest suspended
6. guest resource allocation changed
7. other gust status change?


Management
===========
1. Start guest
2. Stop guest
3. Suspend guest
4. Create snapshot of guest
5. Modify amount of available RAM
6. Modify number of VCPUs
7. Modify IO limits per available device

There is some information about what has been implemented in the agent at:

http://wiki.libvirt.org/page/Libvirt-snmp

I think, that this BZ is all done. Project was started and have requested features. Therefore moving to POST.

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
This package provides SNMP bindings for libvirt. It allows user to control lifecycle of a domain over SNMP and receive status changes via SNMP traps/notification system.

Okay, built in brew, package libvirt-snmp-0.0.2-1.el6,

Daniel

    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1 +1,2 @@
-This package provides SNMP bindings for libvirt. It allows user to control lifecycle of a domain over SNMP and receive status changes via SNMP traps/notification system.+System monitoring via SNMP
+    This feature provides KVM support for stable technology that is already used in data center with bare metal systems. SNMP is the standard for monitoring and is extremely well understood as well as computationally efficient. System monitoring via SNMP in Red Hat Enterprise Linux 6.2 allows the KVM hosts to send SNMP traps on events so that hypervisor events can be communicated to the user via standard SNMP protocol. This feature is provided through the addition of a new package: libvirt-snmp. This feature is introduced as a Technology Preview.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHEA-2011-1609.html