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
