| 1 | <?xml version='1.0' encoding='UTF-8'?>
|
|---|
| 2 | <!DOCTYPE topic PUBLIC "-//OASIS//DTD DITA Topic//EN" "topic.dtd">
|
|---|
| 3 | <topic xml:lang="en-us" id="guestadd-pagefusion">
|
|---|
| 4 | <title>Page Fusion</title>
|
|---|
| 5 |
|
|---|
| 6 | <body>
|
|---|
| 7 | <p>
|
|---|
| 8 | Whereas memory ballooning simply reduces the amount of RAM that
|
|---|
| 9 | is available to a VM, Page Fusion works differently. It avoids
|
|---|
| 10 | memory duplication between several similar running VMs.
|
|---|
| 11 | </p>
|
|---|
| 12 | <p>
|
|---|
| 13 | In a server environment running several similar VMs on the same
|
|---|
| 14 | host, lots of memory pages are identical. For example, if the
|
|---|
| 15 | VMs are using identical operating systems. <ph conkeyref="vbox-conkeyref-phrases/product-name"/>'s Page
|
|---|
| 16 | Fusion technology can efficiently identify these identical
|
|---|
| 17 | memory pages and share them between multiple VMs.
|
|---|
| 18 | </p>
|
|---|
| 19 | <note>
|
|---|
| 20 | <p>
|
|---|
| 21 | <ph conkeyref="vbox-conkeyref-phrases/product-name"/> supports Page Fusion only on 64-bit hosts, and
|
|---|
| 22 | it is not supported on macOS hosts. Page Fusion currently
|
|---|
| 23 | works only with Windows 2000 and later guests.
|
|---|
| 24 | </p>
|
|---|
| 25 | </note>
|
|---|
| 26 | <p>
|
|---|
| 27 | The more similar the VMs on a given host are, the more
|
|---|
| 28 | efficiently Page Fusion can reduce the amount of host memory
|
|---|
| 29 | that is in use. It therefore works best if all VMs on a host run
|
|---|
| 30 | identical operating systems. Instead of having a complete copy
|
|---|
| 31 | of each operating system in each VM, Page Fusion identifies the
|
|---|
| 32 | identical memory pages in use by these operating systems and
|
|---|
| 33 | eliminates the duplicates, sharing host memory between several
|
|---|
| 34 | machines. This is called <i>deduplication</i>. If
|
|---|
| 35 | a VM tries to modify a page that has been shared with other VMs,
|
|---|
| 36 | a new page is allocated again for that VM with a copy of the
|
|---|
| 37 | shared page. This is called <i>copy on write</i>.
|
|---|
| 38 | All this is fully transparent to the virtual machine.
|
|---|
| 39 | </p>
|
|---|
| 40 | <p>
|
|---|
| 41 | You may be familiar with this kind of memory overcommitment from
|
|---|
| 42 | other hypervisor products, which call this feature
|
|---|
| 43 | <i>page sharing</i> or <i>same page
|
|---|
| 44 | merging</i>. However, Page Fusion differs significantly
|
|---|
| 45 | from those other solutions, whose approaches have several
|
|---|
| 46 | drawbacks:
|
|---|
| 47 | </p>
|
|---|
| 48 | <ul>
|
|---|
| 49 | <li>
|
|---|
| 50 | <p>
|
|---|
| 51 | Traditional hypervisors scan <i>all</i> guest
|
|---|
| 52 | memory and compute checksums, also called hashes, for every
|
|---|
| 53 | single memory page. Then, they look for pages with identical
|
|---|
| 54 | hashes and compare the entire content of those pages. If two
|
|---|
| 55 | pages produce the same hash, it is very likely that the
|
|---|
| 56 | pages are identical in content. This process can take rather
|
|---|
| 57 | long, especially if the system is not idling. As a result,
|
|---|
| 58 | the additional memory only becomes available after a
|
|---|
| 59 | significant amount of time, such as hours or sometimes days.
|
|---|
| 60 | Even worse, this kind of page sharing algorithm generally
|
|---|
| 61 | consumes significant CPU resources and increases the
|
|---|
| 62 | virtualization overhead by 10 to 20%.
|
|---|
| 63 | </p>
|
|---|
| 64 | <p>
|
|---|
| 65 | Page Fusion in <ph conkeyref="vbox-conkeyref-phrases/product-name"/> uses logic in the
|
|---|
| 66 | <ph conkeyref="vbox-conkeyref-phrases/product-name"/> Guest Additions to quickly identify memory
|
|---|
| 67 | cells that are most likely identical across VMs. It can
|
|---|
| 68 | therefore achieve most of the possible savings of page
|
|---|
| 69 | sharing almost immediately and with almost no overhead.
|
|---|
| 70 | </p>
|
|---|
| 71 | </li>
|
|---|
| 72 | <li>
|
|---|
| 73 | <p>
|
|---|
| 74 | Page Fusion is also much less likely to be confused by
|
|---|
| 75 | identical memory that it will eliminate, just to learn
|
|---|
| 76 | seconds later that the memory will now change and having to
|
|---|
| 77 | perform a highly expensive and often service-disrupting
|
|---|
| 78 | reallocation.
|
|---|
| 79 | </p>
|
|---|
| 80 | </li>
|
|---|
| 81 | </ul>
|
|---|
| 82 | <p>
|
|---|
| 83 | At this time, Page Fusion can only be controlled with
|
|---|
| 84 | <userinput>VBoxManage</userinput>, and only while a VM is shut down.
|
|---|
| 85 | To enable Page Fusion for a VM, use the following command:
|
|---|
| 86 | </p>
|
|---|
| 87 | <pre xml:space="preserve">VBoxManage modifyvm "VM name" --page-fusion on</pre>
|
|---|
| 88 | <p> You can observe Page Fusion operation using some metrics. <codeph>RAM/VMM/Shared</codeph> shows the total amount of fused pages, whereas the per-VM metric <codeph>Guest/RAM/Usage/Shared</codeph> will return the amount of fused memory for a given VM. See <xref href="../cli_topics/vboxmanage-metrics.dita"/> for information on how to query metrics.</p>
|
|---|
| 89 | <note>
|
|---|
| 90 | <p>
|
|---|
| 91 | Enabling Page Fusion might indirectly increase the chances for
|
|---|
| 92 | malicious guests to successfully attack other VMs running on
|
|---|
| 93 | the same host. See <xref href="pot-insecure.dita">Potentially Insecure Operations</xref>.
|
|---|
| 94 | </p>
|
|---|
| 95 | </note>
|
|---|
| 96 | </body>
|
|---|
| 97 |
|
|---|
| 98 | </topic>
|
|---|
