Hello, Thank you for your comments.
On 2013/08/30, at 14:16, Juergen Schoenwaelder <[email protected]> wrote: > I do not get your point, probably because of a lack of definition of > 'primary state'. ;-) > > Perhaps you want to write management software that provides other > abstractions on top of what the various MIB modules provide - thats > fine. I doubt the SNMP agent is the right place to provide > abstractions though. So, you are saying that the MIB should provide a kind of raw data, and how it is translated (or understood) should be done in upper layer applications. Is my understanding correct? Yes, I must agree with you. As I mentioned in my previous mail, my understanding of VirtualMachineOperState and yours is a bit different, I guess. I was thinking the state transition is initiated by an operator, and the next state is determined by the result of the operator's action. But you are thinking that VirtualMachineOperState is also changed by other factors (like I/O blocking in a hypervisor level). Once we have a concrete definition of VirtualMachineOperState, maybe my question will be solved. > And for the KVM case, please note that the > process state is already available from other existing MIB modules. Ok, thank you for this information! > I repeat myself: For troubleshooting purposes, you want the real state > and not a classification of states - which may be fuzzy. Or more > precisely, whether a blocked VM is good or bad depends on the context. > Requiring the SNMP agent to figure out the context correctly and to > classify the state accordingly is adding significant complexity and > agent code is much harder to change and adapt than management software. I understand your concern. I am not saying we should not provide real (or detailed) state information. It is certainly useful to get state information as is. As I mentioned above, I believe that the definition of the meaning of VirtualMachineOperState is the key to conclude this discussion. In section 3.2, there is a text about how the vmOperState changes. "The transition of `vmOperState' by the write access to `vmAdminState' and the notifications generated by the operational state changes are summarized in Figure 2." If I'm not missing, there is no other explanation about how the vmOperState should behave. Maybe we need more concrete description in the vmOperState section. Currently, it just says as below. "The current operational state of the virtual machine." Also, if we keep the blocked state and the state machine figure, then it would be better to provide a complete state transition table. The current figure-style state machine lacks transition flows between the blocked state and other states. I don't want to draw that part in the figure, since it will mess up the figure :) How about adding a separate table in a appendix section? Regards, --- Keiichi SHIMA (島 慶一) WIDE project <[email protected]> Research Laboratory, IIJ Innovation Institute, Inc <[email protected]> On 2013/08/30, at 14:16, Juergen Schoenwaelder <[email protected]> wrote: > On Fri, Aug 30, 2013 at 01:00:28PM +0900, SHIMA Keiichi wrote: >> Hello, >> >> On 2013/08/29, at 19:59, Juergen Schoenwaelder >> <[email protected]> wrote: >> >>>> Do we have any usage scenario of the blocked state? >>> >>> I thing this is backwards. I like my SNMP agent to access the current >>> state and report it. It does not matter whether I believe the state is >>> short lived or not. I like to see the actual state - not a translation >>> of it. >> >> I understand that you want to see the 'raw' state of virtual machines. I >> agree with you as an engineer :) >> But as an operator, I tend to think we need some kind of 'translation', or >> in other words, higher level state information here. >> >> My previous wording of 'short-lived' might not be a proper word. Let me try >> to make myself clearer. >> >> Maybe my question is that whether the 'blocked' state is a primary state or >> not, in the sense of virtual machine operation. I think we need to have >> some abstraction here. How it is implemented is a different discussion. >> >> Well, we may provide the implementation specific state to MIB users, but it >> is different level of information. I'm not saying that we should not >> provide any detailed status information through VMM-MIB. For example, in >> the KVM environment, we may want to know the process state information of a >> running 'kvm' process as a detailed state information. >> >> What I want say here is that we probably need 'different' level of >> information, or a model of virtual machine operation. It seems to me that >> the 'blocked' state is not a primary state. It is rather a kind of a >> sub-state of primary states, or an attribute of primary states (e.g. a VM is >> running (and blocked)). >> >> I might think that the name of the 'running' state is misleading. If I >> rephrase the 'running' state, for example, to 'in-operation' state, does my >> opinion become clearer? >> > > I do not get your point, probably because of a lack of definition of > 'primary state'. ;-) > > Perhaps you want to write management software that provides other > abstractions on top of what the various MIB modules provide - thats > fine. I doubt the SNMP agent is the right place to provide > abstractions though. And for the KVM case, please note that the > process state is already available from other existing MIB modules. > > I repeat myself: For troubleshooting purposes, you want the real state > and not a classification of states - which may be fuzzy. Or more > precisely, whether a blocked VM is good or bad depends on the context. > Requiring the SNMP agent to figure out the context correctly and to > classify the state accordingly is adding significant complexity and > agent code is much harder to change and adapt than management software. > > /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 _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
