similar to: [Xen-API] Re: FW: XCP Memory static/dynamic and overcommit

Hi all, So I have been playing around with XCP and the static/dynamic memory parameters. I have a few behavioral questions I would like to pin down: -Is the static-max quantity of free memory on the host always required before the guest vm can be started? I assume so since you don''t know a-priori if the guest you are booting supports Xen or not. But if this is true, what is the use of

Hello, In our office we would like to do something like "memory overcommitment" or rather "dynamic allocation" for a bunch of windows domUs (server 2003 & 2008). We thought this should be a simple feature, however we did not find any fitting solution. We use Xen 4.2.1 with xl toolstack. The idea is to use ballooning to dynamically (and automatically) change physical

On Tue, Feb 4, 2020 at 11:17 AM David Hildenbrand <david at redhat.com> wrote: > On 04.02.20 19:52, Tyler Sanderson wrote: > > > > > > On Tue, Feb 4, 2020 at 12:29 AM David Hildenbrand <david at redhat.com > > <mailto:david at redhat.com>> wrote: > > > > On 03.02.20 21:32, Tyler Sanderson wrote: > > > There were apparently

On Tue, Feb 4, 2020 at 11:17 AM David Hildenbrand <david at redhat.com> wrote: > On 04.02.20 19:52, Tyler Sanderson wrote: > > > > > > On Tue, Feb 4, 2020 at 12:29 AM David Hildenbrand <david at redhat.com > > <mailto:david at redhat.com>> wrote: > > > > On 03.02.20 21:32, Tyler Sanderson wrote: > > > There were apparently

Team: It is time to start thinking about our 2nd XCP meeting for the Xen.org XCP team. The last meeting was held on May 25, 2010 at 14:00 UTC. Notes are at http://wiki.xensource.com/xenwiki/XCP_Monthly_Meetings. For the next meeting I hope to schedule a time that is better for our Asian participants so please contact me with a time that would be best if you live in Japan, Korea, Australia, etc.

Team: It is time to start thinking about our 2nd XCP meeting for the Xen.org XCP team. The last meeting was held on May 25, 2010 at 14:00 UTC. Notes are at http://wiki.xensource.com/xenwiki/XCP_Monthly_Meetings. For the next meeting I hope to schedule a time that is better for our Asian participants so please contact me with a time that would be best if you live in Japan, Korea, Australia, etc.

On 09/14/2019 02:36 AM, Tyler Sanderson wrote: > Hello, I'm curious about the intent of VIRTIO_BALLOON_F_FREE_PAGE_HINT > (commit > <https://github.com/torvalds/linux/commit/86a559787e6f5cf662c081363f64a20cad654195#diff-fd202acf694d9eba19c8c64da3e480c9>). > > > My understanding is that this mechanism works similarly to the > existing inflate/deflate queues. Pages

On 09/14/2019 02:36 AM, Tyler Sanderson wrote: > Hello, I'm curious about the intent of VIRTIO_BALLOON_F_FREE_PAGE_HINT > (commit > <https://github.com/torvalds/linux/commit/86a559787e6f5cf662c081363f64a20cad654195#diff-fd202acf694d9eba19c8c64da3e480c9>). > > > My understanding is that this mechanism works similarly to the > existing inflate/deflate queues. Pages

Xen Community: As you are aware, the Xen Cloud Platform has been available for download since last November and is becoming a very successful release for Xen.org. In fact, we are seeing substantial network traffic for this solution as we had 26 TB of data from XCP downloads in the past 4 weeks. Of course, this amount of traffic is forcing a re-examination of our co-location agreements as we are

Xen Community: As you are aware, the Xen Cloud Platform has been available for download since last November and is becoming a very successful release for Xen.org. In fact, we are seeing substantial network traffic for this solution as we had 26 TB of data from XCP downloads in the past 4 weeks. Of course, this amount of traffic is forcing a re-examination of our co-location agreements as we are

There were apparently good reasons for moving away from OOM notifier callback: https://lkml.org/lkml/2018/7/12/314 https://lkml.org/lkml/2018/8/2/322 In particular the OOM notifier is worse than the shrinker because: 1. It is last-resort, which means the system has already gone through heroics to prevent OOM. Those heroic reclaim efforts are expensive and impact application performance.

There were apparently good reasons for moving away from OOM notifier callback: https://lkml.org/lkml/2018/7/12/314 https://lkml.org/lkml/2018/8/2/322 In particular the OOM notifier is worse than the shrinker because: 1. It is last-resort, which means the system has already gone through heroics to prevent OOM. Those heroic reclaim efforts are expensive and impact application performance.

On Tue, Feb 4, 2020 at 12:29 AM David Hildenbrand <david at redhat.com> wrote: > On 03.02.20 21:32, Tyler Sanderson wrote: > > There were apparently good reasons for moving away from OOM notifier > > callback: > > https://lkml.org/lkml/2018/7/12/314 > > https://lkml.org/lkml/2018/8/2/322 > > > > In particular the OOM notifier is worse than the shrinker

On Tue, Feb 4, 2020 at 12:29 AM David Hildenbrand <david at redhat.com> wrote: > On 03.02.20 21:32, Tyler Sanderson wrote: > > There were apparently good reasons for moving away from OOM notifier > > callback: > > https://lkml.org/lkml/2018/7/12/314 > > https://lkml.org/lkml/2018/8/2/322 > > > > In particular the OOM notifier is worse than the shrinker

Package: xcp-xapi Version: 1.3.2-6 Severity: important Tags: upstream xe vm-memory-target-set does not write new target to /local/domain/ID/memory/target. Balloon in guest domain is expecting this value to be changed to do selfballooning. This breaks 'dynamic memory control' feature. Steps to reproduce: 1) Setup any PV virtual machine with static-memory-min < static-memory-max 2)

Changes since V3: - Do not do endian conversions as they will be done in the host - Report stats that reference a quantity of memory in bytes - Minor coding style updates Changes since V2: - Increase stat field size to 64 bits - Report all sizes in kb (not pages) - Drop anon_pages stat and fix endianness conversion Changes since V1: - Use a virtqueue instead of the device config space

Changes since V3: - Do not do endian conversions as they will be done in the host - Report stats that reference a quantity of memory in bytes - Minor coding style updates Changes since V2: - Increase stat field size to 64 bits - Report all sizes in kb (not pages) - Drop anon_pages stat and fix endianness conversion Changes since V1: - Use a virtqueue instead of the device config space

On Fri 27-07-18 17:24:55, Wei Wang wrote: > The OOM notifier is getting deprecated to use for the reasons mentioned > here by Michal Hocko: https://lkml.org/lkml/2018/7/12/314 > > This patch replaces the virtio-balloon oom notifier with a shrinker > to release balloon pages on memory pressure. It would be great to document the replacement. This is not a small change... > In

On Fri 27-07-18 17:24:55, Wei Wang wrote: > The OOM notifier is getting deprecated to use for the reasons mentioned > here by Michal Hocko: https://lkml.org/lkml/2018/7/12/314 > > This patch replaces the virtio-balloon oom notifier with a shrinker > to release balloon pages on memory pressure. It would be great to document the replacement. This is not a small change... > In

agl at linux.vnet.ibm.com wrote: > Here are the corresponding changes to the Linux virtio driver... > > virtio: Add memory statistics reporting to the balloon driver > > When using ballooning to manage overcommitted memory on a host, a system for > guests to communicate their memory usage to the host can provide information > that will minimize the impact