On Thu, May 14, 2015 at 04:45:19PM +0000, Romascanu, Dan (Dan) wrote: [...]
Dan, many thanks for the review. I am skipping over the smaller nits. > 16. Page 34-35: I have a big question mark about how the > vmStorageReadLatency and vmStorageWriteLatency objects need to be > used. First the usage of the Counter64 syntax seems odd as these > objects do not count anything and their increase is not > unitary. Second I do not know how to interpret them. What does say a > reading of 'a million' or of 'a billion' mean? It really makes no > sense if not interpreted in conjunction with the number of > respective I/O operations, media type, etc. I guess that the > implementation of these objects is not trivial and probably requires > HW support taking into consideration the microseconds resolution. At > a minimum I guess that some text recommending to the operators how > they are supposed to be used is needed. The only SMIv2 requirement for a Counter64 is that it increases monotonically which is the case here. There is no requirement that a counter increases unitary. By making this a counter, it is clear that one has to to look at the first derivative, that is the change of the counter over time. Obviously, on a lightly loaded hypervisor, the latency should be small but in situations where it increases significantly, you are likely hitting a slowdown of your VMs due to I/O contention instead of CPU limits. These objects are there to identify such situations (and the virtual storage devices involved). > 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. > 18. The Security Considerations section does not include a description of > the security hazards of mis-configuration of the writeable objects (danger of > flooding the network with unwanted notifications) > Perhaps text can be added but I am not sure I see that a data center network will experience any significant load due to these notifications. /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
