similar to: Bug#630175: ballooning with windows xp?

# HG changeset patch # User Ian Campbell <ijc@hellion.org.uk> # Date 1354011148 0 # Node ID 3174dc24e3efb0c5b964c244dbfb0218a03a38cf # Parent 541b0e1a36c86db5df04988dd4ade5430776a7f2 xl: xl.conf(5): correct advice re autoballooning vs. dom0_mem. The advice was backwards, you should really disable autoballoon if you use dom0_mem. Also add a reference to the command-line docs.

This should have gone here and not to #706233. Patch will obviously need rebasing by now... ----- Forwarded message from Ian Campbell <ijc at hellion.org.uk> ----- Date: Fri, 16 Aug 2013 14:56:49 +0100 From: Ian Campbell <ijc at hellion.org.uk> To: 706233 at bugs.debian.org Cc: control at bugs.debian.org Subject: move core dumps to /var/lib/xen/dump X-Spam-Status: No, score=-4.9

Hi list, I try to understand memory ballooning. I have a xen server (kernel 2.6.27.54-0.2-xen) with 32 gb total memory. A domU has been started with "memory=4096" and "maxmem=8192". This is the status of the balloon driver in the domU: test:~ # cat /proc/xen/balloon Current allocation: 4194304 kB Requested target: 4194304 kB Minimum target: 565248 kB Maximum

Package: xen-hypervisor-4.0-amd64 Version: 4.0.1-2 Severity: normal -- System Information: Debian Release: 6.0.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-xen-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash

I have a xen server setup that I want to install a lot of vms on if possible. The vms will have no utilization for the most part; and brief utilization when active. The server has 2GB of RAM. We were running into a problem were the dom0 would not let us add anymore vms because we were out of physical memory. I have started to read about memory ballooning and hoping someone could point me

tags 706233 +patch thanks This is somewhat more FHS compliant IMHO. commit 7d171826bc97bf5f3f2019fc32c1ca85b49de7c9 Author: Ian Campbell <ijc at hellion.org.uk> Date: Fri Aug 16 14:54:42 2013 +0100 * debian/patches/tools-core-dump-dir.patch: Switch tools to dumping to /var/log/xen/dump by default. * debian/xen-utils-common.dirs: Ensure /var/lib/xen/dump is created *

The changeset ''12803:df5fa63490f4da7b65c56087a68783dbcb7944f8'' added a new hypercall XENMEM_set_memory_map for specifying the e820 mapping. There was a small bug in the userspace side of this change though - the e820 mapping was specified based on the ''memory_static_min'' domain info parameter which means the memory map size is clamped to the value

On Tue, Apr 21, 2020 at 8:18 AM David Hildenbrand <david at redhat.com> wrote: > > >> > >> That leaves us with either > >> > >> 1. "Pages hinted via VIRTIO_BALLOON_F_FREE_PAGE_HINT might get replaced > >> by zero page. However, as soon as the page is written by the guest (even > >> before the hinting request was processed by the

# HG changeset patch # User Olaf Hering <olaf@aepfle.de> # Date 1329300057 -3600 # Node ID 5a1cbd1af275e6ed1ef673852f8ac5247c09669c # Parent 5fb2aa61197db9676c11fbcf3ed24f30ac8fab9f man/xl.cfg: mention not yet documented options Add dummy entries for parsed but undocumented cfg file options to xl.cfg: for i in ` grep -Ew

>> >> That leaves us with either >> >> 1. "Pages hinted via VIRTIO_BALLOON_F_FREE_PAGE_HINT might get replaced >> by zero page. However, as soon as the page is written by the guest (even >> before the hinting request was processed by the host), the modified page >> will stay - whereby the unwritten parts might either be from the old, or >> from

On Tue, Apr 21, 2020 at 12:29 AM David Hildenbrand <david at redhat.com> wrote: > > >>> 2. Can we assume that the guest will always rewrite the page after the > >>> deflate in the case of init_on_free or poison? > >> > >> Depends on what we think is the right way to do - IOW if we think "some > >> other content" as mentioned

hi, there is something, what i don''t understand. I have in my DomU config: memory = "128" maxmem = "1024" tsles:~ # cat /proc/xen/balloon Current allocation: 237568 kB Requested target: 237568 kB Minimum target: 237568 kB Maximum target: 1048576 kB Low-mem balloon: 804352 kB High-mem balloon: 0 kB Driver pages: 1024 kB Xen

Package: xen-hypervisor-3.0-i386 Version: 3.0.2+hg9681-1 Severity: important Have been trying to get NetBSD to run under debian unstable with the debian supplied hypervisor. Using the 3.0.2-2 hypervisor supplied by XenSource, it works just fine. Because the install process overrides other things, reverified with debian hypervisor afterwards and symptom continues. Attaching the netbsd.cfg and the

----- Forwarded message from pakrat <pakrat@private.neotoma.org> ----- Forwarding to list without attachments. From: pakrat <pakrat@private.neotoma.org> To: Debian Bug Tracking System <submit@bugs.debian.org> Subject: xen-hypervisor-3.0-i386: cannot start NetBSD-HEAD X-Neotoma-Consulting-MailScanner: Found to be clean X-Neotoma-Consulting-MailScanner-From:

On Mon, Apr 20, 2020 at 6:28 AM David Hildenbrand <david at redhat.com> wrote: > > >>> Now we are talking about what's safe to do with the page. > >>> > >>> If POISON flag is set by hypervisor but clear by guest, > >>> or poison_val is 0, then it's clear it's safe to blow > >>> away the page if we can figure out

Previously we allowed arbitrary flags to be passed through to the underlying openstack CLI command, provided they have the format ‘--key=value’. We want to pass the ‘--insecure’ flag through, but that doesn't have the key=value form. However a small modification to the matching rules would allow this. The effect of this change is that you can now use ‘virt-v2v -oo insecure’ to turn off SSL

I am trying to allow domains'' memory allocation to be altered by using both the "memory" and "maxmem" options in my config files (i.e. set maxmem to some large value to allow the domain to be resized up to that amount, and memory to set the initial allocation). However I appear to lose potentially quite a large chunk of memory as I use a larger "maxmem"

On 23.05.2018 20:24, David Hildenbrand wrote: > This is the Linux driver side of virtio-mem. Compared to the QEMU side, > it is in a pretty complete and clean state. > > virtio-mem is a paravirtualized mechanism of adding/removing memory to/from > a VM. We can do this on a 4MB granularity right now. In Linux, all > memory is added to the ZONE_NORMAL, so unplugging cannot be

Processing commands for control at bugs.debian.org: > forcemerge 587090 588888 Bug #587090 {Done: Ian Campbell <ijc at hellion.org.uk>} [xen-utils-4.0] xen-utils-4.0: Exception starting xend ('NoneType' object has no attribute 'rfind') Unable to merge bugs because: package of #588888 is 'xen-utils-common' not 'xen-utils-4.0' Failed to forcibly merge

Hi I''m getting very high CPU usage on idle for an XP SP3 guest, which is doing nothing and is reporting 0% CPU within the guest. xentop - 14:36:29 Xen 3.2-1 10 domains: 1 running, 9 blocked, 0 paused, 0 crashed, 0 dying, 0 shutdown Mem: 4192752k total, 2654960k used, 1537792k free CPUs: 4 @ 3000MHz NAME STATE CPU(sec) CPU(%) MEM(k) MEM(%) MAXMEM(k) MAXMEM(%) VCPUS