Dear folks, We've uploaded the updated version of our MIB proposal about virtual machines controlled by a hypervisor here: http://tools.ietf.org/html/draft-asai-vmm-mib-03
The followings are the known issues related to notifications listed on P.42 of our I-D. We would like to discuss the followings (and other issues you find, of course), so please review the I-D and post your comments to the list. o Issue 1-1) Scalability issue on notifications: The number of virtual machines managed by a bunch of hypervisors in a datacenter possibly becomes several thousands or more. If these virtual machines frequently change their administrative state, many notifications could be trapped. Since an SNMP manager has to handle SNMP traps of these notifications, there exists a scalability issue on handling them. Should we add some `vmXXXNotificationEnable' objects to disable traps for each notification? Or any other ideas? o Issue 1-2) vmDeleted: Is `vmDeleted' required? If the virtual machine is not persistent on the hypervisor, its entry will disappear when it has shutdown. `vmShutdown' can trap the event of shutdown of a virtual machine. So do we remove `vmDeleted' and change `vmShutdown' to carry `vmPersistent' in order to distinguish ``just shutdown'' and ``shutdown and automatically deleted''? o Issue 1-3) vmOperState carried with each notification: In our current proposal, each notification corresponds to the new operational state of a virtual machine, and `vmOperState' indicates the old operational state. For example, when a virtual machine is switched on, the operational state is changed to running from shutdown. In this case, vmRunning with shutdown vmOperState is be generated when the operational state of a virtual machine is about to enter running state. Is this simple and reasonable? Thank you. Hirochika Asai -- Hirochika Asai <[email protected]>, The University of Tokyo _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
