[openstack-dev] [nova] VM diagnostics - V3 proposal

Gary Kotton gkotton at vmware.com
Thu Dec 19 16:02:16 UTC 2013



On 12/19/13 5:50 PM, "Daniel P. Berrange" <berrange at redhat.com> 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.

>
>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?

> 
>
>
>> 
>>>https://urldefense.proofpoint.com/v1/url?u=http://berrange.com/&k=oIvRg1
>>>%2
>> 
>>>BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq
>>>8%
>> 
>>>3D%0A&m=k92Oxw4Ev6Raba%2FayHa0ExWlFkO%2BLbCNYQYrLDivTK8%3D%0A&s=dd903dfc
>>>a0
>> >b7b3ace5c560509caf1164f8f3f4dda62174e6374b07a85724183c      -o-
>> 
>>>https://urldefense.proofpoint.com/v1/url?u=http://www.flickr.com/photos/
>>>db
>> 
>>>errange/&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2B
>>>fD
>> 
>>>tysg45MkPhCZFxPEq8%3D%0A&m=k92Oxw4Ev6Raba%2FayHa0ExWlFkO%2BLbCNYQYrLDivT
>>>K8
>> 
>>>%3D%0A&s=3d3587124076d99d0ad02847a95a69c541cfe296f650027c99cf098aad764ab
>>>9
>
>BTW if you would be nice if you can get your email program not to
>mangle URLs in mails you're replying to. In this case it was just
>links in a signature so didn't matter, but in other messages it is
>mangled stuff in the body of the message :-( It makes it painful
>to read the context.
>
>Regards,
>Daniel
>-- 
>|: 
>https://urldefense.proofpoint.com/v1/url?u=http://berrange.com/&k=oIvRg1%2
>BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%
>3D%0A&m=vzUZT3t%2BPvKlvBTFueAjUjo8YUZvDEtRLmlzFb5ORuM%3D%0A&s=3b9f7af3a2bc
>4ffaf73f6cff69fd1e88b2af95ced9b60945bc1e2f97ebaf7da4      -o-
>https://urldefense.proofpoint.com/v1/url?u=http://www.flickr.com/photos/db
>errange/&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfD
>tysg45MkPhCZFxPEq8%3D%0A&m=vzUZT3t%2BPvKlvBTFueAjUjo8YUZvDEtRLmlzFb5ORuM%3
>D%0A&s=3fa5cf45352c4dcbedf56f5ba059edf46fec10637a329c808cdfca2f66d3a4ce :|
>|: 
>https://urldefense.proofpoint.com/v1/url?u=http://libvirt.org/&k=oIvRg1%2B
>dGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3
>D%0A&m=vzUZT3t%2BPvKlvBTFueAjUjo8YUZvDEtRLmlzFb5ORuM%3D%0A&s=4bf16f2a8e571
>3d2fb13f8dcb0ab13e78a5ec376b215f6c07476f4a75c1b829f              -o-
>       
>https://urldefense.proofpoint.com/v1/url?u=http://virt-manager.org/&k=oIvR
>g1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxP
>Eq8%3D%0A&m=vzUZT3t%2BPvKlvBTFueAjUjo8YUZvDEtRLmlzFb5ORuM%3D%0A&s=1d14716b
>524d2c056cb5b26f32b13df0a602ca98fb80380d7e1964491f43b44f :|
>|: 
>https://urldefense.proofpoint.com/v1/url?u=http://autobuild.org/&k=oIvRg1%
>2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8
>%3D%0A&m=vzUZT3t%2BPvKlvBTFueAjUjo8YUZvDEtRLmlzFb5ORuM%3D%0A&s=ddcbd034b66
>ac7c6ad71aa7d610c4286edd6b318b1571217479975d0f93ab2a2       -o-
>https://urldefense.proofpoint.com/v1/url?u=http://search.cpan.org/~danberr
>/&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45M
>kPhCZFxPEq8%3D%0A&m=vzUZT3t%2BPvKlvBTFueAjUjo8YUZvDEtRLmlzFb5ORuM%3D%0A&s=
>ee1de07a4232052114216c584542a5c6e1dd9bbe2998e84e170d5cdc7f7dbaf1 :|
>|: 
>https://urldefense.proofpoint.com/v1/url?u=http://entangle-photo.org/&k=oI
>vRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZF
>xPEq8%3D%0A&m=vzUZT3t%2BPvKlvBTFueAjUjo8YUZvDEtRLmlzFb5ORuM%3D%0A&s=f5bbef
>56d9b91e55d6ad4bc09cbda2365cbc21715ba40d922f24de2960daa3a1       -o-
> 
>https://urldefense.proofpoint.com/v1/url?u=http://live.gnome.org/gtk-vnc&k
>=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPh
>CZFxPEq8%3D%0A&m=vzUZT3t%2BPvKlvBTFueAjUjo8YUZvDEtRLmlzFb5ORuM%3D%0A&s=db9
>d0a174f481fbbb3dd4e04e9fc2666b89e1a08b0ed0ed3e2bbb2de0d4cea76 :|




More information about the OpenStack-dev mailing list