similar to: Question about reduced memory by balloon driver (QEMU specific?)

Hi guys, I used setMemory in order to dynamically change guest's memory on QEMU-KVM. As expected, memory(total, free, available) in the guest was really changed, but after a few seconds, it automatically reverted to its initial memory. So, setMemory changes the guest's memory temporarily? Thanks.

On Thu, 3 Mar 2016 18:44:26 +0800 Liang Li <liang.z.li at intel.com> wrote: > Extend the virtio balloon device to support a new feature, this > new feature can help to get guest's free pages information, which > can be used for live migration optimzation. Do you have a spec for this, e.g. as a patch to the virtio spec? > > Signed-off-by: Liang Li <liang.z.li at

Extend the virtio balloon device to support a new feature, this new feature can help to get guest's free pages information, which can be used for live migration optimzation. Signed-off-by: Liang Li <liang.z.li at intel.com> --- balloon.c | 30 ++++++++- hw/virtio/virtio-balloon.c | 81 ++++++++++++++++++++++++-

On Thu, Mar 03, 2016 at 06:44:26PM +0800, Liang Li wrote: > Extend the virtio balloon device to support a new feature, this > new feature can help to get guest's free pages information, which > can be used for live migration optimzation. > > Signed-off-by: Liang Li <liang.z.li at intel.com> I don't understand why we need a new interface. Balloon already sends free

* Liang Li (liang.z.li at intel.com) wrote: > The current QEMU live migration implementation mark the all the > guest's RAM pages as dirtied in the ram bulk stage, all these pages > will be processed and that takes quit a lot of CPU cycles. > > From guest's point of view, it doesn't care about the content in free > pages. We can make use of this fact and skip

On Thu, Mar 03, 2016 at 06:44:24PM +0800, Liang Li wrote: > The current QEMU live migration implementation mark the all the > guest's RAM pages as dirtied in the ram bulk stage, all these pages > will be processed and that takes quit a lot of CPU cycles. > > From guest's point of view, it doesn't care about the content in free > pages. We can make use of this fact

Hi , I Sent this to the wrong list (libvirt-devel) on friday ... so i am trying to send it to the correct one this time. Apologize for double posting. I also created a ticket on bugzilla.redhat.com for this https://bugzilla.redhat.com/show_bug.cgi?id=927336 still i am posting it here because is absolutely possible i am doing something wrong and someone here will see it . Description of the

> > > > * Liang Li (liang.z.li at intel.com) wrote: > > > The current QEMU live migration implementation mark the all the > > > guest's RAM pages as dirtied in the ram bulk stage, all these pages > > > will be processed and that takes quit a lot of CPU cycles. > > > > > > From guest's point of view, it doesn't care about the

> > > > * Liang Li (liang.z.li at intel.com) wrote: > > > The current QEMU live migration implementation mark the all the > > > guest's RAM pages as dirtied in the ram bulk stage, all these pages > > > will be processed and that takes quit a lot of CPU cycles. > > > > > > From guest's point of view, it doesn't care about the

I was hoping that we could use QMP (now semi-stable since qemu 0.14) to hot plug disks. Unfortunately this is not yet possible. There is no drive_add QMP command which would be necessary for adding drives. We (Red Hat) hacked in a drive_add command into RHEL 6 (only for use by libvirt). This doesn't help us with upstream or Fedora. We could still use the human monitor, but obviously this

On 09/12/2017 10:29 PM, Tom?? Golembiovsk? wrote: > On Tue, 29 Aug 2017 20:01:53 +0800 > Wei Wang <wei.w.wang at intel.com> wrote: > >> On 08/29/2017 05:57 PM, Stefan Hajnoczi wrote: >>> On Sun, Aug 27, 2017 at 11:30:33PM +0200, Tom?? Golembiovsk? wrote: >>>> Hi, >>> I have CCed the relevant mailing lists and people most recently involved

The deflation request to the target, which isn't unaligned to the guest page size causes endless deflation and inflation actions. For example, we receive the flooding QMP events for the changes on memory balloon's size after a deflation request to the unaligned target is sent for the ARM64 guest, where we have 64KB base page size. /home/gavin/sandbox/qemu.main/build/qemu-system-aarch64

> Subject: Re: [RFC qemu 0/4] A PV solution for live migration optimization > > * Liang Li (liang.z.li at intel.com) wrote: > > The current QEMU live migration implementation mark the all the > > guest's RAM pages as dirtied in the ram bulk stage, all these pages > > will be processed and that takes quit a lot of CPU cycles. > > > > From guest's

> Subject: Re: [RFC qemu 0/4] A PV solution for live migration optimization > > * Liang Li (liang.z.li at intel.com) wrote: > > The current QEMU live migration implementation mark the all the > > guest's RAM pages as dirtied in the ram bulk stage, all these pages > > will be processed and that takes quit a lot of CPU cycles. > > > > From guest's

On 29.08.23 03:54, Gavin Shan wrote: > The deflation request to the target, which isn't unaligned to the > guest page size causes endless deflation and inflation actions. For > example, we receive the flooding QMP events for the changes on memory > balloon's size after a deflation request to the unaligned target is > sent for the ARM64 guest, where we have 64KB base page

The deflation request to the target, which isn't unaligned to the guest page size causes endless deflation and inflation actions. For example, we receive the flooding QMP events for the changes on memory balloon's size after a deflation request to the unaligned target is sent for the ARM64 guest, where we have 64KB base page size. /home/gavin/sandbox/qemu.main/build/qemu-system-aarch64

* Li, Liang Z (liang.z.li at intel.com) wrote: > > > > Hi, > > I'm just catching back up on this thread; so without reference to any > > particular previous mail in the thread. > > > > 1) How many of the free pages do we tell the host about? > > Your main change is telling the host about all the > > free pages. > > Yes, all

On Tue, 29 Aug 2017 20:01:53 +0800 Wei Wang <wei.w.wang at intel.com> wrote: > On 08/29/2017 05:57 PM, Stefan Hajnoczi wrote: > > On Sun, Aug 27, 2017 at 11:30:33PM +0200, Tom?? Golembiovsk? wrote: > >> Hi, > > I have CCed the relevant mailing lists and people most recently involved > > in virtio-balloon discussions. Hopefully this will help get the right

On Tue, 29 Aug 2017 20:01:53 +0800 Wei Wang <wei.w.wang at intel.com> wrote: > On 08/29/2017 05:57 PM, Stefan Hajnoczi wrote: > > On Sun, Aug 27, 2017 at 11:30:33PM +0200, Tom?? Golembiovsk? wrote: > >> Hi, > > I have CCed the relevant mailing lists and people most recently involved > > in virtio-balloon discussions. Hopefully this will help get the right

Am 21.12.2016 um 07:52 schrieb Liang Li: > This patch set contains two parts of changes to the virtio-balloon. > > One is the change for speeding up the inflating & deflating process, > the main idea of this optimization is to use {pfn|length} to present > the page information instead of the PFNs, to reduce the overhead of > virtio data transmission, address translation and