Re: [libvirt] [PATCH v3 04/13] XML parsing for memory tunables
* Nikunj A. Dadhania nik...@linux.vnet.ibm.com [2010-10-08 14:43:34]: On Fri, 8 Oct 2010 14:10:53 +0530, Balbir Singh bal...@linux.vnet.ibm.com wrote: * Nikunj A. Dadhania nik...@linux.vnet.ibm.com [2010-10-08 12:00:44]: On Thu, 7 Oct 2010 12:49:29 +0100, Daniel P. Berrange berra...@redhat.com wrote: On Mon, Oct 04, 2010 at 12:47:22PM +0530, Nikunj A. Dadhania wrote: On Mon, 4 Oct 2010 12:16:42 +0530, Balbir Singh bal...@linux.vnet.ibm.com wrote: * Nikunj A. Dadhania nik...@linux.vnet.ibm.com [2010-09-28 15:26:30]: snip +unsigned long hard_limit; +unsigned long soft_limit; +unsigned long min_guarantee; +unsigned long swap_hard_limit; The hard_limit, soft_limit, swap_hard_limit are s64 and the value is in bytes. What is the unit supported in this implementation? Actually if libvirt is built on 32bit these aren't big enough - make them into 'unsigned long long' data types I reckon. I was thinking that as we are having the unit of KB, we would be able to represent 2^42 bytes of memory limit, ie. 4 Terabytes. Won't this suffice in case of 32bit? How would you represent -1 (2^63 -1) as unlimited or max limit we use today? I think I have answered this question in the thread: this is specific to cgroup that -1 means unlimited, this may not be true for other HVs. OK, so how do we handle unlimited values in general? -- Three Cheers, Balbir -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v3 04/13] XML parsing for memory tunables
On Tue, 12 Oct 2010 19:19:21 +0530, Balbir Singh bal...@linux.vnet.ibm.com wrote: * Nikunj A. Dadhania nik...@linux.vnet.ibm.com [2010-10-08 14:43:34]: On Fri, 8 Oct 2010 14:10:53 +0530, Balbir Singh bal...@linux.vnet.ibm.com wrote: * Nikunj A. Dadhania nik...@linux.vnet.ibm.com [2010-10-08 12:00:44]: On Thu, 7 Oct 2010 12:49:29 +0100, Daniel P. Berrange berra...@redhat.com wrote: On Mon, Oct 04, 2010 at 12:47:22PM +0530, Nikunj A. Dadhania wrote: On Mon, 4 Oct 2010 12:16:42 +0530, Balbir Singh bal...@linux.vnet.ibm.com wrote: * Nikunj A. Dadhania nik...@linux.vnet.ibm.com [2010-09-28 15:26:30]: snip +unsigned long hard_limit; +unsigned long soft_limit; +unsigned long min_guarantee; +unsigned long swap_hard_limit; The hard_limit, soft_limit, swap_hard_limit are s64 and the value is in bytes. What is the unit supported in this implementation? Actually if libvirt is built on 32bit these aren't big enough - make them into 'unsigned long long' data types I reckon. I was thinking that as we are having the unit of KB, we would be able to represent 2^42 bytes of memory limit, ie. 4 Terabytes. Won't this suffice in case of 32bit? How would you represent -1 (2^63 -1) as unlimited or max limit we use today? I think I have answered this question in the thread: this is specific to cgroup that -1 means unlimited, this may not be true for other HVs. OK, so how do we handle unlimited values in general? At present, API does not have a way to do this. We have added a flag in the API, let me think of some way I could use it for such setting unlimited values. Regards Nikunj -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v3 04/13] XML parsing for memory tunables
On Thu, 7 Oct 2010 12:49:29 +0100, Daniel P. Berrange berra...@redhat.com wrote: On Mon, Oct 04, 2010 at 12:47:22PM +0530, Nikunj A. Dadhania wrote: On Mon, 4 Oct 2010 12:16:42 +0530, Balbir Singh bal...@linux.vnet.ibm.com wrote: * Nikunj A. Dadhania nik...@linux.vnet.ibm.com [2010-09-28 15:26:30]: snip +unsigned long hard_limit; +unsigned long soft_limit; +unsigned long min_guarantee; +unsigned long swap_hard_limit; The hard_limit, soft_limit, swap_hard_limit are s64 and the value is in bytes. What is the unit supported in this implementation? Actually if libvirt is built on 32bit these aren't big enough - make them into 'unsigned long long' data types I reckon. I was thinking that as we are having the unit of KB, we would be able to represent 2^42 bytes of memory limit, ie. 4 Terabytes. Won't this suffice in case of 32bit? Nikunj -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v3 04/13] XML parsing for memory tunables
* Nikunj A. Dadhania nik...@linux.vnet.ibm.com [2010-10-08 12:00:44]: On Thu, 7 Oct 2010 12:49:29 +0100, Daniel P. Berrange berra...@redhat.com wrote: On Mon, Oct 04, 2010 at 12:47:22PM +0530, Nikunj A. Dadhania wrote: On Mon, 4 Oct 2010 12:16:42 +0530, Balbir Singh bal...@linux.vnet.ibm.com wrote: * Nikunj A. Dadhania nik...@linux.vnet.ibm.com [2010-09-28 15:26:30]: snip +unsigned long hard_limit; +unsigned long soft_limit; +unsigned long min_guarantee; +unsigned long swap_hard_limit; The hard_limit, soft_limit, swap_hard_limit are s64 and the value is in bytes. What is the unit supported in this implementation? Actually if libvirt is built on 32bit these aren't big enough - make them into 'unsigned long long' data types I reckon. I was thinking that as we are having the unit of KB, we would be able to represent 2^42 bytes of memory limit, ie. 4 Terabytes. Won't this suffice in case of 32bit? How would you represent -1 (2^63 -1) as unlimited or max limit we use today? -- Three Cheers, Balbir -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v3 04/13] XML parsing for memory tunables
On Thu, 7 Oct 2010 12:48:26 +0100, Daniel P. Berrange berra...@redhat.com wrote: On Tue, Sep 28, 2010 at 03:26:30PM +0530, Nikunj A. Dadhania wrote: From: Nikunj A. Dadhania nik...@linux.vnet.ibm.com Adding parsing code for memory tunables in the domain xml file v2: + Fix typo min_guarantee Signed-off-by: Nikunj A. Dadhania nik...@linux.vnet.ibm.com --- src/conf/domain_conf.c | 50 +--- src/conf/domain_conf.h | 12 --- src/esx/esx_vmx.c | 30 +- src/lxc/lxc_controller.c |2 +- src/lxc/lxc_driver.c | 12 +-- src/openvz/openvz_driver.c |8 --- src/qemu/qemu_conf.c |8 --- src/qemu/qemu_driver.c | 18 src/test/test_driver.c | 12 +-- src/uml/uml_conf.c |2 +- src/uml/uml_driver.c | 14 ++-- 11 files changed, 104 insertions(+), 64 deletions(-) ACK, looks fine, though it'd be good to add one or two example data files to tests/qemuxml2xmltest.c to ensure that we roundtrip through the XML parser+formatter correctly. Sure, will add the files, and send the updated series Nikunj -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v3 04/13] XML parsing for memory tunables
On Fri, 8 Oct 2010 14:10:53 +0530, Balbir Singh bal...@linux.vnet.ibm.com wrote: * Nikunj A. Dadhania nik...@linux.vnet.ibm.com [2010-10-08 12:00:44]: On Thu, 7 Oct 2010 12:49:29 +0100, Daniel P. Berrange berra...@redhat.com wrote: On Mon, Oct 04, 2010 at 12:47:22PM +0530, Nikunj A. Dadhania wrote: On Mon, 4 Oct 2010 12:16:42 +0530, Balbir Singh bal...@linux.vnet.ibm.com wrote: * Nikunj A. Dadhania nik...@linux.vnet.ibm.com [2010-09-28 15:26:30]: snip +unsigned long hard_limit; +unsigned long soft_limit; +unsigned long min_guarantee; +unsigned long swap_hard_limit; The hard_limit, soft_limit, swap_hard_limit are s64 and the value is in bytes. What is the unit supported in this implementation? Actually if libvirt is built on 32bit these aren't big enough - make them into 'unsigned long long' data types I reckon. I was thinking that as we are having the unit of KB, we would be able to represent 2^42 bytes of memory limit, ie. 4 Terabytes. Won't this suffice in case of 32bit? How would you represent -1 (2^63 -1) as unlimited or max limit we use today? I think I have answered this question in the thread: this is specific to cgroup that -1 means unlimited, this may not be true for other HVs. Nikunj -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v3 04/13] XML parsing for memory tunables
On Tue, Sep 28, 2010 at 03:26:30PM +0530, Nikunj A. Dadhania wrote: From: Nikunj A. Dadhania nik...@linux.vnet.ibm.com Adding parsing code for memory tunables in the domain xml file v2: + Fix typo min_guarantee Signed-off-by: Nikunj A. Dadhania nik...@linux.vnet.ibm.com --- src/conf/domain_conf.c | 50 +--- src/conf/domain_conf.h | 12 --- src/esx/esx_vmx.c | 30 +- src/lxc/lxc_controller.c |2 +- src/lxc/lxc_driver.c | 12 +-- src/openvz/openvz_driver.c |8 --- src/qemu/qemu_conf.c |8 --- src/qemu/qemu_driver.c | 18 src/test/test_driver.c | 12 +-- src/uml/uml_conf.c |2 +- src/uml/uml_driver.c | 14 ++-- 11 files changed, 104 insertions(+), 64 deletions(-) ACK, looks fine, though it'd be good to add one or two example data files to tests/qemuxml2xmltest.c to ensure that we roundtrip through the XML parser+formatter correctly. Daniel -- |: Red Hat, Engineering, London-o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org-o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v3 04/13] XML parsing for memory tunables
On Mon, Oct 04, 2010 at 12:47:22PM +0530, Nikunj A. Dadhania wrote: On Mon, 4 Oct 2010 12:16:42 +0530, Balbir Singh bal...@linux.vnet.ibm.com wrote: * Nikunj A. Dadhania nik...@linux.vnet.ibm.com [2010-09-28 15:26:30]: snip +/* Extract other memory tunables */ +if (virXPathULong(string(./memtune/hard_limit), ctxt, + def-mem.hard_limit) 0) +def-mem.hard_limit = 0; + +if (virXPathULong(string(./memtune/soft_limit[1]), ctxt, + def-mem.soft_limit) 0) +def-mem.soft_limit = 0; + +if (virXPathULong(string(./memtune/min_guarantee[1]), ctxt, + def-mem.min_guarantee) 0) +def-mem.min_guarantee = 0; + +if (virXPathULong(string(./memtune/swap_hard_limit[1]), ctxt, + def-mem.swap_hard_limit) 0) +def-mem.swap_hard_limit = 0; + Quick question, does 0 represent invalid values? If configuration file does not provide any value, we set this to 0, we do not call the lower layer calls in this case. I'd presume you'd want to use something like -1. We support unsigned long long for the values to be set (64 bit signed), unlimited translates to 2^63 - 1, is ULong sufficient to represent that value? The unit here is KB, so we can have till 2^42 bytes. So to answer you question, no it does not represent 64 bit signed. I guess this should not be an issue to support if needed. I understand that in case of cgroup unlimited is (-1), but again that would be cgroup specific at this level. I need to think of some way to address this independent of the lower layer. +unsigned long hard_limit; +unsigned long soft_limit; +unsigned long min_guarantee; +unsigned long swap_hard_limit; The hard_limit, soft_limit, swap_hard_limit are s64 and the value is in bytes. What is the unit supported in this implementation? Actually if libvirt is built on 32bit these aren't big enough - make them into 'unsigned long long' data types I reckon. Daniel -- |: Red Hat, Engineering, London-o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org-o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v3 04/13] XML parsing for memory tunables
On Mon, 4 Oct 2010 12:16:42 +0530, Balbir Singh bal...@linux.vnet.ibm.com wrote: * Nikunj A. Dadhania nik...@linux.vnet.ibm.com [2010-09-28 15:26:30]: snip +/* Extract other memory tunables */ +if (virXPathULong(string(./memtune/hard_limit), ctxt, + def-mem.hard_limit) 0) +def-mem.hard_limit = 0; + +if (virXPathULong(string(./memtune/soft_limit[1]), ctxt, + def-mem.soft_limit) 0) +def-mem.soft_limit = 0; + +if (virXPathULong(string(./memtune/min_guarantee[1]), ctxt, + def-mem.min_guarantee) 0) +def-mem.min_guarantee = 0; + +if (virXPathULong(string(./memtune/swap_hard_limit[1]), ctxt, + def-mem.swap_hard_limit) 0) +def-mem.swap_hard_limit = 0; + Quick question, does 0 represent invalid values? If configuration file does not provide any value, we set this to 0, we do not call the lower layer calls in this case. I'd presume you'd want to use something like -1. We support unsigned long long for the values to be set (64 bit signed), unlimited translates to 2^63 - 1, is ULong sufficient to represent that value? The unit here is KB, so we can have till 2^42 bytes. So to answer you question, no it does not represent 64 bit signed. I guess this should not be an issue to support if needed. I understand that in case of cgroup unlimited is (-1), but again that would be cgroup specific at this level. I need to think of some way to address this independent of the lower layer. +unsigned long hard_limit; +unsigned long soft_limit; +unsigned long min_guarantee; +unsigned long swap_hard_limit; The hard_limit, soft_limit, swap_hard_limit are s64 and the value is in bytes. What is the unit supported in this implementation? KB Thanks for reviewing. Regard Nikunj -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v3 04/13] XML parsing for memory tunables
* Nikunj A. Dadhania nik...@linux.vnet.ibm.com [2010-09-28 15:26:30]:
From: Nikunj A. Dadhania nik...@linux.vnet.ibm.com
Adding parsing code for memory tunables in the domain xml file
v2:
+ Fix typo min_guarantee
Signed-off-by: Nikunj A. Dadhania nik...@linux.vnet.ibm.com
---
src/conf/domain_conf.c | 50
+---
src/conf/domain_conf.h | 12 ---
src/esx/esx_vmx.c | 30 +-
src/lxc/lxc_controller.c |2 +-
src/lxc/lxc_driver.c | 12 +--
src/openvz/openvz_driver.c |8 ---
src/qemu/qemu_conf.c |8 ---
src/qemu/qemu_driver.c | 18
src/test/test_driver.c | 12 +--
src/uml/uml_conf.c |2 +-
src/uml/uml_driver.c | 14 ++--
11 files changed, 104 insertions(+), 64 deletions(-)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index e05d5d7..0dd74e4 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -4231,19 +4231,38 @@ static virDomainDefPtr
virDomainDefParseXML(virCapsPtr caps,
def-description = virXPathString(string(./description[1]), ctxt);
/* Extract domain memory */
-if (virXPathULong(string(./memory[1]), ctxt, def-maxmem) 0) {
+if (virXPathULong(string(./memory[1]), ctxt,
+ def-mem.max_balloon) 0) {
virDomainReportError(VIR_ERR_INTERNAL_ERROR,
%s, _(missing memory element));
goto error;
}
-if (virXPathULong(string(./currentMemory[1]), ctxt, def-memory) 0)
-def-memory = def-maxmem;
+if (virXPathULong(string(./currentMemory[1]), ctxt,
+ def-mem.cur_balloon) 0)
+def-mem.cur_balloon = def-mem.max_balloon;
node = virXPathNode(./memoryBacking/hugepages, ctxt);
if (node)
-def-hugepage_backed = 1;
-
+def-mem.hugepage_backed = 1;
+
+/* Extract other memory tunables */
+if (virXPathULong(string(./memtune/hard_limit), ctxt,
+ def-mem.hard_limit) 0)
+def-mem.hard_limit = 0;
+
+if (virXPathULong(string(./memtune/soft_limit[1]), ctxt,
+ def-mem.soft_limit) 0)
+def-mem.soft_limit = 0;
+
+if (virXPathULong(string(./memtune/min_guarantee[1]), ctxt,
+ def-mem.min_guarantee) 0)
+def-mem.min_guarantee = 0;
+
+if (virXPathULong(string(./memtune/swap_hard_limit[1]), ctxt,
+ def-mem.swap_hard_limit) 0)
+def-mem.swap_hard_limit = 0;
+
Quick question, does 0 represent invalid values? I'd presume you'd
want to use something like -1. We support unsigned long long for the
values to be set (64 bit signed), unlimited translates to 2^63 - 1, is
ULong sufficient to represent that value?
if (virXPathULong(string(./vcpu[1]), ctxt, def-vcpus) 0)
def-vcpus = 1;
@@ -6382,10 +6401,25 @@ char *virDomainDefFormat(virDomainDefPtr def,
virBufferEscapeString(buf, description%s/description\n,
def-description);
-virBufferVSprintf(buf, memory%lu/memory\n, def-maxmem);
+virBufferVSprintf(buf, memory%lu/memory\n,
def-mem.max_balloon);
virBufferVSprintf(buf, currentMemory%lu/currentMemory\n,
- def-memory);
-if (def-hugepage_backed) {
+ def-mem.cur_balloon);
+virBufferVSprintf(buf, memtune\n);
+if (def-mem.hard_limit) {
+virBufferVSprintf(buf, hard_limit%lu/hard_limit\n,
+ def-mem.hard_limit);
+}
+if (def-mem.soft_limit) {
+virBufferVSprintf(buf, soft_limit%lu/soft_limit\n,
+ def-mem.soft_limit);
+}
+if (def-mem.swap_hard_limit) {
+virBufferVSprintf(buf,
swap_hard_limit%lu/swap_hard_limit\n,
+ def-mem.swap_hard_limit);
+}
+virBufferVSprintf(buf, /memtune\n);
+
+if (def-mem.hugepage_backed) {
virBufferAddLit(buf, memoryBacking\n);
virBufferAddLit(buf, hugepages/\n);
virBufferAddLit(buf, /memoryBacking\n);
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index 7195c04..2ecc2af 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -864,9 +864,15 @@ struct _virDomainDef {
char *name;
char *description;
-unsigned long memory;
-unsigned long maxmem;
-unsigned char hugepage_backed;
+struct {
+unsigned long max_balloon;
+unsigned long cur_balloon;
+unsigned long hugepage_backed;
+unsigned long hard_limit;
+unsigned long soft_limit;
+unsigned long min_guarantee;
+unsigned long swap_hard_limit;
The hard_limit, soft_limit, swap_hard_limit are s64 and the value is
in bytes. What is
[libvirt] [PATCH v3 04/13] XML parsing for memory tunables
From: Nikunj A. Dadhania nik...@linux.vnet.ibm.com
Adding parsing code for memory tunables in the domain xml file
v2:
+ Fix typo min_guarantee
Signed-off-by: Nikunj A. Dadhania nik...@linux.vnet.ibm.com
---
src/conf/domain_conf.c | 50 +---
src/conf/domain_conf.h | 12 ---
src/esx/esx_vmx.c | 30 +-
src/lxc/lxc_controller.c |2 +-
src/lxc/lxc_driver.c | 12 +--
src/openvz/openvz_driver.c |8 ---
src/qemu/qemu_conf.c |8 ---
src/qemu/qemu_driver.c | 18
src/test/test_driver.c | 12 +--
src/uml/uml_conf.c |2 +-
src/uml/uml_driver.c | 14 ++--
11 files changed, 104 insertions(+), 64 deletions(-)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index e05d5d7..0dd74e4 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -4231,19 +4231,38 @@ static virDomainDefPtr virDomainDefParseXML(virCapsPtr
caps,
def-description = virXPathString(string(./description[1]), ctxt);
/* Extract domain memory */
-if (virXPathULong(string(./memory[1]), ctxt, def-maxmem) 0) {
+if (virXPathULong(string(./memory[1]), ctxt,
+ def-mem.max_balloon) 0) {
virDomainReportError(VIR_ERR_INTERNAL_ERROR,
%s, _(missing memory element));
goto error;
}
-if (virXPathULong(string(./currentMemory[1]), ctxt, def-memory) 0)
-def-memory = def-maxmem;
+if (virXPathULong(string(./currentMemory[1]), ctxt,
+ def-mem.cur_balloon) 0)
+def-mem.cur_balloon = def-mem.max_balloon;
node = virXPathNode(./memoryBacking/hugepages, ctxt);
if (node)
-def-hugepage_backed = 1;
-
+def-mem.hugepage_backed = 1;
+
+/* Extract other memory tunables */
+if (virXPathULong(string(./memtune/hard_limit), ctxt,
+ def-mem.hard_limit) 0)
+def-mem.hard_limit = 0;
+
+if (virXPathULong(string(./memtune/soft_limit[1]), ctxt,
+ def-mem.soft_limit) 0)
+def-mem.soft_limit = 0;
+
+if (virXPathULong(string(./memtune/min_guarantee[1]), ctxt,
+ def-mem.min_guarantee) 0)
+def-mem.min_guarantee = 0;
+
+if (virXPathULong(string(./memtune/swap_hard_limit[1]), ctxt,
+ def-mem.swap_hard_limit) 0)
+def-mem.swap_hard_limit = 0;
+
if (virXPathULong(string(./vcpu[1]), ctxt, def-vcpus) 0)
def-vcpus = 1;
@@ -6382,10 +6401,25 @@ char *virDomainDefFormat(virDomainDefPtr def,
virBufferEscapeString(buf, description%s/description\n,
def-description);
-virBufferVSprintf(buf, memory%lu/memory\n, def-maxmem);
+virBufferVSprintf(buf, memory%lu/memory\n, def-mem.max_balloon);
virBufferVSprintf(buf, currentMemory%lu/currentMemory\n,
- def-memory);
-if (def-hugepage_backed) {
+ def-mem.cur_balloon);
+virBufferVSprintf(buf, memtune\n);
+if (def-mem.hard_limit) {
+virBufferVSprintf(buf, hard_limit%lu/hard_limit\n,
+ def-mem.hard_limit);
+}
+if (def-mem.soft_limit) {
+virBufferVSprintf(buf, soft_limit%lu/soft_limit\n,
+ def-mem.soft_limit);
+}
+if (def-mem.swap_hard_limit) {
+virBufferVSprintf(buf,
swap_hard_limit%lu/swap_hard_limit\n,
+ def-mem.swap_hard_limit);
+}
+virBufferVSprintf(buf, /memtune\n);
+
+if (def-mem.hugepage_backed) {
virBufferAddLit(buf, memoryBacking\n);
virBufferAddLit(buf, hugepages/\n);
virBufferAddLit(buf, /memoryBacking\n);
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index 7195c04..2ecc2af 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -864,9 +864,15 @@ struct _virDomainDef {
char *name;
char *description;
-unsigned long memory;
-unsigned long maxmem;
-unsigned char hugepage_backed;
+struct {
+unsigned long max_balloon;
+unsigned long cur_balloon;
+unsigned long hugepage_backed;
+unsigned long hard_limit;
+unsigned long soft_limit;
+unsigned long min_guarantee;
+unsigned long swap_hard_limit;
+} mem;
unsigned long vcpus;
int cpumasklen;
char *cpumask;
diff --git a/src/esx/esx_vmx.c b/src/esx/esx_vmx.c
index 59eb3b2..6f1eb17 100644
--- a/src/esx/esx_vmx.c
+++ b/src/esx/esx_vmx.c
@@ -48,8 +48,8 @@ domain-xml= vmx
def-id = value = ???
# not representable
def-uuid = value = uuid.bios = value
def-name = value = displayName = value
-def-maxmem = value kilobyte= memsize = value
