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> _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
