Show Table of Contents
23.7. Memory Tuning
<domain>
...
<memtune>
<hard_limit unit='G'>1</hard_limit>
<soft_limit unit='M'>128</soft_limit>
<swap_hard_limit unit='G'>2</swap_hard_limit>
<min_guarantee unit='bytes'>67108864</min_guarantee>
</memtune>
...
</domain>
Figure 23.9. Memory tuning
Although
<memtune> is optional, the components of this section of the domain XML are as follows:
Table 23.5. Memory tuning elements
| Element | Description |
|---|---|
<memtune> | Provides details regarding the memory tunable parameters for the domain. If this is omitted, it defaults to the operating system provided defaults. As parameters are applied to the process as a whole, when setting limits, determine values by adding the guest virtual machine RAM to the guest virtual machine video RAM, allowing for some memory overhead. For each tunable, it is possible to designate which unit the number is in on input, using the same values as for <memory>. For backwards compatibility, output is always in kibibytes (KiB). |
<hard_limit> | The maximum memory the guest virtual machine can use. This value is expressed in kibibytes (blocks of 1024 bytes). |
<soft_limit> | The memory limit to enforce during memory contention. This value is expressed in kibibytes (blocks of 1024 bytes). |
<swap_hard_limit> | The maximum memory plus swap the guest virtual machine can use. This value is expressed in kibibytes (blocks of 1024 bytes). This must be more than <hard_limit> value. |
<min_guarantee> | The guaranteed minimum memory allocation for the guest virtual machine. This value is expressed in kibibytes (blocks of 1024 bytes). |

Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.