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