| 1 | <?xml version="1.0" encoding="UTF-8"?>
|
|---|
| 2 | <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
|---|
| 3 | "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"[
|
|---|
| 4 | <!ENTITY % all.entities SYSTEM "all-entities.ent">
|
|---|
| 5 | %all.entities;
|
|---|
| 6 | ]>
|
|---|
| 7 | <chapter id="TechnicalBackground">
|
|---|
| 8 |
|
|---|
| 9 | <title>Technical Background</title>
|
|---|
| 10 |
|
|---|
| 11 | <para>
|
|---|
| 12 | This chapter provides additional information for readers who are
|
|---|
| 13 | familiar with computer architecture and technology and wish to find
|
|---|
| 14 | out more about how &product-name; works <emphasis>under the
|
|---|
| 15 | hood</emphasis>. The contents of this chapter are not required
|
|---|
| 16 | reading in order to use &product-name; successfully.
|
|---|
| 17 | </para>
|
|---|
| 18 |
|
|---|
| 19 | <sect1 id="vboxconfigdata">
|
|---|
| 20 |
|
|---|
| 21 | <title>Where &product-name; Stores its Files</title>
|
|---|
| 22 |
|
|---|
| 23 | <para>
|
|---|
| 24 | In &product-name;, a virtual machine and its settings are
|
|---|
| 25 | described in a virtual machine settings file in XML format. In
|
|---|
| 26 | addition, most virtual machine have one or more virtual hard
|
|---|
| 27 | disks, which are typically represented by disk images, such as
|
|---|
| 28 | those in VDI format. Where all these files are stored depends on
|
|---|
| 29 | which version of &product-name; created the machine.
|
|---|
| 30 | </para>
|
|---|
| 31 |
|
|---|
| 32 | <sect2 id="vboxconfigdata-post-version-four">
|
|---|
| 33 |
|
|---|
| 34 | <title>Machines Created by &product-name; Version 4.0 or Later</title>
|
|---|
| 35 |
|
|---|
| 36 | <para>
|
|---|
| 37 | By default, each virtual machine has one directory on your host
|
|---|
| 38 | computer where all the files of that machine are stored: the XML
|
|---|
| 39 | settings file, with a <computeroutput>.vbox</computeroutput>
|
|---|
| 40 | file extension, and its disk images.
|
|---|
| 41 | </para>
|
|---|
| 42 |
|
|---|
| 43 | <para>
|
|---|
| 44 | By default, this <emphasis>machine folder</emphasis> is placed
|
|---|
| 45 | in a common folder called <computeroutput>VirtualBox
|
|---|
| 46 | VMs</computeroutput>, which &product-name; creates in the
|
|---|
| 47 | current system user's home directory. The location of this home
|
|---|
| 48 | directory depends on the conventions of the host operating
|
|---|
| 49 | system, as follows:
|
|---|
| 50 | </para>
|
|---|
| 51 |
|
|---|
| 52 | <itemizedlist>
|
|---|
| 53 |
|
|---|
| 54 | <listitem>
|
|---|
| 55 | <para>
|
|---|
| 56 | On Windows, this is the location returned by the
|
|---|
| 57 | <computeroutput>SHGetFolderPath</computeroutput> function of
|
|---|
| 58 | the Windows system library Shell32.dll, asking for the user
|
|---|
| 59 | profile. On very old Windows versions which do not have this
|
|---|
| 60 | function or where it unexpectedly returns an error, there is
|
|---|
| 61 | a fallback based on environment variables. First,
|
|---|
| 62 | <computeroutput>%USERPROFILE%</computeroutput> is checked.
|
|---|
| 63 | If it does not exist then an attempt with
|
|---|
| 64 | <computeroutput>%HOMEDRIVE%%HOMEPATH%</computeroutput> is
|
|---|
| 65 | made. A typical location is
|
|---|
| 66 | <computeroutput>C:\Users\username</computeroutput>.
|
|---|
| 67 | </para>
|
|---|
| 68 | </listitem>
|
|---|
| 69 |
|
|---|
| 70 | <listitem>
|
|---|
| 71 | <para>
|
|---|
| 72 | On Linux, Mac OS X, and Oracle Solaris, this is generally
|
|---|
| 73 | taken from the environment variable
|
|---|
| 74 | <computeroutput>$HOME</computeroutput>, except for the user
|
|---|
| 75 | <computeroutput>root</computeroutput> where it is taken from
|
|---|
| 76 | the account database. This is a workaround for the frequent
|
|---|
| 77 | trouble caused by users using &product-name; in combination
|
|---|
| 78 | with the tool <computeroutput>sudo</computeroutput> which by
|
|---|
| 79 | default does not reset the environment variable
|
|---|
| 80 | <computeroutput>$HOME</computeroutput>. A typical location
|
|---|
| 81 | on Linux and Oracle Solaris is
|
|---|
| 82 | <computeroutput>/home/username</computeroutput> and on Mac
|
|---|
| 83 | OS X <computeroutput>/Users/username</computeroutput>.
|
|---|
| 84 | </para>
|
|---|
| 85 | </listitem>
|
|---|
| 86 |
|
|---|
| 87 | </itemizedlist>
|
|---|
| 88 |
|
|---|
| 89 | <para>
|
|---|
| 90 | For simplicity, we will abbreviate the location of the home
|
|---|
| 91 | directory as <computeroutput>$HOME</computeroutput>. Using that
|
|---|
| 92 | convention, the common folder for all virtual machines is
|
|---|
| 93 | <computeroutput>$HOME/VirtualBox VMs</computeroutput>.
|
|---|
| 94 | </para>
|
|---|
| 95 |
|
|---|
| 96 | <para>
|
|---|
| 97 | As an example, when you create a virtual machine called "Example
|
|---|
| 98 | VM", &product-name; creates the following:
|
|---|
| 99 | </para>
|
|---|
| 100 |
|
|---|
| 101 | <itemizedlist>
|
|---|
| 102 |
|
|---|
| 103 | <listitem>
|
|---|
| 104 | <para>
|
|---|
| 105 | A machine folder <computeroutput>$HOME/VirtualBox
|
|---|
| 106 | VMs/Example VM/</computeroutput>
|
|---|
| 107 | </para>
|
|---|
| 108 | </listitem>
|
|---|
| 109 |
|
|---|
| 110 | <listitem>
|
|---|
| 111 | <para>
|
|---|
| 112 | In the machine folder, a settings file:
|
|---|
| 113 | <computeroutput>Example VM.vbox</computeroutput>
|
|---|
| 114 | </para>
|
|---|
| 115 | </listitem>
|
|---|
| 116 |
|
|---|
| 117 | <listitem>
|
|---|
| 118 | <para>
|
|---|
| 119 | In the machine folder, a virtual disk image:
|
|---|
| 120 | <computeroutput>Example VM.vdi</computeroutput>.
|
|---|
| 121 | </para>
|
|---|
| 122 | </listitem>
|
|---|
| 123 |
|
|---|
| 124 | </itemizedlist>
|
|---|
| 125 |
|
|---|
| 126 | <para>
|
|---|
| 127 | This is the default layout if you use the
|
|---|
| 128 | <emphasis role="bold">Create New Virtual Machine</emphasis>
|
|---|
| 129 | wizard described in <xref linkend="gui-createvm" />. Once you
|
|---|
| 130 | start working with the VM, additional files are added. Log files
|
|---|
| 131 | are in a subfolder called <computeroutput>Logs</computeroutput>,
|
|---|
| 132 | and if you have taken snapshots, they are in a
|
|---|
| 133 | <computeroutput>Snapshots</computeroutput> subfolder. For each
|
|---|
| 134 | VM, you can change the location of its snapshots folder in the
|
|---|
| 135 | VM settings.
|
|---|
| 136 | </para>
|
|---|
| 137 |
|
|---|
| 138 | <para>
|
|---|
| 139 | You can change the default machine folder by selecting
|
|---|
| 140 | <emphasis role="bold">Preferences</emphasis> from the
|
|---|
| 141 | <emphasis role="bold">File</emphasis> menu in the &product-name;
|
|---|
| 142 | main window. Then, in the displayed window, click on the
|
|---|
| 143 | <emphasis role="bold">General</emphasis> tab. Alternatively, use
|
|---|
| 144 | <command>VBoxManage setproperty machinefolder</command>. See
|
|---|
| 145 | <xref linkend="vboxmanage-setproperty" />.
|
|---|
| 146 | </para>
|
|---|
| 147 |
|
|---|
| 148 | </sect2>
|
|---|
| 149 |
|
|---|
| 150 | <sect2 id="vboxconfigdata-pre-version-four">
|
|---|
| 151 |
|
|---|
| 152 | <title>Machines Created by &product-name; Versions Before 4.0</title>
|
|---|
| 153 |
|
|---|
| 154 | <para>
|
|---|
| 155 | If you have upgraded to &product-name; 4.0 from an earlier
|
|---|
| 156 | version of &product-name;, you probably have settings files and
|
|---|
| 157 | disks in the earlier file system layout.
|
|---|
| 158 | </para>
|
|---|
| 159 |
|
|---|
| 160 | <para>
|
|---|
| 161 | Before version 4.0, &product-name; separated the machine
|
|---|
| 162 | settings files from virtual disk images. The machine settings
|
|---|
| 163 | files had an <computeroutput>.xml</computeroutput> file
|
|---|
| 164 | extension and resided in a folder called
|
|---|
| 165 | <computeroutput>Machines</computeroutput> under the global
|
|---|
| 166 | &product-name; configuration directory. See
|
|---|
| 167 | <xref linkend="vboxconfigdata-global"/>. On Linux, for example,
|
|---|
| 168 | this was the hidden directory
|
|---|
| 169 | <computeroutput>$HOME/.VirtualBox/Machines</computeroutput>. The
|
|---|
| 170 | default hard disks folder was called
|
|---|
| 171 | <computeroutput>HardDisks</computeroutput> and was also located
|
|---|
| 172 | in the <computeroutput>.VirtualBox</computeroutput> folder. Both
|
|---|
| 173 | locations could be changed by the user in the global
|
|---|
| 174 | preferences. The concept of a default hard disk folder was
|
|---|
| 175 | abandoned with &product-name; 4.0, since disk images now reside
|
|---|
| 176 | in each machine's folder by default.
|
|---|
| 177 | </para>
|
|---|
| 178 |
|
|---|
| 179 | <para>
|
|---|
| 180 | The old layout had the following severe disadvantages:
|
|---|
| 181 | </para>
|
|---|
| 182 |
|
|---|
| 183 | <itemizedlist>
|
|---|
| 184 |
|
|---|
| 185 | <listitem>
|
|---|
| 186 | <para>
|
|---|
| 187 | It was very difficult to move a virtual machine from one
|
|---|
| 188 | host to another because the files involved did not reside in
|
|---|
| 189 | the same folder. In addition, the virtual media of all
|
|---|
| 190 | machines were registered with a global registry in the
|
|---|
| 191 | central &product-name; settings file,
|
|---|
| 192 | <computeroutput>$HOME/.VirtualBox/VirtualBox.xml</computeroutput>.
|
|---|
| 193 | </para>
|
|---|
| 194 |
|
|---|
| 195 | <para>
|
|---|
| 196 | To move a machine to another host, it was therefore not
|
|---|
| 197 | enough to move the XML settings file and the disk images,
|
|---|
| 198 | which were in different locations, but the hard disk entries
|
|---|
| 199 | from the global media registry XML had to be meticulously
|
|---|
| 200 | copied as well. This was close to impossible if the machine
|
|---|
| 201 | had snapshots and therefore differencing images.
|
|---|
| 202 | </para>
|
|---|
| 203 | </listitem>
|
|---|
| 204 |
|
|---|
| 205 | <listitem>
|
|---|
| 206 | <para>
|
|---|
| 207 | Storing virtual disk images, which can grow very large,
|
|---|
| 208 | under the hidden
|
|---|
| 209 | <computeroutput>.VirtualBox</computeroutput> directory, at
|
|---|
| 210 | least on Linux and Oracle Solaris hosts, made many users
|
|---|
| 211 | wonder where their disk space had gone.
|
|---|
| 212 | </para>
|
|---|
| 213 | </listitem>
|
|---|
| 214 |
|
|---|
| 215 | </itemizedlist>
|
|---|
| 216 |
|
|---|
| 217 | <para>
|
|---|
| 218 | Whereas new VMs created with &product-name; 4.0 or later will
|
|---|
| 219 | conform to the new layout, for maximum compatibility, old VMs
|
|---|
| 220 | are <emphasis>not</emphasis> converted to the new layout.
|
|---|
| 221 | Otherwise machine settings would be irrevocably broken if a user
|
|---|
| 222 | downgraded from 4.0 back to an older version of &product-name;.
|
|---|
| 223 | </para>
|
|---|
| 224 |
|
|---|
| 225 | </sect2>
|
|---|
| 226 |
|
|---|
| 227 | <sect2 id="vboxconfigdata-global">
|
|---|
| 228 |
|
|---|
| 229 | <title>Global Configuration Data</title>
|
|---|
| 230 |
|
|---|
| 231 | <para>
|
|---|
| 232 | In addition to the files of the virtual machines, &product-name;
|
|---|
| 233 | maintains global configuration data in the following directory:
|
|---|
| 234 | </para>
|
|---|
| 235 |
|
|---|
| 236 | <itemizedlist>
|
|---|
| 237 |
|
|---|
| 238 | <listitem>
|
|---|
| 239 | <para>
|
|---|
| 240 | <emphasis role="bold">Linux and Oracle Solaris:</emphasis>
|
|---|
| 241 | <computeroutput>$HOME/.config/VirtualBox</computeroutput>.
|
|---|
| 242 | </para>
|
|---|
| 243 |
|
|---|
| 244 | <para>
|
|---|
| 245 | <computeroutput>$HOME/.VirtualBox</computeroutput> is used
|
|---|
| 246 | if it exists, for compatibility with legacy versions before
|
|---|
| 247 | &product-name; 4.3.
|
|---|
| 248 | </para>
|
|---|
| 249 | </listitem>
|
|---|
| 250 |
|
|---|
| 251 | <listitem>
|
|---|
| 252 | <para>
|
|---|
| 253 | <emphasis role="bold">Windows:</emphasis>
|
|---|
| 254 | <computeroutput>$HOME/.VirtualBox</computeroutput>.
|
|---|
| 255 | </para>
|
|---|
| 256 | </listitem>
|
|---|
| 257 |
|
|---|
| 258 | <listitem>
|
|---|
| 259 | <para>
|
|---|
| 260 | <emphasis role="bold">Mac OS X:</emphasis>
|
|---|
| 261 | <computeroutput>$HOME/Library/VirtualBox</computeroutput>.
|
|---|
| 262 | </para>
|
|---|
| 263 | </listitem>
|
|---|
| 264 |
|
|---|
| 265 | </itemizedlist>
|
|---|
| 266 |
|
|---|
| 267 | <para>
|
|---|
| 268 | &product-name; creates this configuration directory
|
|---|
| 269 | automatically, if necessary. Optionally, you can specify an
|
|---|
| 270 | alternate configuration directory by setting the
|
|---|
| 271 | <computeroutput>VBOX_USER_HOME</computeroutput> environment
|
|---|
| 272 | variable, or additionally on Linux or Oracle Solaris by using
|
|---|
| 273 | the standard <computeroutput>XDG_CONFIG_HOME</computeroutput>
|
|---|
| 274 | variable. Since the global
|
|---|
| 275 | <computeroutput>VirtualBox.xml</computeroutput> settings file
|
|---|
| 276 | points to all other configuration files, this enables switching
|
|---|
| 277 | between several &product-name; configurations.
|
|---|
| 278 | </para>
|
|---|
| 279 |
|
|---|
| 280 | <para>
|
|---|
| 281 | Most importantly, in this directory, &product-name; stores its
|
|---|
| 282 | global settings file, another XML file called
|
|---|
| 283 | <computeroutput>VirtualBox.xml</computeroutput>. This includes
|
|---|
| 284 | global configuration options and the list of registered virtual
|
|---|
| 285 | machines with pointers to their XML settings files. Neither the
|
|---|
| 286 | location of this file nor its directory has changed with
|
|---|
| 287 | &product-name; 4.0.
|
|---|
| 288 | </para>
|
|---|
| 289 |
|
|---|
| 290 | <para>
|
|---|
| 291 | Before &product-name; 4.0, all virtual media, such as disk image
|
|---|
| 292 | files, were also contained in a global registry in this settings
|
|---|
| 293 | file. For compatibility, this media registry still exists if you
|
|---|
| 294 | upgrade &product-name; and there are media from machines which
|
|---|
| 295 | were created with a version before 4.0. If you have no such
|
|---|
| 296 | machines, then there will be no global media registry. With
|
|---|
| 297 | &product-name; 4.0, each machine XML file has its own media
|
|---|
| 298 | registry.
|
|---|
| 299 | </para>
|
|---|
| 300 |
|
|---|
| 301 | <para>
|
|---|
| 302 | Also before &product-name; 4.0, the default
|
|---|
| 303 | <computeroutput>Machines</computeroutput> folder and the default
|
|---|
| 304 | <computeroutput>HardDisks</computeroutput> folder resided under
|
|---|
| 305 | the &product-name; configuration directory, such as
|
|---|
| 306 | <computeroutput>$HOME/.VirtualBox/Machines</computeroutput> on
|
|---|
| 307 | Linux. If you are upgrading from an &product-name; version
|
|---|
| 308 | before 4.0, files in these directories are not automatically
|
|---|
| 309 | moved in order not to break backwards compatibility.
|
|---|
| 310 | </para>
|
|---|
| 311 |
|
|---|
| 312 | </sect2>
|
|---|
| 313 |
|
|---|
| 314 | <sect2 id="vboxconfigdata-summary-version-four">
|
|---|
| 315 |
|
|---|
| 316 | <title>Summary of 4.0 Configuration Changes</title>
|
|---|
| 317 |
|
|---|
| 318 | <para>
|
|---|
| 319 | <xref linkend="table-version4-config-changes"/> gives a brief
|
|---|
| 320 | overview of the configuration changes between legacy versions
|
|---|
| 321 | and version 4.0 or later.
|
|---|
| 322 | </para>
|
|---|
| 323 |
|
|---|
| 324 | <table id="table-version4-config-changes">
|
|---|
| 325 | <title>Configuration Changes in Version 4.0 or Above</title>
|
|---|
| 326 | <tgroup cols="3">
|
|---|
| 327 | <thead>
|
|---|
| 328 | <row>
|
|---|
| 329 | <entry><para>
|
|---|
| 330 | <emphasis role="bold">Setting</emphasis>
|
|---|
| 331 | </para></entry>
|
|---|
| 332 | <entry><para>
|
|---|
| 333 | <emphasis role="bold">Before 4.0</emphasis>
|
|---|
| 334 | </para></entry>
|
|---|
| 335 | <entry><para>
|
|---|
| 336 | <emphasis role="bold">4.0 or above</emphasis>
|
|---|
| 337 | </para></entry>
|
|---|
| 338 | </row>
|
|---|
| 339 | </thead>
|
|---|
| 340 | <tbody>
|
|---|
| 341 | <row>
|
|---|
| 342 | <entry><para>
|
|---|
| 343 | Default machines folder
|
|---|
| 344 | </para></entry>
|
|---|
| 345 | <entry><para>
|
|---|
| 346 | <computeroutput>$HOME/.VirtualBox/Machines</computeroutput>
|
|---|
| 347 | </para></entry>
|
|---|
| 348 | <entry><para>
|
|---|
| 349 | <computeroutput>$HOME/VirtualBox VMs</computeroutput>
|
|---|
| 350 | </para></entry>
|
|---|
| 351 | </row>
|
|---|
| 352 | <row>
|
|---|
| 353 | <entry><para>
|
|---|
| 354 | Default disk image location
|
|---|
| 355 | </para></entry>
|
|---|
| 356 | <entry><para>
|
|---|
| 357 | <computeroutput>$HOME/.VirtualBox/HardDisks</computeroutput>
|
|---|
| 358 | </para></entry>
|
|---|
| 359 | <entry><para>
|
|---|
| 360 | In each machine's folder
|
|---|
| 361 | </para></entry>
|
|---|
| 362 | </row>
|
|---|
| 363 | <row>
|
|---|
| 364 | <entry><para>
|
|---|
| 365 | Machine settings file extension
|
|---|
| 366 | </para></entry>
|
|---|
| 367 | <entry><para>
|
|---|
| 368 | <computeroutput>.xml</computeroutput>
|
|---|
| 369 | </para></entry>
|
|---|
| 370 | <entry><para>
|
|---|
| 371 | <computeroutput>.vbox</computeroutput>
|
|---|
| 372 | </para></entry>
|
|---|
| 373 | </row>
|
|---|
| 374 | <row>
|
|---|
| 375 | <entry><para>
|
|---|
| 376 | Media registry
|
|---|
| 377 | </para></entry>
|
|---|
| 378 | <entry><para>
|
|---|
| 379 | Global <computeroutput>VirtualBox.xml</computeroutput>
|
|---|
| 380 | file
|
|---|
| 381 | </para></entry>
|
|---|
| 382 | <entry><para>
|
|---|
| 383 | Each machine settings file
|
|---|
| 384 | </para></entry>
|
|---|
| 385 | </row>
|
|---|
| 386 | <row>
|
|---|
| 387 | <entry><para>
|
|---|
| 388 | Media registration
|
|---|
| 389 | </para></entry>
|
|---|
| 390 | <entry><para>
|
|---|
| 391 | Explicit open/close required
|
|---|
| 392 | </para></entry>
|
|---|
| 393 | <entry><para>
|
|---|
| 394 | Automatic on attach
|
|---|
| 395 | </para></entry>
|
|---|
| 396 | </row>
|
|---|
| 397 | </tbody>
|
|---|
| 398 | </tgroup>
|
|---|
| 399 | </table>
|
|---|
| 400 |
|
|---|
| 401 | </sect2>
|
|---|
| 402 |
|
|---|
| 403 | <sect2 id="vboxconfigdata-XML-files">
|
|---|
| 404 |
|
|---|
| 405 | <title>&product-name; XML Files</title>
|
|---|
| 406 |
|
|---|
| 407 | <para>
|
|---|
| 408 | &product-name; uses XML for both the machine settings files and
|
|---|
| 409 | the global configuration file,
|
|---|
| 410 | <computeroutput>VirtualBox.xml</computeroutput>.
|
|---|
| 411 | </para>
|
|---|
| 412 |
|
|---|
| 413 | <para>
|
|---|
| 414 | All &product-name; XML files are versioned. When a new settings
|
|---|
| 415 | file is created, for example because a new virtual machine is
|
|---|
| 416 | created, &product-name; automatically uses the settings format
|
|---|
| 417 | of the current &product-name; version. These files may not be
|
|---|
| 418 | readable if you downgrade to an earlier version of
|
|---|
| 419 | &product-name;. However, when &product-name; encounters a
|
|---|
| 420 | settings file from an earlier version, such as after upgrading
|
|---|
| 421 | &product-name;, it attempts to preserve the settings format as
|
|---|
| 422 | much as possible. It will only silently upgrade the settings
|
|---|
| 423 | format if the current settings cannot be expressed in the old
|
|---|
| 424 | format, for example because you enabled a feature that was not
|
|---|
| 425 | present in an earlier version of &product-name;.
|
|---|
| 426 | </para>
|
|---|
| 427 |
|
|---|
| 428 | <para>
|
|---|
| 429 | As an example, before &product-name; 3.1, it was only possible
|
|---|
| 430 | to enable or disable a single DVD drive in a virtual machine. If
|
|---|
| 431 | it was enabled, then it would always be visible as the secondary
|
|---|
| 432 | master of the IDE controller. With &product-name; 3.1, DVD
|
|---|
| 433 | drives can be attached to arbitrary slots of arbitrary
|
|---|
| 434 | controllers, so they could be the secondary slave of an IDE
|
|---|
| 435 | controller or in a SATA slot. If you have a machine settings
|
|---|
| 436 | file from an earlier version and upgrade &product-name; to 3.1
|
|---|
| 437 | and then move the DVD drive from its default position, this
|
|---|
| 438 | cannot be expressed in the old settings format; the XML machine
|
|---|
| 439 | file would get written in the new format, and a backup file of
|
|---|
| 440 | the old format would be kept.
|
|---|
| 441 | </para>
|
|---|
| 442 |
|
|---|
| 443 | <para>
|
|---|
| 444 | In such cases, &product-name; backs up the old settings file in
|
|---|
| 445 | the virtual machine's configuration directory. If you need to go
|
|---|
| 446 | back to the earlier version of &product-name;, then you will
|
|---|
| 447 | need to manually copy these backup files back.
|
|---|
| 448 | </para>
|
|---|
| 449 |
|
|---|
| 450 | <para>
|
|---|
| 451 | We intentionally do not document the specifications of the
|
|---|
| 452 | &product-name; XML files, as we must reserve the right to modify
|
|---|
| 453 | them in the future. We therefore strongly suggest that you do
|
|---|
| 454 | not edit these files manually. &product-name; provides complete
|
|---|
| 455 | access to its configuration data through its the
|
|---|
| 456 | <command>VBoxManage</command> command line tool, see
|
|---|
| 457 | <xref linkend="vboxmanage" /> and its API, see
|
|---|
| 458 | <xref linkend="VirtualBoxAPI" />.
|
|---|
| 459 | </para>
|
|---|
| 460 |
|
|---|
| 461 | </sect2>
|
|---|
| 462 |
|
|---|
| 463 | </sect1>
|
|---|
| 464 |
|
|---|
| 465 | <sect1 id="technical-components">
|
|---|
| 466 |
|
|---|
| 467 | <title>&product-name; Executables and Components</title>
|
|---|
| 468 |
|
|---|
| 469 | <para>
|
|---|
| 470 | &product-name; was designed to be modular and flexible. When the
|
|---|
| 471 | &product-name; graphical user interface (GUI) is opened and a VM
|
|---|
| 472 | is started, at least the following three processes are running:
|
|---|
| 473 | </para>
|
|---|
| 474 |
|
|---|
| 475 | <itemizedlist>
|
|---|
| 476 |
|
|---|
| 477 | <listitem>
|
|---|
| 478 | <para>
|
|---|
| 479 | <computeroutput>VBoxSVC</computeroutput>, the &product-name;
|
|---|
| 480 | service process which always runs in the background. This
|
|---|
| 481 | process is started automatically by the first &product-name;
|
|---|
| 482 | client process and exits a short time after the last client
|
|---|
| 483 | exits. The first &product-name; service can be the GUI,
|
|---|
| 484 | <computeroutput>VBoxManage</computeroutput>,
|
|---|
| 485 | <computeroutput>VBoxHeadless</computeroutput>, the web service
|
|---|
| 486 | amongst others. The service is responsible for bookkeeping,
|
|---|
| 487 | maintaining the state of all VMs, and for providing
|
|---|
| 488 | communication between &product-name; components. This
|
|---|
| 489 | communication is implemented using COM/XPCOM.
|
|---|
| 490 | </para>
|
|---|
| 491 |
|
|---|
| 492 | <note>
|
|---|
| 493 | <para>
|
|---|
| 494 | When we refer to <emphasis>clients</emphasis> here, we mean
|
|---|
| 495 | the local clients of a particular
|
|---|
| 496 | <computeroutput>VBoxSVC</computeroutput> server process, not
|
|---|
| 497 | clients in a network. &product-name; employs its own
|
|---|
| 498 | client/server design to allow its processes to cooperate,
|
|---|
| 499 | but all these processes run under the same user account on
|
|---|
| 500 | the host operating system, and this is totally transparent
|
|---|
| 501 | to the user.
|
|---|
| 502 | </para>
|
|---|
| 503 | </note>
|
|---|
| 504 | </listitem>
|
|---|
| 505 |
|
|---|
| 506 | <listitem>
|
|---|
| 507 | <para>
|
|---|
| 508 | The GUI process,
|
|---|
| 509 | <computeroutput>VirtualBoxVM</computeroutput>, a client
|
|---|
| 510 | application based on the cross-platform Qt library. When
|
|---|
| 511 | started without the <computeroutput>--startvm</computeroutput>
|
|---|
| 512 | option, this application acts as the &product-name; manager,
|
|---|
| 513 | displaying the VMs and their settings. It then communicates
|
|---|
| 514 | settings and state changes to
|
|---|
| 515 | <computeroutput>VBoxSVC</computeroutput> and also reflects
|
|---|
| 516 | changes effected through other means, such as the
|
|---|
| 517 | <command>VBoxManage</command> command.
|
|---|
| 518 | </para>
|
|---|
| 519 | </listitem>
|
|---|
| 520 |
|
|---|
| 521 | <listitem>
|
|---|
| 522 | <para>
|
|---|
| 523 | If the <computeroutput>VirtualBoxVM</computeroutput> client
|
|---|
| 524 | application is started with the
|
|---|
| 525 | <computeroutput>--startvm</computeroutput> argument, it loads
|
|---|
| 526 | the VMM library which includes the actual hypervisor and then
|
|---|
| 527 | runs a virtual machine and provides the input and output for
|
|---|
| 528 | the guest.
|
|---|
| 529 | </para>
|
|---|
| 530 | </listitem>
|
|---|
| 531 |
|
|---|
| 532 | </itemizedlist>
|
|---|
| 533 |
|
|---|
| 534 | <para>
|
|---|
| 535 | Any &product-name; front-end, or client, will communicate with the
|
|---|
| 536 | service process and can both control and reflect the current
|
|---|
| 537 | state. For example, either the VM selector or the VM window or
|
|---|
| 538 | VBoxManage can be used to pause the running VM, and other
|
|---|
| 539 | components will always reflect the changed state.
|
|---|
| 540 | </para>
|
|---|
| 541 |
|
|---|
| 542 | <para>
|
|---|
| 543 | The &product-name; GUI application is only one of several
|
|---|
| 544 | available front ends, or clients. The complete list shipped with
|
|---|
| 545 | &product-name; is as follows:
|
|---|
| 546 | </para>
|
|---|
| 547 |
|
|---|
| 548 | <itemizedlist>
|
|---|
| 549 |
|
|---|
| 550 | <listitem>
|
|---|
| 551 | <para>
|
|---|
| 552 | <computeroutput>VirtualBoxVM</computeroutput>: The Qt front
|
|---|
| 553 | end implementing the manager and running VMs.
|
|---|
| 554 | </para>
|
|---|
| 555 | </listitem>
|
|---|
| 556 |
|
|---|
| 557 | <listitem>
|
|---|
| 558 | <para>
|
|---|
| 559 | <computeroutput>VBoxManage</computeroutput>: A less
|
|---|
| 560 | user-friendly but more powerful alternative. See
|
|---|
| 561 | <xref linkend="vboxmanage" />.
|
|---|
| 562 | </para>
|
|---|
| 563 | </listitem>
|
|---|
| 564 |
|
|---|
| 565 | <listitem>
|
|---|
| 566 | <para>
|
|---|
| 567 | <computeroutput>VBoxHeadless</computeroutput>: A VM front end
|
|---|
| 568 | which does not directly provide any video output and keyboard
|
|---|
| 569 | or mouse input, but enables redirection through the VirtualBox
|
|---|
| 570 | Remote Desktop Extension. See <xref linkend="vboxheadless" />.
|
|---|
| 571 | </para>
|
|---|
| 572 | </listitem>
|
|---|
| 573 |
|
|---|
| 574 | <listitem>
|
|---|
| 575 | <para>
|
|---|
| 576 | <computeroutput>vboxwebsrv</computeroutput>: The
|
|---|
| 577 | &product-name; web service process which enables control of an
|
|---|
| 578 | &product-name; host remotely. This is described in detail in
|
|---|
| 579 | the &product-name; Software Development Kit (SDK) reference.
|
|---|
| 580 | See <xref linkend="VirtualBoxAPI" />.
|
|---|
| 581 | </para>
|
|---|
| 582 | </listitem>
|
|---|
| 583 |
|
|---|
| 584 | <listitem>
|
|---|
| 585 | <para>
|
|---|
| 586 | The &product-name; Python shell: A Python alternative to
|
|---|
| 587 | <computeroutput>VBoxManage</computeroutput>. This is also
|
|---|
| 588 | described in the SDK reference.
|
|---|
| 589 | </para>
|
|---|
| 590 | </listitem>
|
|---|
| 591 |
|
|---|
| 592 | </itemizedlist>
|
|---|
| 593 |
|
|---|
| 594 | <para>
|
|---|
| 595 | Internally, &product-name; consists of many more or less separate
|
|---|
| 596 | components. You may encounter these when analyzing &product-name;
|
|---|
| 597 | internal error messages or log files. These include the following:
|
|---|
| 598 | </para>
|
|---|
| 599 |
|
|---|
| 600 | <itemizedlist>
|
|---|
| 601 |
|
|---|
| 602 | <listitem>
|
|---|
| 603 | <para>
|
|---|
| 604 | IPRT: A portable runtime library which abstracts file access,
|
|---|
| 605 | threading, and string manipulation. Whenever &product-name;
|
|---|
| 606 | accesses host operating features, it does so through this
|
|---|
| 607 | library for cross-platform portability.
|
|---|
| 608 | </para>
|
|---|
| 609 | </listitem>
|
|---|
| 610 |
|
|---|
| 611 | <listitem>
|
|---|
| 612 | <para>
|
|---|
| 613 | VMM (Virtual Machine Monitor): The heart of the hypervisor.
|
|---|
| 614 | </para>
|
|---|
| 615 | </listitem>
|
|---|
| 616 |
|
|---|
| 617 | <listitem>
|
|---|
| 618 | <para>
|
|---|
| 619 | EM (Execution Manager): Controls execution of guest code.
|
|---|
| 620 | </para>
|
|---|
| 621 | </listitem>
|
|---|
| 622 |
|
|---|
| 623 | <listitem>
|
|---|
| 624 | <para>
|
|---|
| 625 | REM (Recompiled Execution Monitor): Provides software
|
|---|
| 626 | emulation of CPU instructions.
|
|---|
| 627 | </para>
|
|---|
| 628 | </listitem>
|
|---|
| 629 |
|
|---|
| 630 | <listitem>
|
|---|
| 631 | <para>
|
|---|
| 632 | TRPM (Trap Manager): Intercepts and processes guest traps and
|
|---|
| 633 | exceptions.
|
|---|
| 634 | </para>
|
|---|
| 635 | </listitem>
|
|---|
| 636 |
|
|---|
| 637 | <listitem>
|
|---|
| 638 | <para>
|
|---|
| 639 | HM (Hardware Acceleration Manager): Provides support for VT-x
|
|---|
| 640 | and AMD-V.
|
|---|
| 641 | </para>
|
|---|
| 642 | </listitem>
|
|---|
| 643 |
|
|---|
| 644 | <listitem>
|
|---|
| 645 | <para>
|
|---|
| 646 | GIM (Guest Interface Manager): Provides support for various
|
|---|
| 647 | paravirtualization interfaces to the guest.
|
|---|
| 648 | </para>
|
|---|
| 649 | </listitem>
|
|---|
| 650 |
|
|---|
| 651 | <listitem>
|
|---|
| 652 | <para>
|
|---|
| 653 | PDM (Pluggable Device Manager): An abstract interface between
|
|---|
| 654 | the VMM and emulated devices which separates device
|
|---|
| 655 | implementations from VMM internals and makes it easy to add
|
|---|
| 656 | new emulated devices. Through PDM, third-party developers can
|
|---|
| 657 | add new virtual devices to &product-name; without having to
|
|---|
| 658 | change &product-name; itself.
|
|---|
| 659 | </para>
|
|---|
| 660 | </listitem>
|
|---|
| 661 |
|
|---|
| 662 | <listitem>
|
|---|
| 663 | <para>
|
|---|
| 664 | PGM (Page Manager): A component that controls guest paging.
|
|---|
| 665 | </para>
|
|---|
| 666 | </listitem>
|
|---|
| 667 |
|
|---|
| 668 | <listitem>
|
|---|
| 669 | <para>
|
|---|
| 670 | PATM (Patch Manager): Patches guest code to improve and speed
|
|---|
| 671 | up software virtualization.
|
|---|
| 672 | </para>
|
|---|
| 673 | </listitem>
|
|---|
| 674 |
|
|---|
| 675 | <listitem>
|
|---|
| 676 | <para>
|
|---|
| 677 | TM (Time Manager): Handles timers and all aspects of time
|
|---|
| 678 | inside guests.
|
|---|
| 679 | </para>
|
|---|
| 680 | </listitem>
|
|---|
| 681 |
|
|---|
| 682 | <listitem>
|
|---|
| 683 | <para>
|
|---|
| 684 | CFGM (Configuration Manager): Provides a tree structure which
|
|---|
| 685 | holds configuration settings for the VM and all emulated
|
|---|
| 686 | devices.
|
|---|
| 687 | </para>
|
|---|
| 688 | </listitem>
|
|---|
| 689 |
|
|---|
| 690 | <listitem>
|
|---|
| 691 | <para>
|
|---|
| 692 | SSM (Saved State Manager): Saves and loads VM state.
|
|---|
| 693 | </para>
|
|---|
| 694 | </listitem>
|
|---|
| 695 |
|
|---|
| 696 | <listitem>
|
|---|
| 697 | <para>
|
|---|
| 698 | VUSB (Virtual USB): A USB layer which separates emulated USB
|
|---|
| 699 | controllers from the controllers on the host and from USB
|
|---|
| 700 | devices. This component also enables remote USB.
|
|---|
| 701 | </para>
|
|---|
| 702 | </listitem>
|
|---|
| 703 |
|
|---|
| 704 | <listitem>
|
|---|
| 705 | <para>
|
|---|
| 706 | DBGF (Debug Facility): A built-in VM debugger.
|
|---|
| 707 | </para>
|
|---|
| 708 | </listitem>
|
|---|
| 709 |
|
|---|
| 710 | <listitem>
|
|---|
| 711 | <para>
|
|---|
| 712 | &product-name; emulates a number of devices to provide the
|
|---|
| 713 | hardware environment that various guests need. Most of these
|
|---|
| 714 | are standard devices found in many PC compatible machines and
|
|---|
| 715 | widely supported by guest operating systems. For network and
|
|---|
| 716 | storage devices in particular, there are several options for
|
|---|
| 717 | the emulated devices to access the underlying hardware. These
|
|---|
| 718 | devices are managed by PDM.
|
|---|
| 719 | </para>
|
|---|
| 720 | </listitem>
|
|---|
| 721 |
|
|---|
| 722 | <listitem>
|
|---|
| 723 | <para>
|
|---|
| 724 | Guest Additions for various guest operating systems. This is
|
|---|
| 725 | code that is installed from within a virtual machine. See
|
|---|
| 726 | <xref linkend="guestadditions" />.
|
|---|
| 727 | </para>
|
|---|
| 728 | </listitem>
|
|---|
| 729 |
|
|---|
| 730 | <listitem>
|
|---|
| 731 | <para>
|
|---|
| 732 | The "Main" component is special. It ties all the above bits
|
|---|
| 733 | together and is the only public API that &product-name;
|
|---|
| 734 | provides. All the client processes listed above use only this
|
|---|
| 735 | API and never access the hypervisor components directly. As a
|
|---|
| 736 | result, third-party applications that use the &product-name;
|
|---|
| 737 | Main API can rely on the fact that it is always well-tested
|
|---|
| 738 | and that all capabilities of &product-name; are fully exposed.
|
|---|
| 739 | It is this API that is described in the &product-name; SDK.
|
|---|
| 740 | See <xref linkend="VirtualBoxAPI" />.
|
|---|
| 741 | </para>
|
|---|
| 742 | </listitem>
|
|---|
| 743 |
|
|---|
| 744 | </itemizedlist>
|
|---|
| 745 |
|
|---|
| 746 | </sect1>
|
|---|
| 747 |
|
|---|
| 748 | <sect1 id="hwvirt">
|
|---|
| 749 |
|
|---|
| 750 | <title>Hardware vs. Software Virtualization</title>
|
|---|
| 751 |
|
|---|
| 752 | <para>
|
|---|
| 753 | &product-name; enables software in the virtual machine to run
|
|---|
| 754 | directly on the processor of the host, but an array of complex
|
|---|
| 755 | techniques is employed to intercept operations that would
|
|---|
| 756 | interfere with your host. Whenever the guest attempts to do
|
|---|
| 757 | something that could be harmful to your computer and its data,
|
|---|
| 758 | &product-name; steps in and takes action. In particular, for lots
|
|---|
| 759 | of hardware that the guest believes to be accessing,
|
|---|
| 760 | &product-name; simulates a certain "virtual" environment according
|
|---|
| 761 | to how you have configured a virtual machine. For example, when
|
|---|
| 762 | the guest attempts to access a hard disk, &product-name; redirects
|
|---|
| 763 | these requests to whatever you have configured to be the virtual
|
|---|
| 764 | machine's virtual hard disk. This is normally an image file on
|
|---|
| 765 | your host.
|
|---|
| 766 | </para>
|
|---|
| 767 |
|
|---|
| 768 | <para>
|
|---|
| 769 | Unfortunately, the x86 platform was never designed to be
|
|---|
| 770 | virtualized. Detecting situations in which &product-name; needs to
|
|---|
| 771 | take control over the guest code that is executing, as described
|
|---|
| 772 | above, is difficult. There are two ways in which to achieve this:
|
|---|
| 773 | </para>
|
|---|
| 774 |
|
|---|
| 775 | <itemizedlist>
|
|---|
| 776 |
|
|---|
| 777 | <listitem>
|
|---|
| 778 | <para>
|
|---|
| 779 | Since 2006, Intel and AMD processors have had support for
|
|---|
| 780 | so-called <emphasis>hardware virtualization</emphasis>. This
|
|---|
| 781 | means that these processors can help &product-name; to
|
|---|
| 782 | intercept potentially dangerous operations that a guest
|
|---|
| 783 | operating system may be attempting and also makes it easier to
|
|---|
| 784 | present virtual hardware to a virtual machine.
|
|---|
| 785 | </para>
|
|---|
| 786 |
|
|---|
| 787 | <para>
|
|---|
| 788 | These hardware features differ between Intel and AMD
|
|---|
| 789 | processors. Intel named its technology >VT-x. AMD calls theirs
|
|---|
| 790 | AMD-V. The Intel and AMD support for virtualization is very
|
|---|
| 791 | different in detail, but not very different in principle.
|
|---|
| 792 | </para>
|
|---|
| 793 |
|
|---|
| 794 | <note>
|
|---|
| 795 | <para>
|
|---|
| 796 | On many systems, the hardware virtualization features first
|
|---|
| 797 | need to be enabled in the BIOS before &product-name; can use
|
|---|
| 798 | them.
|
|---|
| 799 | </para>
|
|---|
| 800 | </note>
|
|---|
| 801 | </listitem>
|
|---|
| 802 |
|
|---|
| 803 | <listitem>
|
|---|
| 804 | <para>
|
|---|
| 805 | As opposed to other virtualization software, for many usage
|
|---|
| 806 | scenarios, &product-name; does not
|
|---|
| 807 | <emphasis>require</emphasis> hardware virtualization features
|
|---|
| 808 | to be present. Through sophisticated techniques,
|
|---|
| 809 | &product-name; virtualizes many guest operating systems
|
|---|
| 810 | entirely in <emphasis>software</emphasis>. This means that you
|
|---|
| 811 | can run virtual machines even on older processors which do not
|
|---|
| 812 | support hardware virtualization.
|
|---|
| 813 | </para>
|
|---|
| 814 | </listitem>
|
|---|
| 815 |
|
|---|
| 816 | </itemizedlist>
|
|---|
| 817 |
|
|---|
| 818 | <para>
|
|---|
| 819 | Even though &product-name; does not always require hardware
|
|---|
| 820 | virtualization, enabling it is <emphasis>required</emphasis> in
|
|---|
| 821 | the following scenarios:
|
|---|
| 822 | </para>
|
|---|
| 823 |
|
|---|
| 824 | <itemizedlist>
|
|---|
| 825 |
|
|---|
| 826 | <listitem>
|
|---|
| 827 | <para>
|
|---|
| 828 | Certain rare guest operating systems like OS/2 make use of
|
|---|
| 829 | very esoteric processor instructions that are not supported
|
|---|
| 830 | with our software virtualization. For virtual machines that
|
|---|
| 831 | are configured to contain such an operating system, hardware
|
|---|
| 832 | virtualization is enabled automatically.
|
|---|
| 833 | </para>
|
|---|
| 834 | </listitem>
|
|---|
| 835 |
|
|---|
| 836 | <listitem>
|
|---|
| 837 | <para>
|
|---|
| 838 | &product-name;'s 64-bit guest support, added with version 2.0,
|
|---|
| 839 | and multiprocessing (SMP), added with version 3.0, both
|
|---|
| 840 | require hardware virtualization to be enabled. This is not
|
|---|
| 841 | much of a limitation since the vast majority of today's 64-bit
|
|---|
| 842 | and multicore CPUs ship with hardware virtualization anyway.
|
|---|
| 843 | The exceptions to this rule are older Intel Celeron and AMD
|
|---|
| 844 | Opteron CPUs, for example.
|
|---|
| 845 | </para>
|
|---|
| 846 | </listitem>
|
|---|
| 847 |
|
|---|
| 848 | </itemizedlist>
|
|---|
| 849 |
|
|---|
| 850 | <warning>
|
|---|
| 851 | <para>
|
|---|
| 852 | Do not run other hypervisors, either open source or commercial
|
|---|
| 853 | virtualization products, together with &product-name;. While
|
|---|
| 854 | several hypervisors can normally be
|
|---|
| 855 | <emphasis>installed</emphasis> in parallel, do not attempt to
|
|---|
| 856 | <emphasis>run</emphasis> several virtual machines from competing
|
|---|
| 857 | hypervisors at the same time. &product-name; cannot track what
|
|---|
| 858 | another hypervisor is currently attempting to do on the same
|
|---|
| 859 | host, and especially if several products attempt to use hardware
|
|---|
| 860 | virtualization features such as VT-x, this can crash the entire
|
|---|
| 861 | host. Also, within &product-name;, you can mix software and
|
|---|
| 862 | hardware virtualization when running multiple VMs. In certain
|
|---|
| 863 | cases a small performance penalty will be unavoidable when
|
|---|
| 864 | mixing VT-x and software virtualization VMs. We recommend not
|
|---|
| 865 | mixing virtualization modes if maximum performance and low
|
|---|
| 866 | overhead are essential. This does <emphasis>not</emphasis> apply
|
|---|
| 867 | to AMD-V.
|
|---|
| 868 | </para>
|
|---|
| 869 | </warning>
|
|---|
| 870 |
|
|---|
| 871 | </sect1>
|
|---|
| 872 |
|
|---|
| 873 | <sect1 id="gimproviders">
|
|---|
| 874 |
|
|---|
| 875 | <title>Paravirtualization Providers</title>
|
|---|
| 876 |
|
|---|
| 877 | <para>
|
|---|
| 878 | &product-name; enables the exposure of a paravirtualization
|
|---|
| 879 | interface, to facilitate accurate and efficient execution of
|
|---|
| 880 | software within a virtual machine. These interfaces require the
|
|---|
| 881 | guest operating system to recognize their presence and make use of
|
|---|
| 882 | them in order to leverage the benefits of communicating with the
|
|---|
| 883 | &product-name; hypervisor.
|
|---|
| 884 | </para>
|
|---|
| 885 |
|
|---|
| 886 | <para>
|
|---|
| 887 | Most modern mainstream guest operating systems, including Windows
|
|---|
| 888 | and Linux, ship with support for one or more paravirtualization
|
|---|
| 889 | interfaces. Hence, there is typically no need to install
|
|---|
| 890 | additional software in the guest to take advantage of this
|
|---|
| 891 | feature.
|
|---|
| 892 | </para>
|
|---|
| 893 |
|
|---|
| 894 | <para>
|
|---|
| 895 | Exposing a paravirtualization provider to the guest operating
|
|---|
| 896 | system does not rely on the choice of host platforms. For example,
|
|---|
| 897 | the <emphasis>Hyper-V</emphasis> paravirtualization provider can
|
|---|
| 898 | be used for VMs to run on any host platform supported by
|
|---|
| 899 | &product-name; and not just Windows.
|
|---|
| 900 | </para>
|
|---|
| 901 |
|
|---|
| 902 | <para>
|
|---|
| 903 | &product-name; provides the following interfaces:
|
|---|
| 904 | </para>
|
|---|
| 905 |
|
|---|
| 906 | <itemizedlist>
|
|---|
| 907 |
|
|---|
| 908 | <listitem>
|
|---|
| 909 | <para>
|
|---|
| 910 | <emphasis role="bold">Minimal</emphasis>: Announces the
|
|---|
| 911 | presence of a virtualized environment. Additionally, reports
|
|---|
| 912 | the TSC and APIC frequency to the guest operating system. This
|
|---|
| 913 | provider is mandatory for running any Mac OS X guests.
|
|---|
| 914 | </para>
|
|---|
| 915 | </listitem>
|
|---|
| 916 |
|
|---|
| 917 | <listitem>
|
|---|
| 918 | <para>
|
|---|
| 919 | <emphasis role="bold">KVM</emphasis>: Presents a Linux KVM
|
|---|
| 920 | hypervisor interface which is recognized by Linux kernels
|
|---|
| 921 | version 2.6.25 or later. &product-name;'s implementation
|
|---|
| 922 | currently supports paravirtualized clocks and SMP spinlocks.
|
|---|
| 923 | This provider is recommended for Linux guests.
|
|---|
| 924 | </para>
|
|---|
| 925 | </listitem>
|
|---|
| 926 |
|
|---|
| 927 | <listitem>
|
|---|
| 928 | <para>
|
|---|
| 929 | <emphasis role="bold">Hyper-V</emphasis>: Presents a Microsoft
|
|---|
| 930 | Hyper-V hypervisor interface which is recognized by Windows 7
|
|---|
| 931 | and newer operating systems. &product-name;'s implementation
|
|---|
| 932 | currently supports paravirtualized clocks, APIC frequency
|
|---|
| 933 | reporting, guest debugging, guest crash reporting and relaxed
|
|---|
| 934 | timer checks. This provider is recommended for Windows guests.
|
|---|
| 935 | </para>
|
|---|
| 936 | </listitem>
|
|---|
| 937 |
|
|---|
| 938 | </itemizedlist>
|
|---|
| 939 |
|
|---|
| 940 | </sect1>
|
|---|
| 941 |
|
|---|
| 942 | <sect1 id="swvirt-details">
|
|---|
| 943 |
|
|---|
| 944 | <title>Details About Software Virtualization</title>
|
|---|
| 945 |
|
|---|
| 946 | <para>
|
|---|
| 947 | Implementing virtualization on x86 CPUs with no hardware
|
|---|
| 948 | virtualization support is an extraordinarily complex task because
|
|---|
| 949 | the CPU architecture was not designed to be virtualized. The
|
|---|
| 950 | problems can usually be solved, but at the cost of reduced
|
|---|
| 951 | performance. Thus, there is a constant clash between
|
|---|
| 952 | virtualization performance and accuracy.
|
|---|
| 953 | </para>
|
|---|
| 954 |
|
|---|
| 955 | <para>
|
|---|
| 956 | The x86 instruction set was originally designed in the 1970s and
|
|---|
| 957 | underwent significant changes with the addition of protected mode
|
|---|
| 958 | in the 1980s with the 286 CPU architecture and then again with the
|
|---|
| 959 | Intel 386 and its 32-bit architecture. Whereas the 386 did have
|
|---|
| 960 | limited virtualization support for real mode operation with V86
|
|---|
| 961 | mode, as used by the "DOS Box" of Windows 3.x and OS/2 2.x, no
|
|---|
| 962 | support was provided for virtualizing the entire architecture.
|
|---|
| 963 | </para>
|
|---|
| 964 |
|
|---|
| 965 | <para>
|
|---|
| 966 | In theory, software virtualization is not overly complex. There
|
|---|
| 967 | are four privilege levels, called <emphasis>rings</emphasis>,
|
|---|
| 968 | provided by the hardware. Typically only two rings are used: ring
|
|---|
| 969 | 0 for kernel mode and ring 3 for user mode. Additionally, one
|
|---|
| 970 | needs to differentiate between <emphasis>host context</emphasis>
|
|---|
| 971 | and <emphasis>guest context</emphasis>.
|
|---|
| 972 | </para>
|
|---|
| 973 |
|
|---|
| 974 | <para>
|
|---|
| 975 | In host context, everything is as if no hypervisor was active.
|
|---|
| 976 | This might be the active mode if another application on your host
|
|---|
| 977 | has been scheduled CPU time. In that case, there is a host ring 3
|
|---|
| 978 | mode and a host ring 0 mode. The hypervisor is not involved.
|
|---|
| 979 | </para>
|
|---|
| 980 |
|
|---|
| 981 | <para>
|
|---|
| 982 | In guest context, however, a virtual machine is active. So long as
|
|---|
| 983 | the guest code is running in ring 3, this is not much of a problem
|
|---|
| 984 | since a hypervisor can set up the page tables properly and run
|
|---|
| 985 | that code natively on the processor. The problems mostly lie in
|
|---|
| 986 | how to intercept what the guest's kernel does.
|
|---|
| 987 | </para>
|
|---|
| 988 |
|
|---|
| 989 | <para>
|
|---|
| 990 | There are several possible solutions to these problems. One
|
|---|
| 991 | approach is full software emulation, usually involving
|
|---|
| 992 | recompilation. That is, all code to be run by the guest is
|
|---|
| 993 | analyzed, transformed into a form which will not allow the guest
|
|---|
| 994 | to either modify or see the true state of the CPU, and only then
|
|---|
| 995 | executed. This process is obviously highly complex and costly in
|
|---|
| 996 | terms of performance. &product-name; contains a recompiler based
|
|---|
| 997 | on QEMU which can be used for pure software emulation, but the
|
|---|
| 998 | recompiler is only activated in special situations, described
|
|---|
| 999 | below.
|
|---|
| 1000 | </para>
|
|---|
| 1001 |
|
|---|
| 1002 | <para>
|
|---|
| 1003 | Another possible solution is paravirtualization, in which only
|
|---|
| 1004 | specially modified guest OSes are allowed to run. This way, most
|
|---|
| 1005 | of the hardware access is abstracted and any functions which would
|
|---|
| 1006 | normally access the hardware or privileged CPU state are passed on
|
|---|
| 1007 | to the hypervisor instead. Paravirtualization can achieve good
|
|---|
| 1008 | functionality and performance on standard x86 CPUs, but it can
|
|---|
| 1009 | only work if the guest OS can actually be modified, which is
|
|---|
| 1010 | obviously not always the case.
|
|---|
| 1011 | </para>
|
|---|
| 1012 |
|
|---|
| 1013 | <para>
|
|---|
| 1014 | &product-name; chooses a different approach. When starting a
|
|---|
| 1015 | virtual machine, through its ring-0 support kernel driver,
|
|---|
| 1016 | &product-name; has set up the host system so that it can run most
|
|---|
| 1017 | of the guest code natively, but it has inserted itself at the
|
|---|
| 1018 | "bottom" of the picture. It can then assume control when needed.
|
|---|
| 1019 | If a privileged instruction is executed, the guest traps, in
|
|---|
| 1020 | particular because an I/O register was accessed and a device needs
|
|---|
| 1021 | to be virtualized, or external interrupts occur. &product-name;
|
|---|
| 1022 | may then handle this and either route a request to a virtual
|
|---|
| 1023 | device or possibly delegate handling such things to the guest or
|
|---|
| 1024 | host OS. In guest context, &product-name; can therefore be in one
|
|---|
| 1025 | of three states:
|
|---|
| 1026 | </para>
|
|---|
| 1027 |
|
|---|
| 1028 | <itemizedlist>
|
|---|
| 1029 |
|
|---|
| 1030 | <listitem>
|
|---|
| 1031 | <para>
|
|---|
| 1032 | Guest ring 3 code is run unmodified, at full speed, as much as
|
|---|
| 1033 | possible. The number of faults will generally be low, unless
|
|---|
| 1034 | the guest allows port I/O from ring 3. This is something we
|
|---|
| 1035 | cannot do as we do not want the guest to be able to access
|
|---|
| 1036 | real ports. This is also referred to as <emphasis>raw
|
|---|
| 1037 | mode</emphasis>, as the guest ring-3 code runs unmodified.
|
|---|
| 1038 | </para>
|
|---|
| 1039 | </listitem>
|
|---|
| 1040 |
|
|---|
| 1041 | <listitem>
|
|---|
| 1042 | <para>
|
|---|
| 1043 | For guest code in ring 0, &product-name; employs a clever
|
|---|
| 1044 | trick. It actually reconfigures the guest so that its ring-0
|
|---|
| 1045 | code is run in ring 1 instead, which is normally not used in
|
|---|
| 1046 | x86 operating systems). As a result, when guest ring-0 code,
|
|---|
| 1047 | actually running n ring 1, such as a guest device driver
|
|---|
| 1048 | attempts to write to an I/O register or execute a privileged
|
|---|
| 1049 | instruction, the &product-name; hypervisor in the "real" ring
|
|---|
| 1050 | 0 can take over.
|
|---|
| 1051 | </para>
|
|---|
| 1052 | </listitem>
|
|---|
| 1053 |
|
|---|
| 1054 | <listitem>
|
|---|
| 1055 | <para>
|
|---|
| 1056 | The hypervisor (VMM) can be active. Every time a fault occurs,
|
|---|
| 1057 | &product-name; looks at the offending instruction and can
|
|---|
| 1058 | relegate it to a virtual device or the host OS or the guest OS
|
|---|
| 1059 | or run it in the recompiler.
|
|---|
| 1060 | </para>
|
|---|
| 1061 |
|
|---|
| 1062 | <para>
|
|---|
| 1063 | In particular, the recompiler is used when guest code disables
|
|---|
| 1064 | interrupts and &product-name; cannot figure out when they will
|
|---|
| 1065 | be switched back on. In these situations, &product-name;
|
|---|
| 1066 | actually analyzes the guest code using its own disassembler.
|
|---|
| 1067 | Also, certain privileged instructions such as LIDT need to be
|
|---|
| 1068 | handled specially. Finally, any real-mode or protected-mode
|
|---|
| 1069 | code, such as BIOS code, a DOS guest, or any operating system
|
|---|
| 1070 | startup, is run in the recompiler entirely.
|
|---|
| 1071 | </para>
|
|---|
| 1072 | </listitem>
|
|---|
| 1073 |
|
|---|
| 1074 | </itemizedlist>
|
|---|
| 1075 |
|
|---|
| 1076 | <para>
|
|---|
| 1077 | Unfortunately this only works to a degree. Among others, the
|
|---|
| 1078 | following situations require special handling:
|
|---|
| 1079 | </para>
|
|---|
| 1080 |
|
|---|
| 1081 | <itemizedlist>
|
|---|
| 1082 |
|
|---|
| 1083 | <listitem>
|
|---|
| 1084 | <para>
|
|---|
| 1085 | Running ring 0 code in ring 1 causes a lot of additional
|
|---|
| 1086 | instruction faults, as ring 1 is not allowed to execute any
|
|---|
| 1087 | privileged instructions, of which guest's ring-0 contains
|
|---|
| 1088 | plenty. With each of these faults, the VMM must step in and
|
|---|
| 1089 | emulate the code to achieve the desired behavior. While this
|
|---|
| 1090 | works, emulating thousands of these faults is very expensive
|
|---|
| 1091 | and severely hurts the performance of the virtualized guest.
|
|---|
| 1092 | </para>
|
|---|
| 1093 | </listitem>
|
|---|
| 1094 |
|
|---|
| 1095 | <listitem>
|
|---|
| 1096 | <para>
|
|---|
| 1097 | There are certain flaws in the implementation of ring 1 in the
|
|---|
| 1098 | x86 architecture that were never fixed. Certain instructions
|
|---|
| 1099 | that <emphasis>should</emphasis> trap in ring 1 do not. This
|
|---|
| 1100 | affects, for example, the LGDT/SGDT, LIDT/SIDT, or POPF/PUSHF
|
|---|
| 1101 | instruction pairs. Whereas the "load" operation is privileged
|
|---|
| 1102 | and can therefore be trapped, the "store" instruction always
|
|---|
| 1103 | succeed. If the guest is allowed to execute these, it will see
|
|---|
| 1104 | the true state of the CPU, not the virtualized state. The
|
|---|
| 1105 | CPUID instruction also has the same problem.
|
|---|
| 1106 | </para>
|
|---|
| 1107 | </listitem>
|
|---|
| 1108 |
|
|---|
| 1109 | <listitem>
|
|---|
| 1110 | <para>
|
|---|
| 1111 | A hypervisor typically needs to reserve some portion of the
|
|---|
| 1112 | guest's address space, both linear address space and
|
|---|
| 1113 | selectors, for its own use. This is not entirely transparent
|
|---|
| 1114 | to the guest OS and may cause clashes.
|
|---|
| 1115 | </para>
|
|---|
| 1116 | </listitem>
|
|---|
| 1117 |
|
|---|
| 1118 | <listitem>
|
|---|
| 1119 | <para>
|
|---|
| 1120 | The SYSENTER instruction, used for system calls, executed by
|
|---|
| 1121 | an application running in a guest OS always transitions to
|
|---|
| 1122 | ring 0. But that is where the hypervisor runs, not the guest
|
|---|
| 1123 | OS. In this case, the hypervisor must trap and emulate the
|
|---|
| 1124 | instruction even when it is not desirable.
|
|---|
| 1125 | </para>
|
|---|
| 1126 | </listitem>
|
|---|
| 1127 |
|
|---|
| 1128 | <listitem>
|
|---|
| 1129 | <para>
|
|---|
| 1130 | The CPU segment registers contain a "hidden" descriptor cache
|
|---|
| 1131 | which is not software-accessible. The hypervisor cannot read,
|
|---|
| 1132 | save, or restore this state, but the guest OS may use it.
|
|---|
| 1133 | </para>
|
|---|
| 1134 | </listitem>
|
|---|
| 1135 |
|
|---|
| 1136 | <listitem>
|
|---|
| 1137 | <para>
|
|---|
| 1138 | Some resources must, and can, be trapped by the hypervisor,
|
|---|
| 1139 | but the access is so frequent that this creates a significant
|
|---|
| 1140 | performance overhead. An example is the TPR (Task Priority)
|
|---|
| 1141 | register in 32-bit mode. Accesses to this register must be
|
|---|
| 1142 | trapped by the hypervisor. But certain guest operating
|
|---|
| 1143 | systems, notably Windows and Oracle Solaris, write this
|
|---|
| 1144 | register very often, which adversely affects virtualization
|
|---|
| 1145 | performance.
|
|---|
| 1146 | </para>
|
|---|
| 1147 | </listitem>
|
|---|
| 1148 |
|
|---|
| 1149 | </itemizedlist>
|
|---|
| 1150 |
|
|---|
| 1151 | <para>
|
|---|
| 1152 | To fix these performance and security issues, &product-name;
|
|---|
| 1153 | contains a Code Scanning and Analysis Manager (CSAM), which
|
|---|
| 1154 | disassembles guest code, and the Patch Manager (PATM), which can
|
|---|
| 1155 | replace it at runtime.
|
|---|
| 1156 | </para>
|
|---|
| 1157 |
|
|---|
| 1158 | <para>
|
|---|
| 1159 | Before executing ring 0 code, CSAM scans it recursively to
|
|---|
| 1160 | discover problematic instructions. PATM then performs
|
|---|
| 1161 | <emphasis>in-situ </emphasis>patching. It replaces the instruction
|
|---|
| 1162 | with a jump to hypervisor memory where an integrated code
|
|---|
| 1163 | generator has placed a more suitable implementation. In reality,
|
|---|
| 1164 | this is a very complex task as there are lots of odd situations to
|
|---|
| 1165 | be discovered and handled correctly. So, with its current
|
|---|
| 1166 | complexity, one could argue that PATM is an advanced
|
|---|
| 1167 | <emphasis>in-situ</emphasis> recompiler.
|
|---|
| 1168 | </para>
|
|---|
| 1169 |
|
|---|
| 1170 | <para>
|
|---|
| 1171 | In addition, every time a fault occurs, &product-name; analyzes
|
|---|
| 1172 | the offending code to determine if it is possible to patch it in
|
|---|
| 1173 | order to prevent it from causing more faults in the future. This
|
|---|
| 1174 | approach works well in practice and dramatically improves software
|
|---|
| 1175 | virtualization performance.
|
|---|
| 1176 | </para>
|
|---|
| 1177 |
|
|---|
| 1178 | </sect1>
|
|---|
| 1179 |
|
|---|
| 1180 | <sect1 id="hwvirt-details">
|
|---|
| 1181 |
|
|---|
| 1182 | <title>Details About Hardware Virtualization</title>
|
|---|
| 1183 |
|
|---|
| 1184 | <para>
|
|---|
| 1185 | With Intel VT-x, there are two distinct modes of CPU operation:
|
|---|
| 1186 | VMX root mode and non-root mode.
|
|---|
| 1187 | </para>
|
|---|
| 1188 |
|
|---|
| 1189 | <itemizedlist>
|
|---|
| 1190 |
|
|---|
| 1191 | <listitem>
|
|---|
| 1192 | <para>
|
|---|
| 1193 | In root mode, the CPU operates much like older generations of
|
|---|
| 1194 | processors without VT-x support. There are four privilege
|
|---|
| 1195 | levels, called rings, and the same instruction set is
|
|---|
| 1196 | supported, with the addition of several virtualization
|
|---|
| 1197 | specific instruction. Root mode is what a host operating
|
|---|
| 1198 | system without virtualization uses, and it is also used by a
|
|---|
| 1199 | hypervisor when virtualization is active.
|
|---|
| 1200 | </para>
|
|---|
| 1201 | </listitem>
|
|---|
| 1202 |
|
|---|
| 1203 | <listitem>
|
|---|
| 1204 | <para>
|
|---|
| 1205 | In non-root mode, CPU operation is significantly different.
|
|---|
| 1206 | There are still four privilege rings and the same instruction
|
|---|
| 1207 | set, but a new structure called VMCS (Virtual Machine Control
|
|---|
| 1208 | Structure) now controls the CPU operation and determines how
|
|---|
| 1209 | certain instructions behave. Non-root mode is where guest
|
|---|
| 1210 | systems run.
|
|---|
| 1211 | </para>
|
|---|
| 1212 | </listitem>
|
|---|
| 1213 |
|
|---|
| 1214 | </itemizedlist>
|
|---|
| 1215 |
|
|---|
| 1216 | <para>
|
|---|
| 1217 | Switching from root mode to non-root mode is called "VM entry",
|
|---|
| 1218 | the switch back is "VM exit". The VMCS includes a guest and host
|
|---|
| 1219 | state area which is saved/restored at VM entry and exit. Most
|
|---|
| 1220 | importantly, the VMCS controls which guest operations will cause
|
|---|
| 1221 | VM exits.
|
|---|
| 1222 | </para>
|
|---|
| 1223 |
|
|---|
| 1224 | <para>
|
|---|
| 1225 | The VMCS provides fairly fine-grained control over what the guests
|
|---|
| 1226 | can and cannot do. For example, a hypervisor can allow a guest to
|
|---|
| 1227 | write certain bits in shadowed control registers, but not others.
|
|---|
| 1228 | This enables efficient virtualization in cases where guests can be
|
|---|
| 1229 | allowed to write control bits without disrupting the hypervisor,
|
|---|
| 1230 | while preventing them from altering control bits over which the
|
|---|
| 1231 | hypervisor needs to retain full control. The VMCS also provides
|
|---|
| 1232 | control over interrupt delivery and exceptions.
|
|---|
| 1233 | </para>
|
|---|
| 1234 |
|
|---|
| 1235 | <para>
|
|---|
| 1236 | Whenever an instruction or event causes a VM exit, the VMCS
|
|---|
| 1237 | contains information about the exit reason, often with
|
|---|
| 1238 | accompanying detail. For example, if a write to the CR0 register
|
|---|
| 1239 | causes an exit, the offending instruction is recorded, along with
|
|---|
| 1240 | the fact that a write access to a control register caused the
|
|---|
| 1241 | exit, and information about source and destination register. Thus
|
|---|
| 1242 | the hypervisor can efficiently handle the condition without
|
|---|
| 1243 | needing advanced techniques such as CSAM and PATM described above.
|
|---|
| 1244 | </para>
|
|---|
| 1245 |
|
|---|
| 1246 | <para>
|
|---|
| 1247 | VT-x inherently avoids several of the problems which software
|
|---|
| 1248 | virtualization faces. The guest has its own completely separate
|
|---|
| 1249 | address space not shared with the hypervisor, which eliminates
|
|---|
| 1250 | potential clashes. Additionally, guest OS kernel code runs at
|
|---|
| 1251 | privilege ring 0 in VMX non-root mode, obviating the problems by
|
|---|
| 1252 | running ring 0 code at less privileged levels. For example the
|
|---|
| 1253 | SYSENTER instruction can transition to ring 0 without causing
|
|---|
| 1254 | problems. Naturally, even at ring 0 in VMX non-root mode, any I/O
|
|---|
| 1255 | access by guest code still causes a VM exit, allowing for device
|
|---|
| 1256 | emulation.
|
|---|
| 1257 | </para>
|
|---|
| 1258 |
|
|---|
| 1259 | <para>
|
|---|
| 1260 | The biggest difference between VT-x and AMD-V is that AMD-V
|
|---|
| 1261 | provides a more complete virtualization environment. VT-x requires
|
|---|
| 1262 | the VMX non-root code to run with paging enabled, which precludes
|
|---|
| 1263 | hardware virtualization of real-mode code and non-paged
|
|---|
| 1264 | protected-mode software. This typically only includes firmware and
|
|---|
| 1265 | OS loaders, but nevertheless complicates VT-x hypervisor
|
|---|
| 1266 | implementation. AMD-V does not have this restriction.
|
|---|
| 1267 | </para>
|
|---|
| 1268 |
|
|---|
| 1269 | <para>
|
|---|
| 1270 | Of course hardware virtualization is not perfect. Compared to
|
|---|
| 1271 | software virtualization, the overhead of VM exits is relatively
|
|---|
| 1272 | high. This causes problems for devices whose emulation requires
|
|---|
| 1273 | high number of traps. One example is the VGA device in 16-color
|
|---|
| 1274 | modes, where not only every I/O port access but also every access
|
|---|
| 1275 | to the framebuffer memory must be trapped.
|
|---|
| 1276 | </para>
|
|---|
| 1277 |
|
|---|
| 1278 | </sect1>
|
|---|
| 1279 |
|
|---|
| 1280 | <sect1 id="nestedpaging">
|
|---|
| 1281 |
|
|---|
| 1282 | <title>Nested Paging and VPIDs</title>
|
|---|
| 1283 |
|
|---|
| 1284 | <para>
|
|---|
| 1285 | In addition to normal hardware virtualization, your processor may
|
|---|
| 1286 | also support the following additional sophisticated techniques:
|
|---|
| 1287 | </para>
|
|---|
| 1288 |
|
|---|
| 1289 | <itemizedlist>
|
|---|
| 1290 |
|
|---|
| 1291 | <listitem>
|
|---|
| 1292 | <para>
|
|---|
| 1293 | Nested paging implements some memory management in hardware,
|
|---|
| 1294 | which can greatly accelerate hardware virtualization since
|
|---|
| 1295 | these tasks no longer need to be performed by the
|
|---|
| 1296 | virtualization software.
|
|---|
| 1297 | </para>
|
|---|
| 1298 |
|
|---|
| 1299 | <para>
|
|---|
| 1300 | With nested paging, the hardware provides another level of
|
|---|
| 1301 | indirection when translating linear to physical addresses.
|
|---|
| 1302 | Page tables function as before, but linear addresses are now
|
|---|
| 1303 | translated to "guest physical" addresses first and not
|
|---|
| 1304 | physical addresses directly. A new set of paging registers now
|
|---|
| 1305 | exists under the traditional paging mechanism and translates
|
|---|
| 1306 | from guest physical addresses to host physical addresses,
|
|---|
| 1307 | which are used to access memory.
|
|---|
| 1308 | </para>
|
|---|
| 1309 |
|
|---|
| 1310 | <para>
|
|---|
| 1311 | Nested paging eliminates the overhead caused by VM exits and
|
|---|
| 1312 | page table accesses. In essence, with nested page tables the
|
|---|
| 1313 | guest can handle paging without intervention from the
|
|---|
| 1314 | hypervisor. Nested paging thus significantly improves
|
|---|
| 1315 | virtualization performance.
|
|---|
| 1316 | </para>
|
|---|
| 1317 |
|
|---|
| 1318 | <para>
|
|---|
| 1319 | On AMD processors, nested paging has been available starting
|
|---|
| 1320 | with the Barcelona (K10) architecture. They now call it rapid
|
|---|
| 1321 | virtualization indexing (RVI). Intel added support for nested
|
|---|
| 1322 | paging, which they call extended page tables (EPT), with their
|
|---|
| 1323 | Core i7 (Nehalem) processors.
|
|---|
| 1324 | </para>
|
|---|
| 1325 |
|
|---|
| 1326 | <para>
|
|---|
| 1327 | If nested paging is enabled, the &product-name; hypervisor can
|
|---|
| 1328 | also use <emphasis>large pages</emphasis> to reduce TLB usage
|
|---|
| 1329 | and overhead. This can yield a performance improvement of up
|
|---|
| 1330 | to 5%. To enable this feature for a VM, you need to use the
|
|---|
| 1331 | <computeroutput>VBoxManage modifyvm --largepages</computeroutput>
|
|---|
| 1332 | command. See <xref linkend="vboxmanage-modifyvm" />.
|
|---|
| 1333 | </para>
|
|---|
| 1334 |
|
|---|
| 1335 | <para>
|
|---|
| 1336 | If you have an Intel CPU with EPT, please consult
|
|---|
| 1337 | <xref linkend="sec-rec-cve-2018-3646" /> for security concerns
|
|---|
| 1338 | regarding EPT.
|
|---|
| 1339 | </para>
|
|---|
| 1340 | </listitem>
|
|---|
| 1341 |
|
|---|
| 1342 | <listitem>
|
|---|
| 1343 | <para>
|
|---|
| 1344 | On Intel CPUs, a hardware feature called Virtual Processor
|
|---|
| 1345 | Identifiers (VPIDs) can greatly accelerate context switching
|
|---|
| 1346 | by reducing the need for expensive flushing of the processor's
|
|---|
| 1347 | Translation Lookaside Buffers (TLBs).
|
|---|
| 1348 | </para>
|
|---|
| 1349 |
|
|---|
| 1350 | <para>
|
|---|
| 1351 | To enable these features for a VM, you need to use the
|
|---|
| 1352 | <computeroutput>VBoxManage modifyvm --vtxvpid</computeroutput>
|
|---|
| 1353 | and <computeroutput>--largepages</computeroutput> commands.
|
|---|
| 1354 | See <xref linkend="vboxmanage-modifyvm" />.
|
|---|
| 1355 | </para>
|
|---|
| 1356 | </listitem>
|
|---|
| 1357 |
|
|---|
| 1358 | </itemizedlist>
|
|---|
| 1359 |
|
|---|
| 1360 | </sect1>
|
|---|
| 1361 |
|
|---|
| 1362 | </chapter>
|
|---|
