VirtualBox

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

最後變更 在這個檔案從58485是 58485,由 vboxsync 提交於 9 年 前

doc/manual: typos, spaces.

檔案大小: 46.0 KB
 
1<?xml version="1.0" encoding="UTF-8"?>
2<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
3"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">
4<chapter id="TechnicalBackground">
5 <title>Technical background</title>
6
7 <para>The contents of this chapter are not required to use VirtualBox
8 successfully. The following is provided as additional information for
9 readers who are more familiar with computer architecture and technology and
10 wish to find out more about how VirtualBox works "under the hood".</para>
11
12 <sect1 id="vboxconfigdata">
13 <title>Where VirtualBox stores its files</title>
14
15 <para>In VirtualBox, a virtual machine and its settings are described in a
16 virtual machine settings file in XML format. In addition, most virtual
17 machine have one or more virtual hard disks, which are typically
18 represented by disk images (e.g. in VDI format). Where all these files are
19 stored depends on which version of VirtualBox created the machine.</para>
20
21 <sect2>
22 <title>Machines created by VirtualBox version 4.0 or later</title>
23
24 <para>Starting with version 4.0, by default, each virtual machine has
25 one directory on your host computer where all the files of that machine
26 are stored -- the XML settings file (with a
27 <computeroutput>.vbox</computeroutput> file extension) and its disk
28 images.</para>
29
30 <para>By default, this "machine folder" is placed in a common folder
31 called "VirtualBox VMs", which VirtualBox creates in the current system
32 user's home directory. The location of this home directory depends on
33 the conventions of the host operating system:</para>
34
35 <itemizedlist>
36 <listitem>
37 <para>On Windows, this is
38 <computeroutput>%HOMEDRIVE%%HOMEPATH%</computeroutput>; typically
39 something like <computeroutput>C:\Documents and
40 Settings\Username\</computeroutput>.</para>
41 </listitem>
42
43 <listitem>
44 <para>On Mac OS X, this is
45 <computeroutput>/Users/username</computeroutput>.</para>
46 </listitem>
47
48 <listitem>
49 <para>On Linux and Solaris, this is
50 <computeroutput>/home/username</computeroutput>.</para>
51 </listitem>
52 </itemizedlist>
53
54 <para>For simplicity, we will abbreviate this as
55 <computeroutput>$HOME</computeroutput> below. Using that convention, the
56 common folder for all virtual machines is
57 <computeroutput>$HOME/VirtualBox VMs</computeroutput>.</para>
58
59 <para>As an example, when you create a virtual machine called "Example
60 VM", you will find that VirtualBox creates<orderedlist>
61 <listitem>
62 <para>the folder <computeroutput>$HOME/VirtualBox VMs/Example
63 VM/</computeroutput> and, in that folder,</para>
64 </listitem>
65
66 <listitem>
67 <para>the settings file <computeroutput>Example
68 VM.vbox</computeroutput> and</para>
69 </listitem>
70
71 <listitem>
72 <para>the virtual disk image <computeroutput>Example
73 VM.vdi</computeroutput>.</para>
74 </listitem>
75 </orderedlist></para>
76
77 <para>This is the default layout if you use the "Create new virtual
78 machine" wizard as described in <xref linkend="gui-createvm" />. Once
79 you start working with the VM, additional files will show up: you will
80 find log files in a subfolder called
81 <computeroutput>Logs</computeroutput>, and once you have taken
82 snapshots, they will appear in a
83 <computeroutput>Snapshots</computeroutput> subfolder. For each VM, you
84 can change the location of its snapshots folder in the VM
85 settings.</para>
86
87 <para>You can change the default machine folder by selecting
88 "Preferences" from the "File" menu in the VirtualBox main window. Then,
89 in the window that pops up, click on the "General" tab. Alternatively,
90 use <computeroutput>VBoxManage setproperty
91 machinefolder</computeroutput>; see <xref
92 linkend="vboxmanage-setproperty" />.</para>
93 </sect2>
94
95 <sect2>
96 <title>Machines created by VirtualBox versions before 4.0</title>
97
98 <para>If you have upgraded to VirtualBox 4.0 from an earlier version of
99 VirtualBox, you probably have settings files and disks in the earlier
100 file system layout.</para>
101
102 <para>Before version 4.0, VirtualBox separated the machine settings
103 files from virtual disk images. The machine settings files had an
104 <computeroutput>.xml</computeroutput> file extension and resided in a
105 folder called "Machines" under the global VirtualBox configuration
106 directory (see the next section). So, for example, on Linux, this was
107 the hidden <computeroutput>$HOME/.VirtualBox/Machines</computeroutput>
108 directory. The default hard disks folder was called "HardDisks" and
109 resided in the <computeroutput>.VirtualBox</computeroutput> folder as
110 well. Both locations could be changed by the user in the global
111 preferences. (The concept of a "default hard disk folder" has been
112 abandoned with VirtualBox 4.0, since disk images now reside in each
113 machine's folder by default.)</para>
114
115 <para>The old layout had several severe disadvantages.<orderedlist>
116 <listitem>
117 <para>It was very difficult to move a virtual machine from one
118 host to another because the files involved did not reside in the
119 same folder. In addition, the virtual media of all machines were
120 registered with a global registry in the central VirtualBox
121 settings file
122 (<computeroutput>$HOME/.VirtualBox/VirtualBox.xml</computeroutput>).</para>
123
124 <para>To move a machine to another host, it was therefore not
125 enough to move the XML settings file and the disk images (which
126 were in different locations), but the hard disk entries from the
127 global media registry XML had to be meticulously copied as well,
128 which was close to impossible if the machine had snapshots and
129 therefore differencing images.</para>
130 </listitem>
131
132 <listitem>
133 <para>Storing virtual disk images, which can grow very large,
134 under the hidden <computeroutput>.VirtualBox</computeroutput>
135 directory (at least on Linux and Solaris hosts) made many users
136 wonder where their disk space had gone.</para>
137 </listitem>
138 </orderedlist></para>
139
140 <para>Whereas new VMs created with VirtualBox 4.0 or later will conform
141 to the new layout, for maximum compatibility, old VMs are
142 <emphasis>not</emphasis> converted to the new layout. Otherwise machine
143 settings would be irrevocably broken if a user downgraded from 4.0 back
144 to an older version of VirtualBox.</para>
145 </sect2>
146
147 <sect2>
148 <title>Global configuration data</title>
149
150 <para>In addition to the files of the virtual machines, VirtualBox
151 maintains global configuration data. On Linux and Solaris as of VirtualBox 4.3, this
152 is in the hidden directory <computeroutput>$HOME/.config/VirtualBox</computeroutput>, although <computeroutput>$HOME/.VirtualBox</computeroutput> will be used if it exists for compatibility with earlier versions; on Windows (and on Linux and Solaris with VirtualBox 4.2 and earlier) this is in <computeroutput>$HOME/.VirtualBox</computeroutput>; on a Mac it resides in
153 <computeroutput>$HOME/Library/VirtualBox</computeroutput>.</para>
154
155 <para>VirtualBox creates this configuration directory automatically if
156 necessary. Optionally, you can supply an alternate configuration
157 directory by setting the
158 <computeroutput><literal>VBOX_USER_HOME</literal></computeroutput>
159 environment variable, or additionally on Linux or Solaris by using the standard <computeroutput><literal>XDG_CONFIG_HOME</literal></computeroutput> variable. (Since the global
160 <computeroutput>VirtualBox.xml</computeroutput> settings file points to
161 all other configuration files, this allows for switching between several
162 VirtualBox configurations entirely.)</para>
163
164 <para>Most importantly, in this directory, VirtualBox stores its global
165 settings file, another XML file called
166 <computeroutput>VirtualBox.xml</computeroutput>. This includes global
167 configuration options and the list of registered virtual machines with
168 pointers to their XML settings files. (Neither the location of this file
169 nor its directory has changed with VirtualBox 4.0.)</para>
170
171 <para>Before VirtualBox 4.0, all virtual media (disk image files) were
172 also contained in a global registry in this settings file. For
173 compatibility, this media registry still exists if you upgrade
174 VirtualBox and there are media from machines which were created with a
175 version before 4.0. If you have no such machines, then there will be no
176 global media registry; with VirtualBox 4.0, each machine XML file has
177 its own media registry.</para>
178
179 <para>Also before VirtualBox 4.0, the default "Machines" folder and the
180 default "HardDisks" folder resided under the VirtualBox configuration
181 directory (e.g.
182 <computeroutput>$HOME/.VirtualBox/Machines</computeroutput> on Linux).
183 If you are upgrading from a VirtualBox version before 4.0, files in
184 these directories are not automatically moved in order not to break
185 backwards compatibility.</para>
186 </sect2>
187
188 <sect2>
189 <title>Summary of 4.0 configuration changes</title>
190
191 <para>The following table gives a brief overview of the configuration
192 changes between older versions and version 4.0 or above:</para>
193
194 <table>
195 <title>Configuration changes in version 4.0 or above</title>
196
197 <tgroup cols="3">
198 <thead>
199 <row>
200 <entry><emphasis role="bold">Setting</emphasis></entry>
201
202 <entry><emphasis role="bold">Before 4.0</emphasis></entry>
203
204 <entry><emphasis role="bold">4.0 or above</emphasis></entry>
205 </row>
206 </thead>
207 <tbody>
208 <row>
209 <entry>Default machines folder</entry>
210
211 <entry><computeroutput>$HOME/.VirtualBox/Machines</computeroutput></entry>
212
213 <entry><computeroutput>$HOME/VirtualBox
214 VMs</computeroutput></entry>
215 </row>
216
217 <row>
218 <entry>Default disk image location</entry>
219
220 <entry><computeroutput>$HOME/.VirtualBox/HardDisks</computeroutput></entry>
221
222 <entry>In each machine's folder</entry>
223 </row>
224
225 <row>
226 <entry>Machine settings file extension</entry>
227
228 <entry><computeroutput>.xml</computeroutput></entry>
229
230 <entry><computeroutput>.vbox</computeroutput></entry>
231 </row>
232
233 <row>
234 <entry>Media registry</entry>
235
236 <entry>Global <computeroutput>VirtualBox.xml</computeroutput>
237 file</entry>
238
239 <entry>Each machine settings file</entry>
240 </row>
241
242 <row>
243 <entry>Media registration</entry>
244
245 <entry>Explicit open/close required</entry>
246
247 <entry>Automatic on attach</entry>
248 </row>
249 </tbody>
250 </tgroup>
251 </table>
252 </sect2>
253
254 <sect2>
255 <title>VirtualBox XML files</title>
256
257 <para>VirtualBox uses XML for both the machine settings files and the
258 global configuration file,
259 <computeroutput>VirtualBox.xml</computeroutput>.</para>
260
261 <para>All VirtualBox XML files are versioned. When a new settings file
262 is created (e.g. because a new virtual machine is created), VirtualBox
263 automatically uses the settings format of the current VirtualBox
264 version. These files may not be readable if you downgrade to an earlier
265 version of VirtualBox. However, when VirtualBox encounters a settings
266 file from an earlier version (e.g. after upgrading VirtualBox), it
267 attempts to preserve the settings format as much as possible. It will
268 only silently upgrade the settings format if the current settings cannot
269 be expressed in the old format, for example because you enabled a
270 feature that was not present in an earlier version of
271 VirtualBox.<footnote>
272 <para>As an example, before VirtualBox 3.1, it was only possible to
273 enable or disable a single DVD drive in a virtual machine. If it was
274 enabled, then it would always be visible as the secondary master of
275 the IDE controller. With VirtualBox 3.1, DVD drives can be attached
276 to arbitrary slots of arbitrary controllers, so they could be the
277 secondary slave of an IDE controller or in a SATA slot. If you have
278 a machine settings file from an earlier version and upgrade
279 VirtualBox to 3.1 and then move the DVD drive from its default
280 position, this cannot be expressed in the old settings format; the
281 XML machine file would get written in the new format, and a backup
282 file of the old format would be kept.</para>
283 </footnote> In such cases, VirtualBox backs up the old settings file
284 in the virtual machine's configuration directory. If you need to go back
285 to the earlier version of VirtualBox, then you will need to manually
286 copy these backup files back.</para>
287
288 <para>We intentionally do not document the specifications of the
289 VirtualBox XML files, as we must reserve the right to modify them in the
290 future. We therefore strongly suggest that you do not edit these files
291 manually. VirtualBox provides complete access to its configuration data
292 through its the <computeroutput>VBoxManage</computeroutput> command line
293 tool (see <xref linkend="vboxmanage" />) and its API (see <xref
294 linkend="VirtualBoxAPI" />).</para>
295 </sect2>
296 </sect1>
297
298 <sect1 id="technical-components">
299 <title>VirtualBox executables and components</title>
300
301 <para>VirtualBox was designed to be modular and flexible. When the
302 VirtualBox graphical user interface (GUI) is opened and a VM is started,
303 at least three processes are running:<orderedlist>
304 <listitem>
305 <para><computeroutput>VBoxSVC</computeroutput>, the VirtualBox
306 service process which always runs in the background. This process is
307 started automatically by the first VirtualBox client process (the
308 GUI, <computeroutput>VBoxManage</computeroutput>,
309 <computeroutput>VBoxHeadless</computeroutput>, the web service or
310 others) and exits a short time after the last client exits. The
311 service is responsible for bookkeeping, maintaining the state of all
312 VMs, and for providing communication between VirtualBox components.
313 This communication is implemented via COM/XPCOM.<note>
314 <para>When we refer to "clients" here, we mean the local clients
315 of a particular <computeroutput>VBoxSVC</computeroutput> server
316 process, not clients in a network. VirtualBox employs its own
317 client/server design to allow its processes to cooperate, but
318 all these processes run under the same user account on the host
319 operating system, and this is totally transparent to the
320 user.</para>
321 </note></para>
322 </listitem>
323
324 <listitem>
325 <para>The GUI process, <computeroutput>VirtualBox</computeroutput>,
326 a client application based on the cross-platform Qt library. When
327 started without the <computeroutput>--startvm</computeroutput>
328 option, this application acts as the VirtualBox manager, displaying
329 the VMs and their settings. It then communicates settings and state
330 changes to <computeroutput>VBoxSVC</computeroutput> and also
331 reflects changes effected through other means, e.g.,
332 <computeroutput>VBoxManage</computeroutput>.</para>
333 </listitem>
334
335 <listitem>
336 <para>If the <computeroutput>VirtualBox</computeroutput> client
337 application is started with the
338 <computeroutput>--startvm</computeroutput> argument, it loads the
339 VMM library which includes the actual hypervisor and then runs a
340 virtual machine and provides the input and output for the
341 guest.</para>
342 </listitem>
343 </orderedlist></para>
344
345 <para>Any VirtualBox front-end (client) will communicate with the service
346 process and can both control and reflect the current state. For example,
347 either the VM selector or the VM window or VBoxManage can be used to pause
348 the running VM, and other components will always reflect the changed
349 state.</para>
350
351 <para>The VirtualBox GUI application is only one of several available
352 front ends (clients). The complete list shipped with VirtualBox
353 is:<orderedlist>
354 <listitem>
355 <para><computeroutput>VirtualBox</computeroutput>, the Qt front end
356 implementing the manager and running VMs;</para>
357 </listitem>
358
359 <listitem>
360 <para><computeroutput>VBoxManage</computeroutput>, a less
361 user-friendly but more powerful alternative, described in <xref
362 linkend="vboxmanage" />.</para>
363 </listitem>
364
365 <listitem>
366 <para><computeroutput>VBoxSDL</computeroutput>, a simple graphical
367 front end based on the SDL library; see <xref
368 linkend="vboxsdl" />.</para>
369 </listitem>
370
371 <listitem>
372 <para><computeroutput>VBoxHeadless</computeroutput>, a VM front end
373 which does not directly provide any video output and keyboard/mouse
374 input, but allows redirection via VirtualBox Remote Desktop Extension;
375 see <xref linkend="vboxheadless" />.</para>
376 </listitem>
377
378 <listitem>
379 <para><computeroutput>vboxwebsrv</computeroutput>, the VirtualBox
380 web service process which allows for controlling a VirtualBox host
381 remotely. This is described in detail in the VirtualBox Software
382 Development Kit (SDK) reference; please see <xref
383 linkend="VirtualBoxAPI" /> for details.</para>
384 </listitem>
385
386 <listitem>
387 <para>The VirtualBox Python shell, a Python alternative to
388 VBoxManage. This is also described in the SDK reference.</para>
389 </listitem>
390 </orderedlist></para>
391
392 <para>Internally, VirtualBox consists of many more or less separate
393 components. You may encounter these when analyzing VirtualBox internal
394 error messages or log files. These include:</para>
395
396 <itemizedlist>
397 <listitem>
398 <para>IPRT, a portable runtime library which abstracts file access,
399 threading, string manipulation, etc. Whenever VirtualBox accesses host
400 operating features, it does so through this library for cross-platform
401 portability.</para>
402 </listitem>
403
404 <listitem>
405 <para>VMM (Virtual Machine Monitor), the heart of the
406 hypervisor.</para>
407 </listitem>
408
409 <listitem>
410 <para>EM (Execution Manager), controls execution of guest code.</para>
411 </listitem>
412
413 <listitem>
414 <para>REM (Recompiled Execution Monitor), provides software emulation
415 of CPU instructions.</para>
416 </listitem>
417
418 <listitem>
419 <para>TRPM (Trap Manager), intercepts and processes guest traps and
420 exceptions.</para>
421 </listitem>
422
423 <listitem>
424 <para>HM (Hardware Acceleration Manager), provides support for VT-x
425 and AMD-V.</para>
426 </listitem>
427
428 <listitem>
429 <para>GIM (Guest Interface Manager), provides support for various
430 paravirtualization interfaces to the guest.</para>
431 </listitem>
432
433 <listitem>
434 <para>PDM (Pluggable Device Manager), an abstract interface between
435 the VMM and emulated devices which separates device implementations
436 from VMM internals and makes it easy to add new emulated devices.
437 Through PDM, third-party developers can add new virtual devices to
438 VirtualBox without having to change VirtualBox itself.</para>
439 </listitem>
440
441 <listitem>
442 <para>PGM (Page Manager), a component controlling guest paging.</para>
443 </listitem>
444
445 <listitem>
446 <para>PATM (Patch Manager), patches guest code to improve and speed up
447 software virtualization.</para>
448 </listitem>
449
450 <listitem>
451 <para>TM (Time Manager), handles timers and all aspects of time inside
452 guests.</para>
453 </listitem>
454
455 <listitem>
456 <para>CFGM (Configuration Manager), provides a tree structure which
457 holds configuration settings for the VM and all emulated
458 devices.</para>
459 </listitem>
460
461 <listitem>
462 <para>SSM (Saved State Manager), saves and loads VM state.</para>
463 </listitem>
464
465 <listitem>
466 <para>VUSB (Virtual USB), a USB layer which separates emulated USB
467 controllers from the controllers on the host and from USB devices;
468 this also enables remote USB.</para>
469 </listitem>
470
471 <listitem>
472 <para>DBGF (Debug Facility), a built-in VM debugger.</para>
473 </listitem>
474
475 <listitem>
476 <para>VirtualBox emulates a number of devices to provide the hardware
477 environment that various guests need. Most of these are standard
478 devices found in many PC compatible machines and widely supported by
479 guest operating systems. For network and storage devices in
480 particular, there are several options for the emulated devices to
481 access the underlying hardware. These devices are managed by
482 PDM.</para>
483 </listitem>
484
485 <listitem>
486 <para>Guest Additions for various guest operating systems. This is
487 code that is installed from within a virtual machine; see <xref
488 linkend="guestadditions" />.</para>
489 </listitem>
490
491 <listitem>
492 <para>The "Main" component is special: it ties all the above bits
493 together and is the only public API that VirtualBox provides. All the
494 client processes listed above use only this API and never access the
495 hypervisor components directly. As a result, third-party applications
496 that use the VirtualBox Main API can rely on the fact that it is
497 always well-tested and that all capabilities of VirtualBox are fully
498 exposed. It is this API that is described in the VirtualBox SDK
499 mentioned above (again, see <xref linkend="VirtualBoxAPI" />).</para>
500 </listitem>
501 </itemizedlist>
502 </sect1>
503
504 <sect1 id="hwvirt">
505 <title>Hardware vs. software virtualization</title>
506
507 <para>VirtualBox allows software in the virtual machine to run directly on
508 the processor of the host, but an array of complex techniques is employed
509 to intercept operations that would interfere with your host. Whenever the
510 guest attempts to do something that could be harmful to your computer and
511 its data, VirtualBox steps in and takes action. In particular, for lots of
512 hardware that the guest believes to be accessing, VirtualBox simulates a
513 certain "virtual" environment according to how you have configured a
514 virtual machine. For example, when the guest attempts to access a hard
515 disk, VirtualBox redirects these requests to whatever you have configured
516 to be the virtual machine's virtual hard disk -- normally, an image file
517 on your host.</para>
518
519 <para>Unfortunately, the x86 platform was never designed to be
520 virtualized. Detecting situations in which VirtualBox needs to take
521 control over the guest code that is executing, as described above, is
522 difficult. There are two ways in which to achieve this:<itemizedlist>
523 <listitem>
524 <para>Since 2006, Intel and AMD processors have had support for
525 so-called <emphasis role="bold">"hardware
526 virtualization"</emphasis>. This means that these processors can
527 help VirtualBox to intercept potentially dangerous operations that a
528 guest operating system may be attempting and also makes it easier to
529 present virtual hardware to a virtual machine.</para>
530
531 <para>These hardware features differ between Intel and AMD
532 processors. Intel named its technology <emphasis
533 role="bold">VT-x</emphasis>; AMD calls theirs <emphasis
534 role="bold">AMD-V</emphasis>. The Intel and AMD support for
535 virtualization is very different in detail, but not very different
536 in principle.<note>
537 <para>On many systems, the hardware virtualization features
538 first need to be enabled in the BIOS before VirtualBox can use
539 them.</para>
540 </note></para>
541 </listitem>
542
543 <listitem>
544 <para>As opposed to other virtualization software, for many usage
545 scenarios, VirtualBox does not <emphasis>require</emphasis> hardware
546 virtualization features to be present. Through sophisticated
547 techniques, VirtualBox virtualizes many guest operating systems
548 entirely in <emphasis role="bold">software</emphasis>. This means
549 that you can run virtual machines even on older processors which do
550 not support hardware virtualization.</para>
551 </listitem>
552 </itemizedlist></para>
553
554 <para>Even though VirtualBox does not always require hardware
555 virtualization, enabling it is <emphasis>required</emphasis> in the
556 following scenarios:<itemizedlist>
557 <listitem>
558 <para>Certain rare guest operating systems like OS/2 make use of
559 very esoteric processor instructions that are not supported with our
560 software virtualization. For virtual machines that are configured to
561 contain such an operating system, hardware virtualization is enabled
562 automatically.</para>
563 </listitem>
564
565 <listitem>
566 <para>VirtualBox's 64-bit guest support (added with version 2.0) and
567 multiprocessing (SMP, added with version 3.0) both require hardware
568 virtualization to be enabled. (This is not much of a limitation
569 since the vast majority of today's 64-bit and multicore CPUs ship
570 with hardware virtualization anyway; the exceptions to this rule are
571 e.g. older Intel Celeron and AMD Opteron CPUs.)</para>
572 </listitem>
573 </itemizedlist></para>
574
575 <warning>
576 <para>Do not run other hypervisors (open-source or commercial
577 virtualization products) together with VirtualBox! While several
578 hypervisors can normally be <emphasis>installed</emphasis> in parallel,
579 do not attempt to <emphasis>run</emphasis> several virtual machines from
580 competing hypervisors at the same time. VirtualBox cannot track what
581 another hypervisor is currently attempting to do on the same host, and
582 especially if several products attempt to use hardware virtualization
583 features such as VT-x, this can crash the entire host. Also, within
584 VirtualBox, you can mix software and hardware virtualization when
585 running multiple VMs. In certain cases a small performance penalty will
586 be unavoidable when mixing VT-x and software virtualization VMs. We
587 recommend not mixing virtualization modes if maximum performance and low
588 overhead are essential. This does <emphasis>not</emphasis> apply to
589 AMD-V.</para>
590 </warning>
591 </sect1>
592
593 <sect1 id="gimproviders">
594 <title>Paravirtualization providers</title>
595
596 <para>VirtualBox allows exposing a paravirtualization interface to
597 facilitate accurate and efficient execution of software within a
598 virtual machine. These interfaces require the guest operating system
599 to recognize their presence and make use of them in order to leverage
600 the benefits of communicating with the VirtualBox hypervisor.</para>
601
602 <para>Most mainstream, modern guest operating systems, including Windows
603 and Linux, ship with support for one or more paravirtualization interfaces.
604 Hence, there is typically no need to install additional software in the
605 guest (including VirtualBox Guest Additions) to make use of this
606 feature.</para>
607
608 <para>Exposing a paravirtualization provider to the guest operating
609 system does not rely on the choice of host platforms. For example, the
610 <emphasis>Hyper-V</emphasis> paravirtualization provider can be
611 used for VMs to run on any host platform (supported by VirtualBox) and
612 not just Windows.</para>
613
614 <para>VirtualBox provides the following interfaces:</para>
615 <itemizedlist>
616 <listitem>
617 <para><emphasis role="bold">Minimal</emphasis>: Announces the
618 presence of a virtualized environment. Additionally, reports the
619 TSC and APIC frequency to the guest operating system. This provider
620 is mandatory for running any Mac OS X guests.</para>
621 </listitem>
622
623 <listitem>
624 <para><emphasis role="bold">KVM</emphasis>: Presents a Linux KVM
625 hypervisor interface which is recognized by Linux kernels starting
626 with version 2.6.25. VirtualBox's implementation currently supports
627 paravirtualized clocks and SMP spinlocks. This provider is
628 recommended for Linux guests.</para>
629 </listitem>
630
631 <listitem>
632 <para><emphasis role="bold">Hyper-V</emphasis>: Presents a Microsoft
633 Hyper-V hypervisor interface which is recognized by Windows 7 and newer
634 operating systems. VirtualBox's implementation currently supports
635 paravirtualized clocks, APIC frequency reporting, guest crash reporting
636 and relaxed timer checks. This provider is recommended for Windows
637 guests.
638 </para>
639 </listitem>
640 </itemizedlist>
641 </sect1>
642
643 <sect1>
644 <title>Details about software virtualization</title>
645
646 <para>Implementing virtualization on x86 CPUs with no hardware
647 virtualization support is an extraordinarily complex task because the CPU
648 architecture was not designed to be virtualized. The problems can usually
649 be solved, but at the cost of reduced performance. Thus, there is a
650 constant clash between virtualization performance and accuracy.</para>
651
652 <para>The x86 instruction set was originally designed in the 1970s and
653 underwent significant changes with the addition of protected mode in the
654 1980s with the 286 CPU architecture and then again with the Intel 386 and
655 its 32-bit architecture. Whereas the 386 did have limited virtualization
656 support for real mode operation (V86 mode, as used by the "DOS Box" of
657 Windows 3.x and OS/2 2.x), no support was provided for virtualizing the
658 entire architecture.</para>
659
660 <para>In theory, software virtualization is not overly complex. In
661 addition to the four privilege levels ("rings") provided by the hardware
662 (of which typically only two are used: ring 0 for kernel mode and ring 3
663 for user mode), one needs to differentiate between "host context" and
664 "guest context".</para>
665
666 <para>In "host context", everything is as if no hypervisor was active.
667 This might be the active mode if another application on your host has been
668 scheduled CPU time; in that case, there is a host ring 3 mode and a host
669 ring 0 mode. The hypervisor is not involved.</para>
670
671 <para>In "guest context", however, a virtual machine is active. So long as
672 the guest code is running in ring 3, this is not much of a problem since a
673 hypervisor can set up the page tables properly and run that code natively
674 on the processor. The problems mostly lie in how to intercept what the
675 guest's kernel does.</para>
676
677 <para>There are several possible solutions to these problems. One approach
678 is full software emulation, usually involving recompilation. That is, all
679 code to be run by the guest is analyzed, transformed into a form which
680 will not allow the guest to either modify or see the true state of the
681 CPU, and only then executed. This process is obviously highly complex and
682 costly in terms of performance. (VirtualBox contains a recompiler based on
683 QEMU which can be used for pure software emulation, but the recompiler is
684 only activated in special situations, described below.)</para>
685
686 <para>Another possible solution is paravirtualization, in which only
687 specially modified guest OSes are allowed to run. This way, most of the
688 hardware access is abstracted and any functions which would normally
689 access the hardware or privileged CPU state are passed on to the
690 hypervisor instead. Paravirtualization can achieve good functionality and
691 performance on standard x86 CPUs, but it can only work if the guest OS can
692 actually be modified, which is obviously not always the case.</para>
693
694 <para>VirtualBox chooses a different approach. When starting a virtual
695 machine, through its ring-0 support kernel driver, VirtualBox has set up
696 the host system so that it can run most of the guest code natively, but it
697 has inserted itself at the "bottom" of the picture. It can then assume
698 control when needed -- if a privileged instruction is executed, the guest
699 traps (in particular because an I/O register was accessed and a device
700 needs to be virtualized) or external interrupts occur. VirtualBox may then
701 handle this and either route a request to a virtual device or possibly
702 delegate handling such things to the guest or host OS. In guest context,
703 VirtualBox can therefore be in one of three states:</para>
704
705 <para><itemizedlist>
706 <listitem>
707 <para>Guest ring 3 code is run unmodified, at full speed, as much as
708 possible. The number of faults will generally be low (unless the
709 guest allows port I/O from ring 3, something we cannot do as we
710 don't want the guest to be able to access real ports). This is also
711 referred to as "raw mode", as the guest ring-3 code runs
712 unmodified.</para>
713 </listitem>
714
715 <listitem>
716 <para>For guest code in ring 0, VirtualBox employs a nasty trick: it
717 actually reconfigures the guest so that its ring-0 code is run in
718 ring 1 instead (which is normally not used in x86 operating
719 systems). As a result, when guest ring-0 code (actually running in
720 ring 1) such as a guest device driver attempts to write to an I/O
721 register or execute a privileged instruction, the VirtualBox
722 hypervisor in "real" ring 0 can take over.</para>
723 </listitem>
724
725 <listitem>
726 <para>The hypervisor (VMM) can be active. Every time a fault occurs,
727 VirtualBox looks at the offending instruction and can relegate it to
728 a virtual device or the host OS or the guest OS or run it in the
729 recompiler.</para>
730
731 <para>In particular, the recompiler is used when guest code disables
732 interrupts and VirtualBox cannot figure out when they will be
733 switched back on (in these situations, VirtualBox actually analyzes
734 the guest code using its own disassembler). Also, certain privileged
735 instructions such as LIDT need to be handled specially. Finally, any
736 real-mode or protected-mode code (e.g. BIOS code, a DOS guest, or
737 any operating system startup) is run in the recompiler
738 entirely.</para>
739 </listitem>
740 </itemizedlist></para>
741
742 <para>Unfortunately this only works to a degree. Among others, the
743 following situations require special handling:</para>
744
745 <para><orderedlist>
746 <listitem>
747 <para>Running ring 0 code in ring 1 causes a lot of additional
748 instruction faults, as ring 1 is not allowed to execute any
749 privileged instructions (of which guest's ring-0 contains plenty).
750 With each of these faults, the VMM must step in and emulate the code
751 to achieve the desired behavior. While this works, emulating
752 thousands of these faults is very expensive and severely hurts the
753 performance of the virtualized guest.</para>
754 </listitem>
755
756 <listitem>
757 <para>There are certain flaws in the implementation of ring 1 in the
758 x86 architecture that were never fixed. Certain instructions that
759 <emphasis>should</emphasis> trap in ring 1 don't. This affects, for
760 example, the LGDT/SGDT, LIDT/SIDT, or POPF/PUSHF instruction pairs.
761 Whereas the "load" operation is privileged and can therefore be
762 trapped, the "store" instruction always succeed. If the guest is
763 allowed to execute these, it will see the true state of the CPU, not
764 the virtualized state. The CPUID instruction also has the same
765 problem.</para>
766 </listitem>
767
768 <listitem>
769 <para>A hypervisor typically needs to reserve some portion of the
770 guest's address space (both linear address space and selectors) for
771 its own use. This is not entirely transparent to the guest OS and
772 may cause clashes.</para>
773 </listitem>
774
775 <listitem>
776 <para>The SYSENTER instruction (used for system calls) executed by
777 an application running in a guest OS always transitions to ring 0.
778 But that is where the hypervisor runs, not the guest OS. In this
779 case, the hypervisor must trap and emulate the instruction even when
780 it is not desirable.</para>
781 </listitem>
782
783 <listitem>
784 <para>The CPU segment registers contain a "hidden" descriptor cache
785 which is not software-accessible. The hypervisor cannot read, save,
786 or restore this state, but the guest OS may use it.</para>
787 </listitem>
788
789 <listitem>
790 <para>Some resources must (and can) be trapped by the hypervisor,
791 but the access is so frequent that this creates a significant
792 performance overhead. An example is the TPR (Task Priority) register
793 in 32-bit mode. Accesses to this register must be trapped by the
794 hypervisor, but certain guest operating systems (notably Windows and
795 Solaris) write this register very often, which adversely affects
796 virtualization performance.</para>
797 </listitem>
798 </orderedlist></para>
799
800 <para>To fix these performance and security issues, VirtualBox contains a
801 Code Scanning and Analysis Manager (CSAM), which disassembles guest code,
802 and the Patch Manager (PATM), which can replace it at runtime.</para>
803
804 <para>Before executing ring 0 code, CSAM scans it recursively to discover
805 problematic instructions. PATM then performs <emphasis>in-situ
806 </emphasis>patching, i.e. it replaces the instruction with a jump to
807 hypervisor memory where an integrated code generator has placed a more
808 suitable implementation. In reality, this is a very complex task as there
809 are lots of odd situations to be discovered and handled correctly. So,
810 with its current complexity, one could argue that PATM is an advanced
811 <emphasis>in-situ</emphasis> recompiler.</para>
812
813 <para>In addition, every time a fault occurs, VirtualBox analyzes the
814 offending code to determine if it is possible to patch it in order to
815 prevent it from causing more faults in the future. This approach works
816 well in practice and dramatically improves software virtualization
817 performance.</para>
818 </sect1>
819
820 <sect1>
821 <title>Details about hardware virtualization</title>
822
823 <para>With Intel VT-x, there are two distinct modes of CPU operation: VMX
824 root mode and non-root mode.<itemizedlist>
825 <listitem>
826 <para>In root mode, the CPU operates much like older generations of
827 processors without VT-x support. There are four privilege levels
828 ("rings"), and the same instruction set is supported, with the
829 addition of several virtualization specific instruction. Root mode
830 is what a host operating system without virtualization uses, and it
831 is also used by a hypervisor when virtualization is active.</para>
832 </listitem>
833
834 <listitem>
835 <para>In non-root mode, CPU operation is significantly different.
836 There are still four privilege rings and the same instruction set,
837 but a new structure called VMCS (Virtual Machine Control Structure)
838 now controls the CPU operation and determines how certain
839 instructions behave. Non-root mode is where guest systems
840 run.</para>
841 </listitem>
842 </itemizedlist></para>
843
844 <para>Switching from root mode to non-root mode is called "VM entry", the
845 switch back is "VM exit". The VMCS includes a guest and host state area
846 which is saved/restored at VM entry and exit. Most importantly, the VMCS
847 controls which guest operations will cause VM exits.</para>
848
849 <para>The VMCS provides fairly fine-grained control over what the guests
850 can and can't do. For example, a hypervisor can allow a guest to write
851 certain bits in shadowed control registers, but not others. This enables
852 efficient virtualization in cases where guests can be allowed to write
853 control bits without disrupting the hypervisor, while preventing them from
854 altering control bits over which the hypervisor needs to retain full
855 control. The VMCS also provides control over interrupt delivery and
856 exceptions.</para>
857
858 <para>Whenever an instruction or event causes a VM exit, the VMCS contains
859 information about the exit reason, often with accompanying detail. For
860 example, if a write to the CR0 register causes an exit, the offending
861 instruction is recorded, along with the fact that a write access to a
862 control register caused the exit, and information about source and
863 destination register. Thus the hypervisor can efficiently handle the
864 condition without needing advanced techniques such as CSAM and PATM
865 described above.</para>
866
867 <para>VT-x inherently avoids several of the problems which software
868 virtualization faces. The guest has its own completely separate address
869 space not shared with the hypervisor, which eliminates potential clashes.
870 Additionally, guest OS kernel code runs at privilege ring 0 in VMX
871 non-root mode, obviating the problems by running ring 0 code at less
872 privileged levels. For example the SYSENTER instruction can transition to
873 ring 0 without causing problems. Naturally, even at ring 0 in VMX non-root
874 mode, any I/O access by guest code still causes a VM exit, allowing for
875 device emulation.</para>
876
877 <para>The biggest difference between VT-x and AMD-V is that AMD-V provides
878 a more complete virtualization environment. VT-x requires the VMX non-root
879 code to run with paging enabled, which precludes hardware virtualization
880 of real-mode code and non-paged protected-mode software. This typically
881 only includes firmware and OS loaders, but nevertheless complicates VT-x
882 hypervisor implementation. AMD-V does not have this restriction.</para>
883
884 <para>Of course hardware virtualization is not perfect. Compared to
885 software virtualization, the overhead of VM exits is relatively high. This
886 causes problems for devices whose emulation requires high number of traps.
887 One example is the VGA device in 16-color modes, where not only every I/O
888 port access but also every access to the framebuffer memory must be
889 trapped.</para>
890 </sect1>
891
892 <sect1 id="nestedpaging">
893 <title>Nested paging and VPIDs</title>
894
895 <para>In addition to "plain" hardware virtualization, your processor may
896 also support additional sophisticated techniques:<footnote>
897 <para>VirtualBox 2.0 added support for AMD's nested paging; support
898 for Intel's EPT and VPIDs was added with version 2.1.</para>
899 </footnote><itemizedlist>
900 <listitem>
901 <para>A newer feature called <emphasis role="bold">"nested
902 paging"</emphasis> implements some memory management in hardware,
903 which can greatly accelerate hardware virtualization since these
904 tasks no longer need to be performed by the virtualization
905 software.</para>
906
907 <para>With nested paging, the hardware provides another level of
908 indirection when translating linear to physical addresses. Page
909 tables function as before, but linear addresses are now translated
910 to "guest physical" addresses first and not physical addresses
911 directly. A new set of paging registers now exists under the
912 traditional paging mechanism and translates from guest physical
913 addresses to host physical addresses, which are used to access
914 memory.</para>
915
916 <para>Nested paging eliminates the overhead caused by VM exits and
917 page table accesses. In essence, with nested page tables the guest
918 can handle paging without intervention from the hypervisor. Nested
919 paging thus significantly improves virtualization
920 performance.</para>
921
922 <para>On AMD processors, nested paging has been available starting
923 with the Barcelona (K10) architecture -- they call it now "rapid
924 virtualization indexing" (RVI). Intel added support for nested
925 paging, which they call "extended page tables" (EPT), with their
926 Core i7 (Nehalem) processors.</para>
927
928 <para>If nested paging is enabled, the VirtualBox hypervisor can
929 also use <emphasis role="bold">large pages</emphasis> to reduce TLB
930 usage and overhead. This can yield a performance improvement of up
931 to 5%. To enable this feature for a VM, you need to use the
932 <computeroutput>VBoxManage modifyvm
933 </computeroutput><computeroutput>--largepages</computeroutput>
934 command; see <xref linkend="vboxmanage-modifyvm" />.</para>
935 </listitem>
936
937 <listitem>
938 <para>On Intel CPUs, another hardware feature called <emphasis
939 role="bold">"Virtual Processor Identifiers" (VPIDs)</emphasis> can
940 greatly accelerate context switching by reducing the need for
941 expensive flushing of the processor's Translation Lookaside Buffers
942 (TLBs).</para>
943
944 <para>To enable these features for a VM, you need to use the
945 <computeroutput>VBoxManage modifyvm --vtxvpid</computeroutput> and
946 <computeroutput>--largepages</computeroutput> commands; see <xref
947 linkend="vboxmanage-modifyvm" />.</para>
948 </listitem>
949 </itemizedlist></para>
950 </sect1>
951</chapter>
注意: 瀏覽 TracBrowser 來幫助您使用儲存庫瀏覽器

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