> I am > OK to accept these modifications if we at the same time close the door > for new features and instead wrap up this MIB module.
I support this approach. Regards, --- Keiichi SHIMA (島 慶一) WIDE project <[email protected]> Research Laboratory, IIJ Innovation Institute, Inc <[email protected]> On 2014/09/29, at 17:07, Juergen Schoenwaelder <[email protected]> wrote: > Hi, > > for me, it is most important to finish up. This project is ongoing for > quite some time meanwhile and I think it is time to deliver. MIB > moduels can be extended after publication as Proposed Standard. I am > OK to accept these modifications if we at the same time close the door > for new features and instead wrap up this MIB module. > > /js > > On Mon, Sep 29, 2014 at 04:27:13PM +0900, Keiichi SHIMA wrote: >> Hello Ian, >> >> Thank you for contributing the text. I personally think the text is fine. >> Let's wait for a while if we receive any comments about the text from other >> authors and WG people. >> >> I believe this modification doesn't affect the current consensus we have >> about the draft. If the text is accepted by the WG, then we'll integrate it >> to the draft and would like to move forward. >> >> Regards, >> --- >> Keiichi SHIMA (島 慶一) >> WIDE project <[email protected]> >> Research Laboratory, IIJ Innovation Institute, Inc <[email protected]> >> >> >> >> On 2014/09/29, at 15:33, Ian West <[email protected]> wrote: >> >>> Attached is a diff against the text form of the draft, I believe I have >>> addressed the changes that >>> might be required. >>> >>> Also for convenience the actual text of the proposed additional counters is >>> as follows. >>> >>> vmStorageReadOctets OBJECT-TYPE >>> SYNTAX Counter64 >>> MAX-ACCESS read-only >>> STATUS current >>> DESCRIPTION >>> "The total number of bytes read from this device. >>> Discontinuities in the value of this counter can occur >>> at re-initialization of the hypervisor, and >>> administrative state (vmAdminState) changes of the >>> virtual machine." >>> ::= { vmStorageEntry 15 } >>> >>> vmStorageWriteOctets OBJECT-TYPE >>> SYNTAX Counter64 >>> MAX-ACCESS read-only >>> STATUS current >>> DESCRIPTION >>> "The total number of bytes written to this device. >>> Discontinuities in the value of this counter can occur >>> at re-initialization of the hypervisor, and >>> administrative state (vmAdminState) changes of the >>> virtual machine." >>> ::= { vmStorageEntry 16 } >>> >>> vmStorageReadLatency OBJECT-TYPE >>> SYNTAX Counter64 >>> MAX-ACCESS read-only >>> STATUS current >>> DESCRIPTION >>> "The total number of microseconds read requests have been >>> queued for this device. >>> This would typically be implemented by storing the high >>> precision >>> system time stamp of when the request is received from the >>> Virtual >>> Machine with the request, the difference between this initial >>> time >>> stamp and the time at which the requested operation has >>> completed >>> should be converted to microseconds and accumulated. >>> Discontinuities in the value of this counter can occur >>> at re-initialization of the hypervisor, and >>> administrative state (vmAdminState) changes of the >>> virtual machine." >>> ::= { vmStorageEntry 17 } >>> >>> vmStorageWriteLatency OBJECT-TYPE >>> SYNTAX Counter64 >>> MAX-ACCESS read-only >>> STATUS current >>> DESCRIPTION >>> "The total number of microseconds write requests have been >>> queued for this device. >>> This would typically be implemented by storing the high >>> precision >>> system time stamp of when the request is received from the >>> Virtual >>> Machine with the request, the difference between this initial >>> time >>> stamp and the time at which the requested operation has >>> completed >>> should be converted to microseconds and accumulated. >>> Discontinuities in the value of this counter can occur >>> at re-initialization of the hypervisor, and >>> administrative state (vmAdminState) changes of the >>> virtual machine." >>> ::= { vmStorageEntry 18 } >>> >>> Thankyou again for your consideration and feedback. >>> >>> Regards, >>> Ian West. >>> >>> -----Original Message----- >>> From: Juergen Schoenwaelder [mailto:[email protected]] >>> Sent: Monday, 22 September 2014 15:25 >>> To: Keiichi SHIMA >>> Cc: Ian West; [email protected]; ASAI Hirochika; SEKIYA Yuji; Tina Tsou; >>> Cathy Zhou; ESAKI Hiroshi; Michael MacFaden >>> Subject: Re: [OPSAWG] Comments from niw.com.au operator on draft on >>> >>> Hi, >>> >>> it would help if people would propose concrete text of what the >>> description of the counters would be. What is most important is that >>> we define counters that are implementable in a meaningful way on a >>> large set of different hypervisors. >>> >>> /js >>> >>> On Sun, Sep 21, 2014 at 09:36:55PM +0900, Keiichi SHIMA wrote: >>>> Hello Ian, >>>> >>>>> Your description of the accumulated milliseconds (or potentially >>>>> microseconds to allow for things getting a lot faster) is exactly >>>>> what I had in mind. The delta of this figure divided by the delta iops, >>>>> should give an approximate measure of the load the io >>>>> subsystem is under. >>>> >>>> Thank you for the clarification. I got better understanding of your >>>> proposal. I tend to agree that the above usage may be useful. >>>> >>>> I again don’t have any strong support/objection for adding the above new >>>> entry to the VMM-MIB. I’d like to hear if other authors and people in >>>> this WG support this. >>>> >>>> Regards, >>>> --- >>>> Keiichi SHIMA (島 慶一) >>>> WIDE project <[email protected]> >>>> Research Laboratory, IIJ Innovation Institute, Inc <[email protected]> >>>> >>>> >>>> >>>> 2014/09/21 11:27、Ian West <[email protected]> のメール： >>>> >>>>> Hello, >>>>> >>>>> Thankyou for your clarification and feedback. >>>>> >>>>> Your description of the accumulated milliseconds (or potentially >>>>> microseconds to allow for things getting a lot faster) is exactly >>>>> what I had in mind. The delta of this figure divided by the delta iops, >>>>> should give an approximate measure of the load the io >>>>> subsystem is under. >>>>> >>>>> Regards, >>>>> Ian West. >>>>> >>>>> -----Original Message----- >>>>> From: Keiichi SHIMA [mailto:[email protected]] >>>>> Sent: Saturday, 20 September 2014 18:03 >>>>> To: [email protected] >>>>> Cc: SHIMA Keiichi; ASAI Hirochika; Jürgen Schönwälder; SEKIYA Yuji; Tina >>>>> Tsou; Cathy Zhou; ESAKI Hiroshi; Ian West; Michael MacFaden >>>>> Subject: Re: [OPSAWG] Comments from niw.com.au operator on draft on >>>>> >>>>> Hello, >>>>> >>>>>> It would be really nice to have IO service times as well, ie something >>>>>> like accumulated milliseconds of wait time for io servicing, >>>>>> this might be a harder to instrument. A counter64 of cumulative ms (us?) >>>>>> awaiting delivery is a really handy read/write latency metric. >>>>> >>>>> Let me clarify the above sentence. Is the service time, you are talking >>>>> about, the time between an I/O request arrives to the storage subsystem >>>>> (in a hypervisor) and the time its response is returned to the calling >>>>> VM? And you want to add an entry to keep an accumulated value of those >>>>> I/O request delay? >>>>> >>>>> >>>>>> The vmStorageEntry statistics while having read operation and write >>>>>> operation counters don't allow for measuring the volume of read and >>>>>> write traffic. It would be useful to include 64 bit counters for read >>>>>> and write octets. >>>>> >>>>> I don’t have any particular opinion on this topic. If people in this WG >>>>> support adding the above entries, then maybe it is possible to add them. >>>>> >>>>> Regards, >>>>> --- >>>>> Keiichi SHIMA (島 慶一) >>>>> Research Laboratory, IIJ Innovation Institute, Inc <[email protected]> >>>>> WIDE project <[email protected]> >>>>> >>>>> >>>>> >>>>> 2014/09/18 2:45、Michael MacFaden <[email protected]> のメール： >>>>> >>>>>> Hi authors, >>>>>> >>>>>> Regarding: https://datatracker.ietf.org/doc/draft-ietf-opsawg-vmm-mib/ >>>>>> >>>>>> Ian as allowed me to forward you his comments on the draft. >>>>>> >>>>>> Cheers, >>>>>> Mike MacFaden >>>>>> >>>>>> >>>>>> From: Ian West <[email protected]> >>>>>> Subject: RE: Mail regarding draft-ietf-opsawg-vmm-mib >>>>>> Date: September 16, 2014 at 3:18:08 AM PDT >>>>>> To: 'Michael MacFaden' <[email protected]> >>>>>> >>>>>> >>>>>> Overall I think it looks great. >>>>>> >>>>>> It would be really nice to have IO service times as well, ie something >>>>>> like accumulated milliseconds of wait time for io servicing, >>>>>> this might be a harder to instrument. A counter64 of cumulative ms (us?) >>>>>> awaiting delivery is a really handy read/write latency metric. >>>>>> >>>>>> The cputime and memory figures look good. >>>>>> >>>>>> I am thinking there would be a storage object for the swap space which >>>>>> would give most of the paging stats if actual byte counts were added ? >>>>>> >>>>>> Links back to the ifindex should also tie into vswitch I think ? My >>>>>> current walks of vmware are nesting vswitch ports nicely so that’s >>>>>> looking good. Network stats seem good already, its primarily the per >>>>>> vhost cpu usage and io stats that are weak from a real time >>>>>> perspective, this MIB looks like it should cover it really well. >>>>>> >>>>>> Is this intended to be a vsphere (central management) resource, or a per >>>>>> physical host (or both, which would be great) ? >>>>>> >>>>>> If you were to query this from a vsphere central management host, I am >>>>>> thinking you might want to add to the vmtable an identifier >>>>>> for the physical host that the vm is currently running on. This would >>>>>> make the table useful either standalone or across a bunch of >>>>>> physical hosts. >>>>>> >>>>>> Ill think on it some more, this seems like a great step forward over >>>>>> whats there now already in VMware’s implementation. >>>>>> >>>>>> >>>>>> The vmStorageEntry statistics while having read operation and write >>>>>> operation counters don't allow for measuring the volume of read and >>>>>> write traffic. It would be useful to include 64 bit counters for read >>>>>> and write octets. >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OPSAWG mailing list >>>>>> [email protected] >>>>>> https://www.ietf.org/mailman/listinfo/opsawg >>>>> >>>>> >>>> >>> >>> -- >>> 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/> >>> >>> <draft-ietf-opsawg-vmm-mib-01.diff> >> > > -- > 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
