At 02/15/2012 05:07 PM, Jan Kiszka Wrote: > On 2012-02-15 04:47, Wen Congyang wrote: >> At 02/15/2012 02:27 AM, Jan Kiszka Wrote: >>> On 2012-02-14 19:05, Jan Kiszka wrote: >>>> On 2012-02-09 04:28, Wen Congyang wrote: >>>>> The new monitor command dump may take long time to finish. So we need run >>>>> it >>>>> at the background. >>>> >>>> How does it work? Like live migration, i.e. you retransmit (overwrite) >>>> already written but then dirtied pages? Hmm... no. >>>> >>>> What does background mean then? What is the use case? What if the user >>>> decides to resume the vm? >>> >>> OK, that is addressed in patch 15! I would suggest merging it into this >>> patch. It makes sense to handle that case gracefully right from the >>> beginning. >> >> OK, I will merge it. >> >>> >>> OK, now I have some other question: What is the point of rate-limiting >>> the dump? The guest is not running, thus not competing for bandwidth. >> >> I use bandwidth to try to control the writing speed. If we write the vmcore >> to disk in a high speed, it may affect some other appilications which use >> the same disk too. > > Just like the guest of that particular VM can do. I don't think we need > this level of control here, it will be provided (if required) at a > different level, affecting the whole QEMU process. Removing the vmcore > bandwidth control will simplify code and user interface.
OK. I will implementing it like this: 1. write 100ms 2. sleep 100ms(allow qemu to do the other things) 3. goto 1 Thanks Wen Congyang > > Jan >