VirtualBox

source: vbox/trunk/doc/manual/en_US/user_Technical.xml@ 77787

Last change on this file since 77787 was 76786, checked in by vboxsync, 6 years ago

manual: integrate drop #40 with minimal manual adjustments (but everything into one book, with manually applied tweaks to turn the release notes into a pure changelog again, and eliminated trailing whitespace)

  • Property svn:eol-style set to native
  • Property svn:keywords set to Id Revision
File size: 51.7 KB
Line 
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 The following table gives a brief overview of the configuration
320 changes between legacy versions and version 4.0 or later.
321 </para>
322
323 <table id="table-version4-config-changes" tabstyle="oracle-all">
324 <title>Configuration Changes in Version 4.0 or Above</title>
325 <tgroup cols="3">
326 <thead>
327 <row>
328 <entry><para>
329 <emphasis role="bold">Setting</emphasis>
330 </para></entry>
331 <entry><para>
332 <emphasis role="bold">Before 4.0</emphasis>
333 </para></entry>
334 <entry><para>
335 <emphasis role="bold">4.0 or above</emphasis>
336 </para></entry>
337 </row>
338 </thead>
339 <tbody>
340 <row>
341 <entry><para>
342 Default machines folder
343 </para></entry>
344 <entry><para>
345 <computeroutput>$HOME/.VirtualBox/Machines</computeroutput>
346 </para></entry>
347 <entry><para>
348 <computeroutput>$HOME/VirtualBox VMs</computeroutput>
349 </para></entry>
350 </row>
351 <row>
352 <entry><para>
353 Default disk image location
354 </para></entry>
355 <entry><para>
356 <computeroutput>$HOME/.VirtualBox/HardDisks</computeroutput>
357 </para></entry>
358 <entry><para>
359 In each machine's folder
360 </para></entry>
361 </row>
362 <row>
363 <entry><para>
364 Machine settings file extension
365 </para></entry>
366 <entry><para>
367 <computeroutput>.xml</computeroutput>
368 </para></entry>
369 <entry><para>
370 <computeroutput>.vbox</computeroutput>
371 </para></entry>
372 </row>
373 <row>
374 <entry><para>
375 Media registry
376 </para></entry>
377 <entry><para>
378 Global <computeroutput>VirtualBox.xml</computeroutput>
379 file
380 </para></entry>
381 <entry><para>
382 Each machine settings file
383 </para></entry>
384 </row>
385 <row>
386 <entry><para>
387 Media registration
388 </para></entry>
389 <entry><para>
390 Explicit open/close required
391 </para></entry>
392 <entry><para>
393 Automatic on attach
394 </para></entry>
395 </row>
396 </tbody>
397 </tgroup>
398 </table>
399
400 </sect2>
401
402 <sect2 id="vboxconfigdata-XML-files">
403
404 <title>&product-name; XML Files</title>
405
406 <para>
407 &product-name; uses XML for both the machine settings files and
408 the global configuration file,
409 <computeroutput>VirtualBox.xml</computeroutput>.
410 </para>
411
412 <para>
413 All &product-name; XML files are versioned. When a new settings
414 file is created, for example because a new virtual machine is
415 created, &product-name; automatically uses the settings format
416 of the current &product-name; version. These files may not be
417 readable if you downgrade to an earlier version of
418 &product-name;. However, when &product-name; encounters a
419 settings file from an earlier version, such as after upgrading
420 &product-name;, it attempts to preserve the settings format as
421 much as possible. It will only silently upgrade the settings
422 format if the current settings cannot be expressed in the old
423 format, for example because you enabled a feature that was not
424 present in an earlier version of &product-name;.
425 </para>
426
427 <para>
428 As an example, before &product-name; 3.1, it was only possible
429 to enable or disable a single DVD drive in a virtual machine. If
430 it was enabled, then it would always be visible as the secondary
431 master of the IDE controller. With &product-name; 3.1, DVD
432 drives can be attached to arbitrary slots of arbitrary
433 controllers, so they could be the secondary slave of an IDE
434 controller or in a SATA slot. If you have a machine settings
435 file from an earlier version and upgrade &product-name; to 3.1
436 and then move the DVD drive from its default position, this
437 cannot be expressed in the old settings format; the XML machine
438 file would get written in the new format, and a backup file of
439 the old format would be kept.
440 </para>
441
442 <para>
443 In such cases, &product-name; backs up the old settings file in
444 the virtual machine's configuration directory. If you need to go
445 back to the earlier version of &product-name;, then you will
446 need to manually copy these backup files back.
447 </para>
448
449 <para>
450 We intentionally do not document the specifications of the
451 &product-name; XML files, as we must reserve the right to modify
452 them in the future. We therefore strongly suggest that you do
453 not edit these files manually. &product-name; provides complete
454 access to its configuration data through its the
455 <command>VBoxManage</command> command line tool, see
456 <xref linkend="vboxmanage" /> and its API, see
457 <xref linkend="VirtualBoxAPI" />.
458 </para>
459
460 </sect2>
461
462 </sect1>
463
464 <sect1 id="technical-components">
465
466 <title>&product-name; Executables and Components</title>
467
468 <para>
469 &product-name; was designed to be modular and flexible. When the
470 &product-name; graphical user interface (GUI) is opened and a VM
471 is started, at least the following three processes are running:
472 </para>
473
474 <itemizedlist>
475
476 <listitem>
477 <para>
478 <computeroutput>VBoxSVC</computeroutput>, the &product-name;
479 service process which always runs in the background. This
480 process is started automatically by the first &product-name;
481 client process and exits a short time after the last client
482 exits. The first &product-name; service can be the GUI,
483 <computeroutput>VBoxManage</computeroutput>,
484 <computeroutput>VBoxHeadless</computeroutput>, the web service
485 amongst others. The service is responsible for bookkeeping,
486 maintaining the state of all VMs, and for providing
487 communication between &product-name; components. This
488 communication is implemented using COM/XPCOM.
489 </para>
490
491 <note>
492 <para>
493 When we refer to <emphasis>clients</emphasis> here, we mean
494 the local clients of a particular
495 <computeroutput>VBoxSVC</computeroutput> server process, not
496 clients in a network. &product-name; employs its own
497 client/server design to allow its processes to cooperate,
498 but all these processes run under the same user account on
499 the host operating system, and this is totally transparent
500 to the user.
501 </para>
502 </note>
503 </listitem>
504
505 <listitem>
506 <para>
507 The GUI process,
508 <computeroutput>VirtualBoxVM</computeroutput>, a client
509 application based on the cross-platform Qt library. When
510 started without the <computeroutput>--startvm</computeroutput>
511 option, this application acts as the VirtualBox Manager,
512 displaying the VMs and their settings. It then communicates
513 settings and state changes to
514 <computeroutput>VBoxSVC</computeroutput> and also reflects
515 changes effected through other means, such as the
516 <command>VBoxManage</command> command.
517 </para>
518 </listitem>
519
520 <listitem>
521 <para>
522 If the <computeroutput>VirtualBoxVM</computeroutput> client
523 application is started with the
524 <computeroutput>--startvm</computeroutput> argument, it loads
525 the VMM library which includes the actual hypervisor and then
526 runs a virtual machine and provides the input and output for
527 the guest.
528 </para>
529 </listitem>
530
531 </itemizedlist>
532
533 <para>
534 Any &product-name; front-end, or client, will communicate with the
535 service process and can both control and reflect the current
536 state. For example, either the VM selector or the VM window or
537 VBoxManage can be used to pause the running VM, and other
538 components will always reflect the changed state.
539 </para>
540
541 <para>
542 The &product-name; GUI application is only one of several
543 available front ends, or clients. The complete list shipped with
544 &product-name; is as follows:
545 </para>
546
547 <itemizedlist>
548
549 <listitem>
550 <para>
551 <computeroutput>VirtualBoxVM</computeroutput>: The Qt front
552 end implementing the VirtualBox Manager and running VMs.
553 </para>
554 </listitem>
555
556 <listitem>
557 <para>
558 <computeroutput>VBoxManage</computeroutput>: A less
559 user-friendly but more powerful alternative. See
560 <xref linkend="vboxmanage" />.
561 </para>
562 </listitem>
563
564 <listitem>
565 <para>
566 <computeroutput>VBoxHeadless</computeroutput>: A VM front end
567 which does not directly provide any video output and keyboard
568 or mouse input, but enables redirection through the VirtualBox
569 Remote Desktop Extension. See <xref linkend="vboxheadless" />.
570 </para>
571 </listitem>
572
573 <listitem>
574 <para>
575 <computeroutput>vboxwebsrv</computeroutput>: The
576 &product-name; web service process which enables control of an
577 &product-name; host remotely. This is described in detail in
578 the &product-name; Software Development Kit (SDK) reference.
579 See <xref linkend="VirtualBoxAPI" />.
580 </para>
581 </listitem>
582
583 <listitem>
584 <para>
585 The &product-name; Python shell: A Python alternative to
586 <computeroutput>VBoxManage</computeroutput>. This is also
587 described in the SDK reference.
588 </para>
589 </listitem>
590
591 </itemizedlist>
592
593 <para>
594 Internally, &product-name; consists of many more or less separate
595 components. You may encounter these when analyzing &product-name;
596 internal error messages or log files. These include the following:
597 </para>
598
599 <itemizedlist>
600
601 <listitem>
602 <para>
603 IPRT: A portable runtime library which abstracts file access,
604 threading, and string manipulation. Whenever &product-name;
605 accesses host operating features, it does so through this
606 library for cross-platform portability.
607 </para>
608 </listitem>
609
610 <listitem>
611 <para>
612 VMM (Virtual Machine Monitor): The heart of the hypervisor.
613 </para>
614 </listitem>
615
616 <listitem>
617 <para>
618 EM (Execution Manager): Controls execution of guest code.
619 </para>
620 </listitem>
621
622 <listitem>
623 <para>
624 REM (Recompiled Execution Monitor): Provides software
625 emulation of CPU instructions.
626 </para>
627 </listitem>
628
629 <listitem>
630 <para>
631 TRPM (Trap Manager): Intercepts and processes guest traps and
632 exceptions.
633 </para>
634 </listitem>
635
636 <listitem>
637 <para>
638 HM (Hardware Acceleration Manager): Provides support for VT-x
639 and AMD-V.
640 </para>
641 </listitem>
642
643 <listitem>
644 <para>
645 GIM (Guest Interface Manager): Provides support for various
646 paravirtualization interfaces to the guest.
647 </para>
648 </listitem>
649
650 <listitem>
651 <para>
652 PDM (Pluggable Device Manager): An abstract interface between
653 the VMM and emulated devices which separates device
654 implementations from VMM internals and makes it easy to add
655 new emulated devices. Through PDM, third-party developers can
656 add new virtual devices to &product-name; without having to
657 change &product-name; itself.
658 </para>
659 </listitem>
660
661 <listitem>
662 <para>
663 PGM (Page Manager): A component that controls guest paging.
664 </para>
665 </listitem>
666
667 <listitem>
668 <para>
669 PATM (Patch Manager): Patches guest code to improve and speed
670 up software virtualization.
671 </para>
672 </listitem>
673
674 <listitem>
675 <para>
676 TM (Time Manager): Handles timers and all aspects of time
677 inside guests.
678 </para>
679 </listitem>
680
681 <listitem>
682 <para>
683 CFGM (Configuration Manager): Provides a tree structure which
684 holds configuration settings for the VM and all emulated
685 devices.
686 </para>
687 </listitem>
688
689 <listitem>
690 <para>
691 SSM (Saved State Manager): Saves and loads VM state.
692 </para>
693 </listitem>
694
695 <listitem>
696 <para>
697 VUSB (Virtual USB): A USB layer which separates emulated USB
698 controllers from the controllers on the host and from USB
699 devices. This component also enables remote USB.
700 </para>
701 </listitem>
702
703 <listitem>
704 <para>
705 DBGF (Debug Facility): A built-in VM debugger.
706 </para>
707 </listitem>
708
709 <listitem>
710 <para>
711 &product-name; emulates a number of devices to provide the
712 hardware environment that various guests need. Most of these
713 are standard devices found in many PC compatible machines and
714 widely supported by guest operating systems. For network and
715 storage devices in particular, there are several options for
716 the emulated devices to access the underlying hardware. These
717 devices are managed by PDM.
718 </para>
719 </listitem>
720
721 <listitem>
722 <para>
723 Guest Additions for various guest operating systems. This is
724 code that is installed from within a virtual machine. See
725 <xref linkend="guestadditions" />.
726 </para>
727 </listitem>
728
729 <listitem>
730 <para>
731 The "Main" component is special. It ties all the above bits
732 together and is the only public API that &product-name;
733 provides. All the client processes listed above use only this
734 API and never access the hypervisor components directly. As a
735 result, third-party applications that use the &product-name;
736 Main API can rely on the fact that it is always well-tested
737 and that all capabilities of &product-name; are fully exposed.
738 It is this API that is described in the &product-name; SDK.
739 See <xref linkend="VirtualBoxAPI" />.
740 </para>
741 </listitem>
742
743 </itemizedlist>
744
745 </sect1>
746
747 <sect1 id="hwvirt">
748
749 <title>Hardware vs. Software Virtualization</title>
750
751 <para>
752 &product-name; enables software in the virtual machine to run
753 directly on the processor of the host, but an array of complex
754 techniques is employed to intercept operations that would
755 interfere with your host. Whenever the guest attempts to do
756 something that could be harmful to your computer and its data,
757 &product-name; steps in and takes action. In particular, for lots
758 of hardware that the guest believes to be accessing,
759 &product-name; simulates a certain "virtual" environment according
760 to how you have configured a virtual machine. For example, when
761 the guest attempts to access a hard disk, &product-name; redirects
762 these requests to whatever you have configured to be the virtual
763 machine's virtual hard disk. This is normally an image file on
764 your host.
765 </para>
766
767 <para>
768 Unfortunately, the x86 platform was never designed to be
769 virtualized. Detecting situations in which &product-name; needs to
770 take control over the guest code that is executing, as described
771 above, is difficult. There are two ways in which to achieve this:
772 </para>
773
774 <itemizedlist>
775
776 <listitem>
777 <para>
778 Since 2006, Intel and AMD processors have had support for
779 so-called <emphasis>hardware virtualization</emphasis>. This
780 means that these processors can help &product-name; to
781 intercept potentially dangerous operations that a guest
782 operating system may be attempting and also makes it easier to
783 present virtual hardware to a virtual machine.
784 </para>
785
786 <para>
787 These hardware features differ between Intel and AMD
788 processors. Intel named its technology >VT-x. AMD calls theirs
789 AMD-V. The Intel and AMD support for virtualization is very
790 different in detail, but not very different in principle.
791 </para>
792
793 <note>
794 <para>
795 On many systems, the hardware virtualization features first
796 need to be enabled in the BIOS before &product-name; can use
797 them.
798 </para>
799 </note>
800 </listitem>
801
802 <listitem>
803 <para>
804 As opposed to other virtualization software, for many usage
805 scenarios, &product-name; does not
806 <emphasis>require</emphasis> hardware virtualization features
807 to be present. Through sophisticated techniques,
808 &product-name; virtualizes many guest operating systems
809 entirely in <emphasis>software</emphasis>. This means that you
810 can run virtual machines even on older processors which do not
811 support hardware virtualization.
812 </para>
813 </listitem>
814
815 </itemizedlist>
816
817 <para>
818 Even though &product-name; does not always require hardware
819 virtualization, enabling it is <emphasis>required</emphasis> in
820 the following scenarios:
821 </para>
822
823 <itemizedlist>
824
825 <listitem>
826 <para>
827 Certain rare guest operating systems like OS/2 make use of
828 very esoteric processor instructions that are not supported
829 with our software virtualization. For virtual machines that
830 are configured to contain such an operating system, hardware
831 virtualization is enabled automatically.
832 </para>
833 </listitem>
834
835 <listitem>
836 <para>
837 &product-name;'s 64-bit guest support, added with version 2.0,
838 and multiprocessing (SMP), added with version 3.0, both
839 require hardware virtualization to be enabled. This is not
840 much of a limitation since the vast majority of today's 64-bit
841 and multicore CPUs ship with hardware virtualization anyway.
842 The exceptions to this rule are older Intel Celeron and AMD
843 Opteron CPUs, for example.
844 </para>
845 </listitem>
846
847 </itemizedlist>
848
849 <warning>
850 <para>
851 Do not run other hypervisors, either open source or commercial
852 virtualization products, together with &product-name;. While
853 several hypervisors can normally be
854 <emphasis>installed</emphasis> in parallel, do not attempt to
855 <emphasis>run</emphasis> several virtual machines from competing
856 hypervisors at the same time. &product-name; cannot track what
857 another hypervisor is currently attempting to do on the same
858 host, and especially if several products attempt to use hardware
859 virtualization features such as VT-x, this can crash the entire
860 host. Also, within &product-name;, you can mix software and
861 hardware virtualization when running multiple VMs. In certain
862 cases a small performance penalty will be unavoidable when
863 mixing VT-x and software virtualization VMs. We recommend not
864 mixing virtualization modes if maximum performance and low
865 overhead are essential. This does <emphasis>not</emphasis> apply
866 to AMD-V.
867 </para>
868 </warning>
869
870 </sect1>
871
872 <sect1 id="gimproviders">
873
874 <title>Paravirtualization Providers</title>
875
876 <para>
877 &product-name; enables the exposure of a paravirtualization
878 interface, to facilitate accurate and efficient execution of
879 software within a virtual machine. These interfaces require the
880 guest operating system to recognize their presence and make use of
881 them in order to leverage the benefits of communicating with the
882 &product-name; hypervisor.
883 </para>
884
885 <para>
886 Most modern mainstream guest operating systems, including Windows
887 and Linux, ship with support for one or more paravirtualization
888 interfaces. Hence, there is typically no need to install
889 additional software in the guest to take advantage of this
890 feature.
891 </para>
892
893 <para>
894 Exposing a paravirtualization provider to the guest operating
895 system does not rely on the choice of host platforms. For example,
896 the <emphasis>Hyper-V</emphasis> paravirtualization provider can
897 be used for VMs to run on any host platform supported by
898 &product-name; and not just Windows.
899 </para>
900
901 <para>
902 &product-name; provides the following interfaces:
903 </para>
904
905 <itemizedlist>
906
907 <listitem>
908 <para>
909 <emphasis role="bold">Minimal</emphasis>: Announces the
910 presence of a virtualized environment. Additionally, reports
911 the TSC and APIC frequency to the guest operating system. This
912 provider is mandatory for running any Mac OS X guests.
913 </para>
914 </listitem>
915
916 <listitem>
917 <para>
918 <emphasis role="bold">KVM</emphasis>: Presents a Linux KVM
919 hypervisor interface which is recognized by Linux kernels
920 version 2.6.25 or later. &product-name;'s implementation
921 currently supports paravirtualized clocks and SMP spinlocks.
922 This provider is recommended for Linux guests.
923 </para>
924 </listitem>
925
926 <listitem>
927 <para>
928 <emphasis role="bold">Hyper-V</emphasis>: Presents a Microsoft
929 Hyper-V hypervisor interface which is recognized by Windows 7
930 and newer operating systems. &product-name;'s implementation
931 currently supports paravirtualized clocks, APIC frequency
932 reporting, guest debugging, guest crash reporting and relaxed
933 timer checks. This provider is recommended for Windows guests.
934 </para>
935 </listitem>
936
937 </itemizedlist>
938
939 </sect1>
940
941 <sect1 id="swvirt-details">
942
943 <title>Details About Software Virtualization</title>
944
945 <para>
946 Implementing virtualization on x86 CPUs with no hardware
947 virtualization support is an extraordinarily complex task because
948 the CPU architecture was not designed to be virtualized. The
949 problems can usually be solved, but at the cost of reduced
950 performance. Thus, there is a constant clash between
951 virtualization performance and accuracy.
952 </para>
953
954 <para>
955 The x86 instruction set was originally designed in the 1970s and
956 underwent significant changes with the addition of protected mode
957 in the 1980s with the 286 CPU architecture and then again with the
958 Intel 386 and its 32-bit architecture. Whereas the 386 did have
959 limited virtualization support for real mode operation with V86
960 mode, as used by the "DOS Box" of Windows 3.x and OS/2 2.x, no
961 support was provided for virtualizing the entire architecture.
962 </para>
963
964 <para>
965 In theory, software virtualization is not overly complex. There
966 are four privilege levels, called <emphasis>rings</emphasis>,
967 provided by the hardware. Typically only two rings are used: ring
968 0 for kernel mode and ring 3 for user mode. Additionally, one
969 needs to differentiate between <emphasis>host context</emphasis>
970 and <emphasis>guest context</emphasis>.
971 </para>
972
973 <para>
974 In host context, everything is as if no hypervisor was active.
975 This might be the active mode if another application on your host
976 has been scheduled CPU time. In that case, there is a host ring 3
977 mode and a host ring 0 mode. The hypervisor is not involved.
978 </para>
979
980 <para>
981 In guest context, however, a virtual machine is active. So long as
982 the guest code is running in ring 3, this is not much of a problem
983 since a hypervisor can set up the page tables properly and run
984 that code natively on the processor. The problems mostly lie in
985 how to intercept what the guest's kernel does.
986 </para>
987
988 <para>
989 There are several possible solutions to these problems. One
990 approach is full software emulation, usually involving
991 recompilation. That is, all code to be run by the guest is
992 analyzed, transformed into a form which will not allow the guest
993 to either modify or see the true state of the CPU, and only then
994 executed. This process is obviously highly complex and costly in
995 terms of performance. &product-name; contains a recompiler based
996 on QEMU which can be used for pure software emulation, but the
997 recompiler is only activated in special situations, described
998 below.
999 </para>
1000
1001 <para>
1002 Another possible solution is paravirtualization, in which only
1003 specially modified guest OSes are allowed to run. This way, most
1004 of the hardware access is abstracted and any functions which would
1005 normally access the hardware or privileged CPU state are passed on
1006 to the hypervisor instead. Paravirtualization can achieve good
1007 functionality and performance on standard x86 CPUs, but it can
1008 only work if the guest OS can actually be modified, which is
1009 obviously not always the case.
1010 </para>
1011
1012 <para>
1013 &product-name; chooses a different approach. When starting a
1014 virtual machine, through its ring-0 support kernel driver,
1015 &product-name; has set up the host system so that it can run most
1016 of the guest code natively, but it has inserted itself at the
1017 "bottom" of the picture. It can then assume control when needed.
1018 If a privileged instruction is executed, the guest traps, in
1019 particular because an I/O register was accessed and a device needs
1020 to be virtualized, or external interrupts occur. &product-name;
1021 may then handle this and either route a request to a virtual
1022 device or possibly delegate handling such things to the guest or
1023 host OS. In guest context, &product-name; can therefore be in one
1024 of three states:
1025 </para>
1026
1027 <itemizedlist>
1028
1029 <listitem>
1030 <para>
1031 Guest ring 3 code is run unmodified, at full speed, as much as
1032 possible. The number of faults will generally be low, unless
1033 the guest allows port I/O from ring 3. This is something we
1034 cannot do as we do not want the guest to be able to access
1035 real ports. This is also referred to as <emphasis>raw
1036 mode</emphasis>, as the guest ring-3 code runs unmodified.
1037 </para>
1038 </listitem>
1039
1040 <listitem>
1041 <para>
1042 For guest code in ring 0, &product-name; employs a clever
1043 trick. It actually reconfigures the guest so that its ring-0
1044 code is run in ring 1 instead, which is normally not used in
1045 x86 operating systems). As a result, when guest ring-0 code,
1046 actually running n ring 1, such as a guest device driver
1047 attempts to write to an I/O register or execute a privileged
1048 instruction, the &product-name; hypervisor in the "real" ring
1049 0 can take over.
1050 </para>
1051 </listitem>
1052
1053 <listitem>
1054 <para>
1055 The hypervisor (VMM) can be active. Every time a fault occurs,
1056 &product-name; looks at the offending instruction and can
1057 relegate it to a virtual device or the host OS or the guest OS
1058 or run it in the recompiler.
1059 </para>
1060
1061 <para>
1062 In particular, the recompiler is used when guest code disables
1063 interrupts and &product-name; cannot figure out when they will
1064 be switched back on. In these situations, &product-name;
1065 actually analyzes the guest code using its own disassembler.
1066 Also, certain privileged instructions such as LIDT need to be
1067 handled specially. Finally, any real-mode or protected-mode
1068 code, such as BIOS code, a DOS guest, or any operating system
1069 startup, is run in the recompiler entirely.
1070 </para>
1071 </listitem>
1072
1073 </itemizedlist>
1074
1075 <para>
1076 Unfortunately this only works to a degree. Among others, the
1077 following situations require special handling:
1078 </para>
1079
1080 <itemizedlist>
1081
1082 <listitem>
1083 <para>
1084 Running ring 0 code in ring 1 causes a lot of additional
1085 instruction faults, as ring 1 is not allowed to execute any
1086 privileged instructions, of which guest's ring-0 contains
1087 plenty. With each of these faults, the VMM must step in and
1088 emulate the code to achieve the desired behavior. While this
1089 works, emulating thousands of these faults is very expensive
1090 and severely hurts the performance of the virtualized guest.
1091 </para>
1092 </listitem>
1093
1094 <listitem>
1095 <para>
1096 There are certain flaws in the implementation of ring 1 in the
1097 x86 architecture that were never fixed. Certain instructions
1098 that <emphasis>should</emphasis> trap in ring 1 do not. This
1099 affects, for example, the LGDT/SGDT, LIDT/SIDT, or POPF/PUSHF
1100 instruction pairs. Whereas the "load" operation is privileged
1101 and can therefore be trapped, the "store" instruction always
1102 succeed. If the guest is allowed to execute these, it will see
1103 the true state of the CPU, not the virtualized state. The
1104 CPUID instruction also has the same problem.
1105 </para>
1106 </listitem>
1107
1108 <listitem>
1109 <para>
1110 A hypervisor typically needs to reserve some portion of the
1111 guest's address space, both linear address space and
1112 selectors, for its own use. This is not entirely transparent
1113 to the guest OS and may cause clashes.
1114 </para>
1115 </listitem>
1116
1117 <listitem>
1118 <para>
1119 The SYSENTER instruction, used for system calls, executed by
1120 an application running in a guest OS always transitions to
1121 ring 0. But that is where the hypervisor runs, not the guest
1122 OS. In this case, the hypervisor must trap and emulate the
1123 instruction even when it is not desirable.
1124 </para>
1125 </listitem>
1126
1127 <listitem>
1128 <para>
1129 The CPU segment registers contain a "hidden" descriptor cache
1130 which is not software-accessible. The hypervisor cannot read,
1131 save, or restore this state, but the guest OS may use it.
1132 </para>
1133 </listitem>
1134
1135 <listitem>
1136 <para>
1137 Some resources must, and can, be trapped by the hypervisor,
1138 but the access is so frequent that this creates a significant
1139 performance overhead. An example is the TPR (Task Priority)
1140 register in 32-bit mode. Accesses to this register must be
1141 trapped by the hypervisor. But certain guest operating
1142 systems, notably Windows and Oracle Solaris, write this
1143 register very often, which adversely affects virtualization
1144 performance.
1145 </para>
1146 </listitem>
1147
1148 </itemizedlist>
1149
1150 <para>
1151 To fix these performance and security issues, &product-name;
1152 contains a Code Scanning and Analysis Manager (CSAM), which
1153 disassembles guest code, and the Patch Manager (PATM), which can
1154 replace it at runtime.
1155 </para>
1156
1157 <para>
1158 Before executing ring 0 code, CSAM scans it recursively to
1159 discover problematic instructions. PATM then performs
1160 <emphasis>in-situ </emphasis>patching. It replaces the instruction
1161 with a jump to hypervisor memory where an integrated code
1162 generator has placed a more suitable implementation. In reality,
1163 this is a very complex task as there are lots of odd situations to
1164 be discovered and handled correctly. So, with its current
1165 complexity, one could argue that PATM is an advanced
1166 <emphasis>in-situ</emphasis> recompiler.
1167 </para>
1168
1169 <para>
1170 In addition, every time a fault occurs, &product-name; analyzes
1171 the offending code to determine if it is possible to patch it in
1172 order to prevent it from causing more faults in the future. This
1173 approach works well in practice and dramatically improves software
1174 virtualization performance.
1175 </para>
1176
1177 </sect1>
1178
1179 <sect1 id="hwvirt-details">
1180
1181 <title>Details About Hardware Virtualization</title>
1182
1183 <para>
1184 With Intel VT-x, there are two distinct modes of CPU operation:
1185 VMX root mode and non-root mode.
1186 </para>
1187
1188 <itemizedlist>
1189
1190 <listitem>
1191 <para>
1192 In root mode, the CPU operates much like older generations of
1193 processors without VT-x support. There are four privilege
1194 levels, called rings, and the same instruction set is
1195 supported, with the addition of several virtualization
1196 specific instruction. Root mode is what a host operating
1197 system without virtualization uses, and it is also used by a
1198 hypervisor when virtualization is active.
1199 </para>
1200 </listitem>
1201
1202 <listitem>
1203 <para>
1204 In non-root mode, CPU operation is significantly different.
1205 There are still four privilege rings and the same instruction
1206 set, but a new structure called VMCS (Virtual Machine Control
1207 Structure) now controls the CPU operation and determines how
1208 certain instructions behave. Non-root mode is where guest
1209 systems run.
1210 </para>
1211 </listitem>
1212
1213 </itemizedlist>
1214
1215 <para>
1216 Switching from root mode to non-root mode is called "VM entry",
1217 the switch back is "VM exit". The VMCS includes a guest and host
1218 state area which is saved/restored at VM entry and exit. Most
1219 importantly, the VMCS controls which guest operations will cause
1220 VM exits.
1221 </para>
1222
1223 <para>
1224 The VMCS provides fairly fine-grained control over what the guests
1225 can and cannot do. For example, a hypervisor can allow a guest to
1226 write certain bits in shadowed control registers, but not others.
1227 This enables efficient virtualization in cases where guests can be
1228 allowed to write control bits without disrupting the hypervisor,
1229 while preventing them from altering control bits over which the
1230 hypervisor needs to retain full control. The VMCS also provides
1231 control over interrupt delivery and exceptions.
1232 </para>
1233
1234 <para>
1235 Whenever an instruction or event causes a VM exit, the VMCS
1236 contains information about the exit reason, often with
1237 accompanying detail. For example, if a write to the CR0 register
1238 causes an exit, the offending instruction is recorded, along with
1239 the fact that a write access to a control register caused the
1240 exit, and information about source and destination register. Thus
1241 the hypervisor can efficiently handle the condition without
1242 needing advanced techniques such as CSAM and PATM described above.
1243 </para>
1244
1245 <para>
1246 VT-x inherently avoids several of the problems which software
1247 virtualization faces. The guest has its own completely separate
1248 address space not shared with the hypervisor, which eliminates
1249 potential clashes. Additionally, guest OS kernel code runs at
1250 privilege ring 0 in VMX non-root mode, obviating the problems by
1251 running ring 0 code at less privileged levels. For example the
1252 SYSENTER instruction can transition to ring 0 without causing
1253 problems. Naturally, even at ring 0 in VMX non-root mode, any I/O
1254 access by guest code still causes a VM exit, allowing for device
1255 emulation.
1256 </para>
1257
1258 <para>
1259 The biggest difference between VT-x and AMD-V is that AMD-V
1260 provides a more complete virtualization environment. VT-x requires
1261 the VMX non-root code to run with paging enabled, which precludes
1262 hardware virtualization of real-mode code and non-paged
1263 protected-mode software. This typically only includes firmware and
1264 OS loaders, but nevertheless complicates VT-x hypervisor
1265 implementation. AMD-V does not have this restriction.
1266 </para>
1267
1268 <para>
1269 Of course hardware virtualization is not perfect. Compared to
1270 software virtualization, the overhead of VM exits is relatively
1271 high. This causes problems for devices whose emulation requires
1272 high number of traps. One example is the VGA device in 16-color
1273 modes, where not only every I/O port access but also every access
1274 to the framebuffer memory must be trapped.
1275 </para>
1276
1277 </sect1>
1278
1279 <sect1 id="nestedpaging">
1280
1281 <title>Nested Paging and VPIDs</title>
1282
1283 <para>
1284 In addition to normal hardware virtualization, your processor may
1285 also support the following additional sophisticated techniques:
1286 </para>
1287
1288 <itemizedlist>
1289
1290 <listitem>
1291 <para>
1292 Nested paging implements some memory management in hardware,
1293 which can greatly accelerate hardware virtualization since
1294 these tasks no longer need to be performed by the
1295 virtualization software.
1296 </para>
1297
1298 <para>
1299 With nested paging, the hardware provides another level of
1300 indirection when translating linear to physical addresses.
1301 Page tables function as before, but linear addresses are now
1302 translated to "guest physical" addresses first and not
1303 physical addresses directly. A new set of paging registers now
1304 exists under the traditional paging mechanism and translates
1305 from guest physical addresses to host physical addresses,
1306 which are used to access memory.
1307 </para>
1308
1309 <para>
1310 Nested paging eliminates the overhead caused by VM exits and
1311 page table accesses. In essence, with nested page tables the
1312 guest can handle paging without intervention from the
1313 hypervisor. Nested paging thus significantly improves
1314 virtualization performance.
1315 </para>
1316
1317 <para>
1318 On AMD processors, nested paging has been available starting
1319 with the Barcelona (K10) architecture. They now call it rapid
1320 virtualization indexing (RVI). Intel added support for nested
1321 paging, which they call extended page tables (EPT), with their
1322 Core i7 (Nehalem) processors.
1323 </para>
1324
1325 <para>
1326 If nested paging is enabled, the &product-name; hypervisor can
1327 also use <emphasis>large pages</emphasis> to reduce TLB usage
1328 and overhead. This can yield a performance improvement of up
1329 to 5%. To enable this feature for a VM, you use the
1330 <computeroutput>VBoxManage modifyvm
1331 --largepages</computeroutput> command. See
1332 <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 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>
Note: See TracBrowser for help on using the repository browser.

© 2024 Oracle Support Privacy / Do Not Sell My Info Terms of Use Trademark Policy Automated Access Etiquette