My apologies for the delay in response, and thankyou for this feedback. I will endeavour to put my suggestions into the form you suggest over the weekend and submit them back to the list.
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/>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
