On Tue, May 26, 2015 at 10:45:48AM +0900, Keiichi SHIMA wrote: > Hi all, > > >> 17. I am concerned that the current way of defining the > >> notifications switches is too course. Hypervisors may have many VMs > >> in charge, and if each generates one notification per each state > >> changes the numbers can become big even in normal operation. Maybe > >> some throttling mechanism would be useful. Or maybe a couple of more > >> switches that allow to enable only 'critical' notifications > >> (e.g. vmCrashed). > > > > The only situation I can think of where the number of notifications > > will be significant is during restart of a whole rack with many > > hypervisors inside. But even then, things usually take time. (I think > > our Xen hypervisors actually create virtual machines sequentially and > > hence the notifications get actually spaced over time.) It is not > > unlikely that the operating systems inside the hypervisors during > > startup generate significantly more network traffic compared to a few > > hypervisor notifications. That said, during the development of the MIB > > module we moved from generic state change notifications to a set of > > specific notifications and this allows to use SNMPv3 notification > > filtering to filter out notifications people find not useful. > > > I and Asai talked locally and we agree Juergen that the number of > notification events is manageable. > > However we noticed that the 'vmBlocked' notification may be a problem. The > 'blocked' state is defined as 'The operational state of the virtual machine > indicating the execution of the virtual machine is currently blocked, e.g., > waiting for some action of the hypervisor to finish. This is a transient > state from/to other states.' This state transition event may appear more > frequently than other events, since the state is caused by the I/O scheduler > of the hyper visor implementation. > > We think we can simply remove the 'vmBlocked' notification. The 'blocked' > state is a transient state and typically return to the previous state > immediately (once the pending I/O requests completed). >
Yes, this makes sense to me. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
