src/libxl/libxl_conf.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
libxl requires the memory sizes to be rounded to 1MiB increments.
Attempting to start a domain that violates this requirement will
fail with the marginally helpful error
2018-02-22 01:55:32.921+0000: xc: panic: xc_dom_boot.c:141: xc_dom_boot_mem_init: can't allocate low memory for domain: Out of memory
2018-02-22 01:55:32.921+0000: libxl: libxl_dom.c:671:libxl__build_dom: xc_dom_boot_mem_init failed: No such file or directory
Round the maximum and current memory values to the next 1MiB
increment when generating the libxl_domain_config object.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
---
The memory values could also be adjusted in the post parse callback,
which might be better since the virDomainDef object would then reflect
the actual values given to libxl. In general, I often find myself
confused about the dividing line between adjusting such things in the
post parse callback vs domain creation.
src/libxl/libxl_conf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
index 57cb4c0ad..02bbf4e28 100644
--- a/src/libxl/libxl_conf.c
+++ b/src/libxl/libxl_conf.c
@@ -367,8 +367,8 @@ libxlMakeDomBuildInfo(virDomainDefPtr def,
}
b_info->sched_params.weight = 1000;
- b_info->max_memkb = virDomainDefGetMemoryInitial(def);
- b_info->target_memkb = def->mem.cur_balloon;
+ b_info->max_memkb = VIR_ROUND_UP(virDomainDefGetMemoryInitial(def), 1024);
+ b_info->target_memkb = VIR_ROUND_UP(def->mem.cur_balloon, 1024);
if (hvm) {
char bootorder[VIR_DOMAIN_BOOT_LAST + 1];
--
2.16.1
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Wed, Feb 21, 2018 at 19:08:41 -0700, Jim Fehlig wrote: > libxl requires the memory sizes to be rounded to 1MiB increments. > Attempting to start a domain that violates this requirement will > fail with the marginally helpful error > > 2018-02-22 01:55:32.921+0000: xc: panic: xc_dom_boot.c:141: xc_dom_boot_mem_init: can't allocate low memory for domain: Out of memory > 2018-02-22 01:55:32.921+0000: libxl: libxl_dom.c:671:libxl__build_dom: xc_dom_boot_mem_init failed: No such file or directory > > Round the maximum and current memory values to the next 1MiB > increment when generating the libxl_domain_config object. > > Signed-off-by: Jim Fehlig <jfehlig@suse.com> > --- > > The memory values could also be adjusted in the post parse callback, > which might be better since the virDomainDef object would then reflect > the actual values given to libxl. In general, I often find myself We do this in the qemu driver which has also rounding requirements and adjust the live domain XML after it's copied when starting. Thus the persistent definition is as provided by the user and the live XML reflects the actual state. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On 02/21/2018 11:53 PM, Peter Krempa wrote: > On Wed, Feb 21, 2018 at 19:08:41 -0700, Jim Fehlig wrote: >> libxl requires the memory sizes to be rounded to 1MiB increments. >> Attempting to start a domain that violates this requirement will >> fail with the marginally helpful error >> >> 2018-02-22 01:55:32.921+0000: xc: panic: xc_dom_boot.c:141: xc_dom_boot_mem_init: can't allocate low memory for domain: Out of memory >> 2018-02-22 01:55:32.921+0000: libxl: libxl_dom.c:671:libxl__build_dom: xc_dom_boot_mem_init failed: No such file or directory >> >> Round the maximum and current memory values to the next 1MiB >> increment when generating the libxl_domain_config object. >> >> Signed-off-by: Jim Fehlig <jfehlig@suse.com> >> --- >> >> The memory values could also be adjusted in the post parse callback, >> which might be better since the virDomainDef object would then reflect >> the actual values given to libxl. In general, I often find myself > > We do this in the qemu driver which has also rounding requirements and > adjust the live domain XML after it's copied when starting. Thus the > persistent definition is as provided by the user and the live XML > reflects the actual state. Thanks. I've sent a V2 that sets the rounded values in the virDomainDef object. With that change I do indeed see the rounded values in live XML and original values in 'dumpxml --inactive'. Regards, Jim -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
© 2016 - 2025 Red Hat, Inc.