Open Stack

On 12/19/13 6:07 PM, "Daniel P. Berrange" <berrange at redhat.com> wrote:

>On Thu, Dec 19, 2013 at 08:02:16AM -0800, Gary Kotton wrote:
>> 
>> 
>> 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/w
>>>>ik
>> 
>>>>i/Nova_VM_Diagnostics&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8N
>>>>PZ
>> 
>>>>yF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=vzUZT3t%2BPvKlvBTFueAjUjo8YUZv
>>>>DE
>> 
>>>>tRLmlzFb5ORuM%3D%0A&s=d13969885872ea187937a89d12aab9b36b51452ba47e35c7e
>>>>41
>> >>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.

Good call. I'll add this!

>
>Daniel
>-- 
>|: 
>https://urldefense.proofpoint.com/v1/url?u=http://berrange.com/&k=oIvRg1%2
>BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%
>3D%0A&m=np3rsZrtAfOFOfhCRXiCtSXdJPm3QIwaKWcO75QdIvo%3D%0A&s=43e28d32e5a671
>8ba104d118a69e659866e10cb5981b43bd8c89ac09d96bc6de      -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=np3rsZrtAfOFOfhCRXiCtSXdJPm3QIwaKWcO75QdIvo%3D%
>0A&s=69b56c12bb439e62c6aa90ec908016b701d268210a464d9d1f43f8c070e6e1db :|
>|: 
>https://urldefense.proofpoint.com/v1/url?u=http://libvirt.org/&k=oIvRg1%2B
>dGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3
>D%0A&m=np3rsZrtAfOFOfhCRXiCtSXdJPm3QIwaKWcO75QdIvo%3D%0A&s=d4d36b4c778f308
>9290ed06239bad90dbe8b52370f9c6c24b60a935510fb74d7              -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=np3rsZrtAfOFOfhCRXiCtSXdJPm3QIwaKWcO75QdIvo%3D%0A&s=edb1182136
>b3c880b14557de1856e0fbb4a950fceb89b39bb0cef7df081fa10c :|
>|: 
>https://urldefense.proofpoint.com/v1/url?u=http://autobuild.org/&k=oIvRg1%
>2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8
>%3D%0A&m=np3rsZrtAfOFOfhCRXiCtSXdJPm3QIwaKWcO75QdIvo%3D%0A&s=42e39e02e8829
>734ca2e30d74e1eeee0da2b0b3467c1cf019dc51c2edf1886f1       -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=np3rsZrtAfOFOfhCRXiCtSXdJPm3QIwaKWcO75QdIvo%3D%0A&s=ef
>96fb0514240a8fb1a14e4a75889bfc885abd1c4513c2a247cc3ea9d8c6a5d8 :|
>|: 
>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=np3rsZrtAfOFOfhCRXiCtSXdJPm3QIwaKWcO75QdIvo%3D%0A&s=e3b5989e
>44bc56357ec2ad6d0e5362628f44091fd2f7db207e6328512bd92b9a       -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=np3rsZrtAfOFOfhCRXiCtSXdJPm3QIwaKWcO75QdIvo%3D%0A&s=d33ad
>8192121a93a6f313b74f77c8b7add4967d4430f88a0fd11cbe80ee1e5f3 :|