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