vdsm-devel September 2012

vdsm-devel@lists.stg.fedorahosted.org

30 participants
24 discussions

Re: [vdsm] Change in vdsm[master]: report cpuUser and cpuSys separately
by Ryan Harper 07 Sep '12

07 Sep '12

* Mark Wu <wudxw(a)linux.vnet.ibm.com> [2012-09-07 05:00]: > Mark Wu has posted comments on this change. > > Change subject: report cpuUser and cpuSys separately > ...................................................................... > > > Patch Set 1: > > Here's the cpustats of a running vm: > > virsh # cpu-stats 3 > CPU0: > cpu_time 152.626922854 seconds > CPU1: > cpu_time 460.343462849 seconds > CPU2: > cpu_time 37.569566994 seconds > CPU3: > cpu_time 21.092908393 seconds > Total: > cpu_time 671.632861090 seconds > user_time 3.440000000 seconds > system_time 18.380000000 seconds > > You can see cpu_time is much bigger than the sum of user_time and > system_time, because the guest time is not reported here. So most cpu > time is used to run guest code. It makes sense! For a qemu-kvm > process, user_time represents the time used by qemu, and system_time > represents the time used by kvm module, which doesn't contain guest > time. I am not sure if this is what you expect. It could be a little > bit confusing for user. I think it's useful to split the data out seperately for debugging purposes, not clear to me that the user is interested in the break down. Advanced performance tuning will definitely want to observe the data as well as users looking to debug issues. I don't see the harm in adding additional information. > > -- > To view, visit http://gerrit.ovirt.org/7718 > To unsubscribe, visit http://gerrit.ovirt.org/settings > > Gerrit-MessageType: comment > Gerrit-Change-Id: I663ad25ff3ff5ce426b5159b6c9a65b7f5167605 > Gerrit-PatchSet: 1 > Gerrit-Project: vdsm > Gerrit-Branch: master > Gerrit-Owner: Laszlo Hornyak <lhornyak(a)redhat.com> > Gerrit-Reviewer: Dan Kenigsberg <danken(a)redhat.com> > Gerrit-Reviewer: Gal Hammer <ghammer(a)redhat.com> > Gerrit-Reviewer: Laszlo Hornyak <lhornyak(a)redhat.com> > Gerrit-Reviewer: Mark Wu <wudxw(a)linux.vnet.ibm.com> > Gerrit-Reviewer: Royce Lv <lvroyce(a)linux.vnet.ibm.com> > Gerrit-Reviewer: oVirt Jenkins CI Server > _______________________________________________ > vdsm-patches mailing list > vdsm-patches(a)lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/vdsm-patches -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx ryanh(a)us.ibm.com

1 0

Sync mom and vdsm releases
by agl＠us.ibm.com 06 Sep '12

06 Sep '12

Hi Dan, et al: Since vdsm and MOM are now evolving together it seems appropriate that we coordinate their releases. Could you provide me with some information on how the vdsm releases are done? I will take care of releasing MOM (including Fedora packages, etc) but I just need to know when vdsm will release. Also, we need to keep the 'Requires:' up to date in the vdsm spec file. Thanks. -- Adam Litke <agl(a)us.ibm.com> IBM Linux Technology Center

2 1

Cancelled: ovirt network
by lpeer＠redhat.com 05 Sep '12

05 Sep '12

A single instance of the following meeting has been cancelled: Subject: ovirt network Organiser: "Livnat Peer" <lpeer(a)redhat.com> Time: Wednesday, 19 September, 2012, 4:00:00 PM - 5:00:00 PM GMT +02:00 Jerusalem Invitees: engine-devel(a)ovirt.org; vdsm-devel(a)lists.fedorahosted.org; GARGYA(a)de.ibm.com; dyasny(a)redhat.com; simon(a)redhat.com; mkolesni(a)redhat.com; atal(a)redhat.com; ilvovsky(a)redhat.com; dfediuck(a)redhat.com; pradipta.banerjee(a)gmail.com; gkotton(a)redhat.com ... *~*~*~*~*~*~*~*~*~* I'm on vacation Sep 19th, cancelling this meeting instance. If you want to have the meeting please send a new invite to the dev lists. Thanks, Livnat

1 0

[RFC] Implied UUIDs in API
by smizrahi＠redhat.com 03 Sep '12

03 Sep '12

Hi, in the API a lot of IDs get passed around are UUIDs. The point is that as long as you are not the entity generating the UUIDs the fact that these are UUIDs have no real significance to you. I suggest removing the validation of UUIDs from the receiving end. There is no real reason to make sure these are real UUIDs. It's another restriction we can remove from the interface simplifying the code and the interface. Just to be clear I'm not saying that we should stop using UUIDs. For example, vdsm will keep generating task IDs as UUIDs. But the documentation will state that it could be *any* string value. If for some reason we choose to change the format of task IDs. There will be no need to change the interface. The same goes for VM IDs. Currently the engine uses UUIDs but there is no reason for VDSM to enforce this and limit the engine from ever changing it in the future and using other string values.

8 13

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

vdsm-devel September 2012