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 may be wrong. Any comments are welcome :) --- Keiichi SHIMA (島 慶一) WIDE project <[email protected]> Research Laboratory, IIJ Innovation Institute, Inc <[email protected]> On 2013/08/29, at 19:59, Juergen Schoenwaelder <[email protected]> wrote: > On Thu, Aug 29, 2013 at 07:27:40PM +0900, SHIMA Keiichi 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. The worst experience when I debug problems is when software > tries to hide reality. And, btw, being blocked is really not uncommon > in a Xen setup. > > $ sudo xm list > Name ID Mem VCPUs State > Time(s) > Domain-0 0 4160 8 r----- 267537.1 > foo 3 512 1 -b---- 39148.0 > bar 17 2048 1 -b---- 71467.1 > baz 20 2048 1 -b---- 80750.0 > bing 6 1024 1 -b---- 66408.8 > bong 8 256 1 -b---- 57365.8 > bang 21 1024 1 -b---- 36534.1 > yum 10 256 1 -b---- 41611.5 > yam 15 1024 1 -b---- 49363.2 > yim 16 2048 1 -b---- 44081.6 > > (Taken from a live machine with names obfuscated.) > > /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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
