On 11/27/2012 07:01 PM, Wayne Sun wrote:
On 11/27/2012 04:36 PM, Guannan Ren wrote:
On 11/27/2012 03:02 PM, Wayne Sun wrote:
the xml dumped after setMemory is not accurate due to time
delay, so take 10 sec sleep before dump to show the right
xml info
Why it is necessary to sleep for a while, I don't think
adding a sleep
is a good way to solve problem.
Please try to figure out the root cause.
Guannan
DB recently change the code of get domain memory balloon value as in
patch:
http://www.redhat.com/archives/libvir-list/2012-May/msg00871.html
If QEMU supports the BALLOON_EVENT QMP event, then we can
avoid invoking 'query-balloon' when returning XML or the
domain info.
And in qemu patch:
http://lists.gnu.org/archive/html/qemu-devel/2012-05/msg02833.html
DB also emphasis in description:
It is important to note that events are only discarded when they are
obsoleted by a newer event. So an application is guarenteed to see the
final balloon event, with at worst a 1 second delay.
So when after do memory change, for dump domain xml to get balloon
value, it will be controlled in 1 second delay.
When i check with QMP with query-events commands on
qemu-kvm-rhev-0.12.1.2-2.337.el6.x86_64:
{ "execute": "query-events"}
{"error": {"class": "CommandNotFound", "desc": "The command
query-events has not been found", "data": {"name": "query-events"}}}
and this also in my log, so my qemu did not support this BALLOON_EVENT
and using query-balloon to get current memory, and indeed
'query-balloon' is spotted in my log.
This back to
# vim src/qemu/qemu_driver.c +5330
/* Don't delay if someone's using the monitor, just use
* existing most recent data instead */
so most recent data will be returned with query-balloon, that means if
we query too fast, the result will not be accurate.
I think add little time sleep is reasonable here for now, but after
qemu support BALLOON_EVENT, then the sleep will be no use.
So, what do you think?
Okay, I got what you meant here, 10 seconds is too long, I plan
to change it to 3 seconds as we discussed.
Thanks for your patch.
Guannan Ren
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list