On Thu, Dec 19, 2013 at 08:02:16AM -0800, Gary Kotton wrote: > > > On 12/19/13 5:50 PM, "Daniel P. Berrange" <[email protected]> wrote: > > >On Tue, Dec 17, 2013 at 04:28:30AM -0800, Gary Kotton wrote: > >> Hi, > >> Following the discussion yesterday I have updated the wiki - please see > >> > >>https://urldefense.proofpoint.com/v1/url?u=https://wiki.openstack.org/wik > >>i/Nova_VM_Diagnostics&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZ > >>yF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=vzUZT3t%2BPvKlvBTFueAjUjo8YUZvDE > >>tRLmlzFb5ORuM%3D%0A&s=d13969885872ea187937a89d12aab9b36b51452ba47e35c7e41 > >>692335967b9f7. The proposal is > >> backwards compatible and will hopefully provide us with the tools to be > >> able to troubleshoot VM issues. > > > >Some comments > > > > "If the driver is unable to return the value or does not have > > access to it at the moment then it should return 'n/a'." > > > >I think it is better if the driver just omitted any key that > >it doesn't support altogether. That avoids clients / users > >having to do magic string comparisons to identify omitted > >data. > > I am fine with this. If the data is marked optional then whoever is > parsing the data should check to see if the field exists prior. > > > > > "An ID for the diagnostics version. The structure defined below > > is version 1 (Integer)" > > > >What are the proposed semantics for version numbers. Do they incremented > >on any change, or only on backwards incompatible changes ? > > The purpose of this was to be backward compatible. But I guess that if we > go with the optional approach then this is redundant. > > > > > "The amount of time in seconds that the VM has been running (Integer)" > > > >I'd suggest nano-seconds here. I've been burnt too many times in the > >past providing APIs where we rounded data to a coarse unit like seconds. > > Sure, sounds reasonable.
Oh hang on, when you say 'amount of time in seconds the VM has been running' you're meaning wall-clock time since boot. Seconds is fine for wall clock time actually. I was getting mixed up with CPU utilization time, since libvirt doesn't actually provide any way to get "uptime". > >Let client programs convert from nanoseconds to seconds if they wish > >to display it in that way, but keep the API with the full precision. > > > > "The version of the raw data" > > I guess that this is redundant too. > > > > >Same question as previously. > > > > > > > >The allowed keys in network/disk/memory details seem to be > >unduly limited. Just having a boolean "activity" for disk > >or NICs seems almost entirely useless. eg the VM might have > >sent 1 byte when it first booted and nothing more for the > >next 10 days, and an admin can't see this. > > > >I'd suggest we should follow the much expanded set of possible > >stats shown by the libvirt driver. These are pretty common > >things to show for disk/nic activity and a driver wouldn't have > >to support all of them if it doesn't have that info. > > Ok. I was just trying to provide an indicator for the admin to dive into > the raw data. But I am fine with this. > > > > >It would be nice to have CPU stats available too. > > At the moment libvirt only return the cpu0_time. Can you please let me > know what other stats you would like here? Since we have numCpus, I'd suggest we allow for a list of cpus in the same way we do for disk/nics and returning the execution time split out for each vCPU. We could still have a merged execution time too since I can imagine some hypervisors won't be able to provide the split out per-vcpu time. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
