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>
|
---|
5 | <title>Remote virtual machines</title>
|
---|
6 |
|
---|
7 | <sect1>
|
---|
8 | <title id="vrde">Remote display (VRDP support)</title>
|
---|
9 |
|
---|
10 | <para>VirtualBox can display virtual machines remotely, meaning that a
|
---|
11 | virtual machine can execute on one machine even though the machine will be
|
---|
12 | displayed on a second computer, and the machine will be controlled from
|
---|
13 | there as well, as if the virtual machine was running on that second
|
---|
14 | computer.</para>
|
---|
15 |
|
---|
16 | <para>For maximum flexibility, starting with VirtualBox 4.0, VirtualBox
|
---|
17 | implements remote machine display through a generic extension interface,
|
---|
18 | the VirtualBox Remote Desktop Extension (VRDE). The base open-source
|
---|
19 | VirtualBox package only provides this interface, while implementations can
|
---|
20 | be supplied by third parties with VirtualBox extension packages, which
|
---|
21 | must be installed separately from the base package. See <xref
|
---|
22 | linkend="intro-installing" /> for more information.</para>
|
---|
23 |
|
---|
24 | <para>Oracle provides support for the <emphasis role="bold">VirtualBox
|
---|
25 | Remote Display Protocol (VRDP)</emphasis> in such a VirtualBox extension
|
---|
26 | package. When this package is installed, VirtualBox versions 4.0 and later
|
---|
27 | support VRDP the same way as binary (non-open-source) versions of
|
---|
28 | VirtualBox before 4.0 did.</para>
|
---|
29 |
|
---|
30 | <para>VRDP is a backwards-compatible extension to Microsoft's Remote
|
---|
31 | Desktop Protocol (RDP). Typically graphics updates and audio are sent from
|
---|
32 | the remote machine to the client, while keyboard and mouse events are sent
|
---|
33 | back. As a result, you can use any standard RDP client to control the
|
---|
34 | remote VM.</para>
|
---|
35 |
|
---|
36 | <para>Even when the extension is installed, the VRDP server is disabled by
|
---|
37 | default. It can easily be enabled on a per-VM basis either in the
|
---|
38 | VirtualBox Manager in the "Display" settings (see <xref
|
---|
39 | linkend="settings-display" />) or with
|
---|
40 | <computeroutput>VBoxManage</computeroutput>:<screen>VBoxManage modifyvm "VM name" --vrde on</screen></para>
|
---|
41 |
|
---|
42 | <para>If you use <computeroutput>VBoxHeadless</computeroutput> (described
|
---|
43 | further below), VRDP support will be automatically enabled since
|
---|
44 | VBoxHeadless has no other means of output.</para>
|
---|
45 |
|
---|
46 | <sect2 id="rdp-viewers">
|
---|
47 | <title>Common third-party RDP viewers</title>
|
---|
48 |
|
---|
49 | <para>Since VRDP is backwards-compatible to RDP, you can use any
|
---|
50 | standard RDP viewer to connect to such a remote virtual machine
|
---|
51 | (examples follow below). For this to work, you must specify the
|
---|
52 | <emphasis role="bold">IP address</emphasis> of your
|
---|
53 | <emphasis>host</emphasis> system (not of the virtual machine!) as the
|
---|
54 | server address to connect to, as well as the <emphasis role="bold">port
|
---|
55 | number</emphasis> that the RDP server is using.</para>
|
---|
56 |
|
---|
57 | <para>By default, VRDP uses TCP port
|
---|
58 | <computeroutput>3389</computeroutput>. You will need to change the
|
---|
59 | default port if you run more than one VRDP server, since the port can
|
---|
60 | only be used by one server at a time; you might also need to change it
|
---|
61 | on Windows hosts since the default port might already be used by the RDP
|
---|
62 | server that is built into Windows itself. Ports 5000 through 5050 are
|
---|
63 | typically not used and might be a good choice.</para>
|
---|
64 |
|
---|
65 | <para>The port can be changed either in the "Display" settings of the
|
---|
66 | graphical user interface or with
|
---|
67 | <computeroutput>--vrdeport</computeroutput> option of the
|
---|
68 | <computeroutput>VBoxManage modifyvm</computeroutput> command. You can
|
---|
69 | specify a comma-separated list of ports or ranges of ports. Use a dash
|
---|
70 | between two port numbers to specify a range. The VRDP server will bind
|
---|
71 | to <emphasis role="bold">one</emphasis> of available ports from the
|
---|
72 | specified list. For example, <computeroutput>VBoxManage modifyvm "VM
|
---|
73 | name" --vrdeport 5000,5010-5012</computeroutput> will configure the
|
---|
74 | server to bind to one of the ports 5000, 5010, 5011 or 5012. See <xref
|
---|
75 | linkend="vboxmanage-modifyvm" /> for details.</para>
|
---|
76 |
|
---|
77 | <para>The actual port used by a running VM can be either queried with
|
---|
78 | <computeroutput>VBoxManage showvminfo</computeroutput> command or seen
|
---|
79 | in the GUI on the "Runtime" tab of the "Session Information Dialog",
|
---|
80 | which is accessible via the "Machine" menu of the VM window.</para>
|
---|
81 |
|
---|
82 | <para>Here follow examples for the most common RDP viewers:<itemizedlist>
|
---|
83 | <listitem>
|
---|
84 | <para>On Windows, you can use the Microsoft Terminal Services
|
---|
85 | Connector (<computeroutput>mstsc.exe</computeroutput>) that ships
|
---|
86 | with Windows. You can start it by bringing up the "Run" dialog
|
---|
87 | (press the Windows key and "R") and typing "mstsc". You can also
|
---|
88 | find it under "Start" -> "All Programs" -> "Accessories"
|
---|
89 | -> "Remote Desktop Connection". If you use the "Run" dialog,
|
---|
90 | you can type in options directly:<screen>mstsc 1.2.3.4[:3389]</screen></para>
|
---|
91 |
|
---|
92 | <para>Replace "1.2.3.4" with the host IP address, and 3389 with a
|
---|
93 | different port if necessary.</para>
|
---|
94 |
|
---|
95 | <note>
|
---|
96 | <para>When connecting to localhost in order to test the
|
---|
97 | connection, the addresses
|
---|
98 | <computeroutput>localhost</computeroutput> and
|
---|
99 | <computeroutput>127.0.0.1</computeroutput> might not work using
|
---|
100 | <computeroutput>mstsc.exe</computeroutput>. Instead, the address
|
---|
101 | <computeroutput>127.0.0.2[:3389]</computeroutput> has to be
|
---|
102 | used.</para>
|
---|
103 | </note>
|
---|
104 | </listitem>
|
---|
105 |
|
---|
106 | <listitem>
|
---|
107 | <para>On other systems, you can use the standard open-source
|
---|
108 | <computeroutput>rdesktop</computeroutput> program. This ships with
|
---|
109 | most Linux distributions, but VirtualBox also comes with a
|
---|
110 | modified variant of rdesktop for remote USB support (see <xref
|
---|
111 | linkend="usb-over-rdp" /> below).</para>
|
---|
112 |
|
---|
113 | <para>With rdesktop, use a command line such as the
|
---|
114 | following:<screen>rdesktop -a 16 -N 1.2.3.4:3389</screen></para>
|
---|
115 |
|
---|
116 | <para>As said for the Microsoft viewer above, replace "1.2.3.4"
|
---|
117 | with the host IP address, and 3389 with a different port if
|
---|
118 | necessary. The <computeroutput>-a 16</computeroutput> option
|
---|
119 | requests a color depth of 16 bits per pixel, which we recommend.
|
---|
120 | (For best performance, after installation of the guest operating
|
---|
121 | system, you should set its display color depth to the same value).
|
---|
122 | The <computeroutput>-N</computeroutput> option enables use of the
|
---|
123 | NumPad keys.</para>
|
---|
124 | </listitem>
|
---|
125 |
|
---|
126 | <listitem>
|
---|
127 | <para>If you run the KDE desktop, you might prefer
|
---|
128 | <computeroutput>krdc</computeroutput>, the KDE RDP viewer. The
|
---|
129 | command line would look like this:<screen>krdc --window --high-quality rdp:/1.2.3.4[:3389]</screen></para>
|
---|
130 |
|
---|
131 | <para>Again, replace "1.2.3.4" with the host IP address, and 3389
|
---|
132 | with a different port if necessary. The "rdp:/" bit is required
|
---|
133 | with krdc to switch it into RDP mode.</para>
|
---|
134 | </listitem>
|
---|
135 |
|
---|
136 | <listitem>
|
---|
137 | <para>With Sun Ray thin clients you can use
|
---|
138 | <computeroutput>uttsc</computeroutput>, which is part of the
|
---|
139 | Sun Ray Windows Connector package. See the corresponding
|
---|
140 | documentation for details.</para>
|
---|
141 | </listitem>
|
---|
142 | </itemizedlist></para>
|
---|
143 | </sect2>
|
---|
144 |
|
---|
145 | <sect2 id="vboxheadless">
|
---|
146 | <title>VBoxHeadless, the remote desktop server</title>
|
---|
147 |
|
---|
148 | <para>While any VM started from the VirtualBox Manager is capable of
|
---|
149 | running virtual machines remotely, it is not convenient to have to run
|
---|
150 | the full-fledged GUI if you never want to have VMs displayed locally in
|
---|
151 | the first place. In particular, if you are running server hardware whose
|
---|
152 | only purpose is to host VMs, and all your VMs are supposed to run
|
---|
153 | remotely over VRDP, then it is pointless to have a graphical user
|
---|
154 | interface on the server at all -- especially since, on a Linux or
|
---|
155 | Solaris host, the VirtualBox manager comes with dependencies on the Qt
|
---|
156 | and SDL libraries. This is inconvenient if you would rather not have the
|
---|
157 | X Window system on your server at all.</para>
|
---|
158 |
|
---|
159 | <para>VirtualBox therefore comes with yet another front-end called
|
---|
160 | <computeroutput>VBoxHeadless</computeroutput>, which produces no visible
|
---|
161 | output on the host at all, but instead only delivers VRDP data. This
|
---|
162 | front-end has no dependencies on the X Window system on Linux and
|
---|
163 | Solaris hosts.<footnote>
|
---|
164 | <para>Before VirtualBox 1.6, the headless server was called
|
---|
165 | <computeroutput>VBoxVRDP</computeroutput>. For the sake of backwards
|
---|
166 | compatibility, the VirtualBox installation still installs an
|
---|
167 | executable with that name as well.</para>
|
---|
168 | </footnote></para>
|
---|
169 |
|
---|
170 | <para>To start a virtual machine with
|
---|
171 | <computeroutput>VBoxHeadless</computeroutput>, you have two
|
---|
172 | options:</para>
|
---|
173 |
|
---|
174 | <itemizedlist>
|
---|
175 | <listitem>
|
---|
176 | <para>You can use <screen>VBoxManage startvm "VM name" --type headless</screen>The
|
---|
177 | extra <computeroutput>--type</computeroutput> option causes
|
---|
178 | VirtualBox to use <computeroutput>VBoxHeadless</computeroutput> as
|
---|
179 | the front-end to the internal virtualization engine instead of the
|
---|
180 | Qt front-end.</para>
|
---|
181 | </listitem>
|
---|
182 |
|
---|
183 | <listitem>
|
---|
184 | <para>The alternative is to use
|
---|
185 | <computeroutput>VBoxHeadless</computeroutput> directly, as
|
---|
186 | follows:<screen>VBoxHeadless --startvm <uuid|name></screen></para>
|
---|
187 |
|
---|
188 | <para>This way of starting the VM helps troubleshooting problems
|
---|
189 | reported by <computeroutput>VBoxManage startvm ...</computeroutput>
|
---|
190 | because you can see sometimes more detailed error messages,
|
---|
191 | especially for early failures before the VM execution is started.
|
---|
192 | In normal situations <computeroutput>VBoxManage startvm</computeroutput>
|
---|
193 | is preferred since it runs the VM directly as a background process
|
---|
194 | which has to be done explicitly when directly starting
|
---|
195 | <computeroutput>VBoxHeadless</computeroutput>.</para>
|
---|
196 | </listitem>
|
---|
197 | </itemizedlist>
|
---|
198 |
|
---|
199 | <para>Note that when you use
|
---|
200 | <computeroutput>VBoxHeadless</computeroutput> to start a VM, since the
|
---|
201 | headless server has no other means of output, the VRDP server will
|
---|
202 | <emphasis>always</emphasis> be enabled, regardless of whether you had
|
---|
203 | enabled the VRDP server in the VM's settings. If this is undesirable
|
---|
204 | (for example because you want to access the VM via
|
---|
205 | <computeroutput>ssh</computeroutput> only), start the VM like
|
---|
206 | this:<screen>VBoxHeadless --startvm <uuid|name> --vrde=off</screen>To
|
---|
207 | have the VRDP server enabled depending on the VM configuration, as the
|
---|
208 | other front-ends would, use this:<screen>VBoxHeadless --startvm <uuid|name> --vrde=config</screen></para>
|
---|
209 |
|
---|
210 | <para>If you start the VM with <computeroutput>VBoxManage startvm ...</computerputput>
|
---|
211 | then the configuration settings of the VM are always used.</para>
|
---|
212 | </sect2>
|
---|
213 |
|
---|
214 | <sect2>
|
---|
215 | <title>Step by step: creating a virtual machine on a headless
|
---|
216 | server</title>
|
---|
217 |
|
---|
218 | <para>The following instructions may give you an idea how to create a
|
---|
219 | virtual machine on a headless server over a network connection. We will
|
---|
220 | create a virtual machine, establish an RDP connection and install a
|
---|
221 | guest operating system -- all without having to touch the headless
|
---|
222 | server. All you need is the following:</para>
|
---|
223 |
|
---|
224 | <para><orderedlist>
|
---|
225 | <listitem>
|
---|
226 | <para>VirtualBox on a server machine with a supported host
|
---|
227 | operating system. The VirtualBox extension pack for the VRDP
|
---|
228 | server must be installed (see the previous section). For the
|
---|
229 | following example, we will assume a Linux server.</para>
|
---|
230 | </listitem>
|
---|
231 |
|
---|
232 | <listitem>
|
---|
233 | <para>An ISO file accessible from the server, containing the
|
---|
234 | installation data for the guest operating system to install (we
|
---|
235 | will assume Windows XP in the following example).</para>
|
---|
236 | </listitem>
|
---|
237 |
|
---|
238 | <listitem>
|
---|
239 | <para>A terminal connection to that host through which you can
|
---|
240 | access a command line (e.g. via
|
---|
241 | <computeroutput>ssh</computeroutput>).</para>
|
---|
242 | </listitem>
|
---|
243 |
|
---|
244 | <listitem>
|
---|
245 | <para>An RDP viewer on the remote client; see <xref
|
---|
246 | linkend="rdp-viewers" /> above for examples.</para>
|
---|
247 | </listitem>
|
---|
248 | </orderedlist>Note again that on the server machine, since we will
|
---|
249 | only use the headless server, neither Qt nor SDL nor the X Window system
|
---|
250 | will be needed.</para>
|
---|
251 |
|
---|
252 | <para><orderedlist>
|
---|
253 | <listitem>
|
---|
254 | <para>On the headless server, create a new virtual machine:</para>
|
---|
255 |
|
---|
256 | <screen>VBoxManage createvm --name "Windows XP" --ostype WindowsXP --register</screen>
|
---|
257 |
|
---|
258 | <para>Note that if you do not specify
|
---|
259 | <computeroutput>--register</computeroutput>, you will have to
|
---|
260 | manually use the <computeroutput>registervm</computeroutput>
|
---|
261 | command later.</para>
|
---|
262 |
|
---|
263 | <para>Note further that you do not need to specify
|
---|
264 | <computeroutput>--ostype</computeroutput>, but doing so selects
|
---|
265 | some sane default values for certain VM parameters, for example
|
---|
266 | the RAM size and the type of the virtual network device. To get a
|
---|
267 | complete list of supported operating systems you can use</para>
|
---|
268 |
|
---|
269 | <screen>VBoxManage list ostypes</screen>
|
---|
270 | </listitem>
|
---|
271 |
|
---|
272 | <listitem>
|
---|
273 | <para>Make sure the settings for this VM are appropriate for the
|
---|
274 | guest operating system that we will install. For example:<screen>VBoxManage modifyvm "Windows XP" --memory 256 --acpi on --boot1 dvd --nic1 nat</screen></para>
|
---|
275 | </listitem>
|
---|
276 |
|
---|
277 | <listitem>
|
---|
278 | <para>Create a virtual hard disk for the VM (in this case, 10GB in
|
---|
279 | size):<screen>VBoxManage createhd --filename "WinXP.vdi" --size 10000</screen></para>
|
---|
280 | </listitem>
|
---|
281 |
|
---|
282 | <listitem>
|
---|
283 | <para>Add an IDE Controller to the new VM:<screen>VBoxManage storagectl "Windows XP" --name "IDE Controller"
|
---|
284 | --add ide --controller PIIX4</screen></para>
|
---|
285 | </listitem>
|
---|
286 |
|
---|
287 | <listitem>
|
---|
288 | <para>Set the VDI file created above as the first virtual hard
|
---|
289 | disk of the new VM:<screen>VBoxManage storageattach "Windows XP" --storagectl "IDE Controller"
|
---|
290 | --port 0 --device 0 --type hdd --medium "WinXP.vdi"</screen></para>
|
---|
291 | </listitem>
|
---|
292 |
|
---|
293 | <listitem>
|
---|
294 | <para>Attach the ISO file that contains the operating system
|
---|
295 | installation that you want to install later to the virtual
|
---|
296 | machine, so the machine can boot from it:<screen>VBoxManage storageattach "Windows XP" --storagectl "IDE Controller"
|
---|
297 | --port 0 --device 1 --type dvddrive --medium /full/path/to/iso.iso</screen></para>
|
---|
298 | </listitem>
|
---|
299 |
|
---|
300 | <listitem>
|
---|
301 | <para>Start the virtual machine using VBoxHeadless:<screen>VBoxHeadless --startvm "Windows XP"</screen></para>
|
---|
302 |
|
---|
303 | <para>If everything worked, you should see a copyright notice. If,
|
---|
304 | instead, you are returned to the command line, then something went
|
---|
305 | wrong.</para>
|
---|
306 | </listitem>
|
---|
307 |
|
---|
308 | <listitem>
|
---|
309 | <para>On the client machine, fire up the RDP viewer and try to
|
---|
310 | connect to the server (see <xref linkend="rdp-viewers" /> above
|
---|
311 | for how to use various common RDP viewers).</para>
|
---|
312 |
|
---|
313 | <para>You should now be seeing the installation routine of your
|
---|
314 | guest operating system remotely in the RDP viewer.</para>
|
---|
315 | </listitem>
|
---|
316 | </orderedlist></para>
|
---|
317 | </sect2>
|
---|
318 |
|
---|
319 | <sect2 id="usb-over-rdp">
|
---|
320 | <title>Remote USB</title>
|
---|
321 |
|
---|
322 | <para>As a special feature on top of the VRDP support, VirtualBox
|
---|
323 | supports remote USB devices over the wire as well. That is, the
|
---|
324 | VirtualBox guest that runs on one computer can access the USB devices of
|
---|
325 | the remote computer on which the VRDP data is being displayed the same
|
---|
326 | way as USB devices that are connected to the actual host. This allows
|
---|
327 | for running virtual machines on a VirtualBox host that acts as a server,
|
---|
328 | where a client can connect from elsewhere that needs only a network
|
---|
329 | adapter and a display capable of running an RDP viewer. When USB devices
|
---|
330 | are plugged into the client, the remote VirtualBox server can access
|
---|
331 | them.</para>
|
---|
332 |
|
---|
333 | <para>For these remote USB devices, the same filter rules apply as for
|
---|
334 | other USB devices, as described with <xref linkend="settings-usb" />.
|
---|
335 | All you have to do is specify "Remote" (or "Any") when setting up these
|
---|
336 | rules.</para>
|
---|
337 |
|
---|
338 | <para>Accessing remote USB devices is only possible if the RDP client
|
---|
339 | supports this extension. On Linux and Solaris hosts, the VirtualBox
|
---|
340 | installation provides a suitable VRDP client called
|
---|
341 | <computeroutput>rdesktop-vrdp</computeroutput>. Recent versions of
|
---|
342 | <computeroutput>uttsc</computeroutput>, a client tailored for the use
|
---|
343 | with Sun Ray thin clients, also support accessing remote USB devices.
|
---|
344 | RDP clients for other platforms will be provided in future VirtualBox
|
---|
345 | versions.</para>
|
---|
346 |
|
---|
347 | <para>To make a remote USB device available to a VM,
|
---|
348 | <computeroutput>rdesktop-vrdp</computeroutput> should be started as
|
---|
349 | follows:<screen>rdesktop-vrdp -r usb -a 16 -N my.host.address</screen>Note
|
---|
350 | that <computeroutput>rdesktop-vrdp</computeroutput> can access USB
|
---|
351 | devices only through <computeroutput>/proc/bus/usb</computeroutput>.
|
---|
352 | Please refer to <xref linkend="ts_usb-linux" /> for further details on how
|
---|
353 | to properly set up the permissions. Furthermore it is advisable to
|
---|
354 | disable automatic loading of any host driver on the remote host which
|
---|
355 | might work on USB devices to ensure that the devices are accessible by
|
---|
356 | the RDP client. If the setup was properly done on the remote host,
|
---|
357 | plug/unplug events are visible on the VBox.log file of the VM.</para>
|
---|
358 | </sect2>
|
---|
359 |
|
---|
360 | <sect2 id="vbox-auth">
|
---|
361 | <title>RDP authentication</title>
|
---|
362 |
|
---|
363 | <para>For each virtual machine that is remotely accessible via RDP, you
|
---|
364 | can individually determine if and how client connections are
|
---|
365 | authenticated. For this, use <computeroutput>VBoxManage
|
---|
366 | modifyvm</computeroutput> command with the
|
---|
367 | <computeroutput>--vrdeauthtype</computeroutput> option; see <xref
|
---|
368 | linkend="vboxmanage-modifyvm" /> for a general introduction. Three
|
---|
369 | methods of authentication are available:<itemizedlist>
|
---|
370 | <listitem>
|
---|
371 | <para>The "null" method means that there is no authentication at
|
---|
372 | all; any client can connect to the VRDP server and thus the
|
---|
373 | virtual machine. This is, of course, very insecure and only to be
|
---|
374 | recommended for private networks.</para>
|
---|
375 | </listitem>
|
---|
376 |
|
---|
377 | <listitem>
|
---|
378 | <para>The "external" method provides external authentication
|
---|
379 | through a special authentication library. VirtualBox ships with
|
---|
380 | two such authentication libraries:<orderedlist>
|
---|
381 | <listitem>
|
---|
382 | <para>The default authentication library,
|
---|
383 | <computeroutput>VBoxAuth</computeroutput>, authenticates
|
---|
384 | against user credentials of the hosts. Depending on the host
|
---|
385 | platform, this means:<itemizedlist>
|
---|
386 | <listitem>
|
---|
387 | <para>On Linux hosts,
|
---|
388 | <computeroutput>VBoxAuth.so</computeroutput>
|
---|
389 | authenticates users against the host's PAM
|
---|
390 | system.</para>
|
---|
391 | </listitem>
|
---|
392 |
|
---|
393 | <listitem>
|
---|
394 | <para>On Windows hosts,
|
---|
395 | <computeroutput>VBoxAuth.dll</computeroutput>
|
---|
396 | authenticates users against the host's WinLogon
|
---|
397 | system.</para>
|
---|
398 | </listitem>
|
---|
399 |
|
---|
400 | <listitem>
|
---|
401 | <para>On Mac OS X hosts,
|
---|
402 | <computeroutput>VBoxAuth.dylib</computeroutput>
|
---|
403 | authenticates users against the host's directory
|
---|
404 | service.<footnote>
|
---|
405 | <para>Support for Mac OS X was added in version
|
---|
406 | 3.2.</para>
|
---|
407 | </footnote></para>
|
---|
408 | </listitem>
|
---|
409 | </itemizedlist></para>
|
---|
410 |
|
---|
411 | <para>In other words, the "external" method per default
|
---|
412 | performs authentication with the user accounts that exist on
|
---|
413 | the host system. Any user with valid authentication
|
---|
414 | credentials is accepted, i.e. the username does not have to
|
---|
415 | correspond to the user running the VM.</para>
|
---|
416 | </listitem>
|
---|
417 |
|
---|
418 | <listitem>
|
---|
419 | <para>An additional library called
|
---|
420 | <computeroutput>VBoxAuthSimple</computeroutput> performs
|
---|
421 | authentication against credentials configured in the
|
---|
422 | "extradata" section of a virtual machine's XML settings
|
---|
423 | file. This is probably the simplest way to get
|
---|
424 | authentication that does not depend on a running and
|
---|
425 | supported guest (see below). The following steps are
|
---|
426 | required:<orderedlist>
|
---|
427 | <listitem>
|
---|
428 | <para>Enable
|
---|
429 | <computeroutput>VBoxAuthSimple</computeroutput> with
|
---|
430 | the following command:</para>
|
---|
431 |
|
---|
432 | <para><screen>VBoxManage setproperty vrdeauthlibrary "VBoxAuthSimple"</screen></para>
|
---|
433 | </listitem>
|
---|
434 |
|
---|
435 | <listitem>
|
---|
436 | <para>To enable the library for a particular VM, you
|
---|
437 | must then switch authentication to external:<screen>VBoxManage modifyvm <vm> --vrdeauthtype external</screen></para>
|
---|
438 |
|
---|
439 | <para>Replace
|
---|
440 | <computeroutput><vm></computeroutput> with the
|
---|
441 | VM name or UUID.</para>
|
---|
442 | </listitem>
|
---|
443 |
|
---|
444 | <listitem>
|
---|
445 | <para>You will then need to configure users and
|
---|
446 | passwords by writing items into the machine's
|
---|
447 | extradata. Since the XML machine settings file, into
|
---|
448 | whose "extradata" section the password needs to be
|
---|
449 | written, is a plain text file, VirtualBox uses hashes
|
---|
450 | to encrypt passwords. The following command must be
|
---|
451 | used:<screen>VBoxManage setextradata <vm> "VBoxAuthSimple/users/<user>" <hash></screen></para>
|
---|
452 |
|
---|
453 | <para>Replace
|
---|
454 | <computeroutput><vm></computeroutput> with the
|
---|
455 | VM name or UUID,
|
---|
456 | <computeroutput><user></computeroutput> with the
|
---|
457 | user name who should be allowed to log in and
|
---|
458 | <computeroutput><hash></computeroutput> with the
|
---|
459 | encrypted password. As an example, to obtain the hash
|
---|
460 | value for the password "secret", you can use the
|
---|
461 | following command:<screen>VBoxManage internalcommands passwordhash "secret"</screen></para>
|
---|
462 |
|
---|
463 | <para>This will print
|
---|
464 | <screen>2bb80d537b1da3e38bd30361aa855686bde0eacd7162fef6a25fe97bf527a25b</screen>
|
---|
465 | You can then use VBoxManage setextradata to store this
|
---|
466 | value in the machine's "extradata" section.</para>
|
---|
467 |
|
---|
468 | <para>As example, combined together, to set the
|
---|
469 | password for the user "john" and the machine "My VM"
|
---|
470 | to "secret", use this command:<screen>VBoxManage setextradata "My VM" "VBoxAuthSimple/users/john"
|
---|
471 | 2bb80d537b1da3e38bd30361aa855686bde0eacd7162fef6a25fe97bf527a25b</screen></para>
|
---|
472 | </listitem>
|
---|
473 | </orderedlist></para>
|
---|
474 | </listitem>
|
---|
475 | </orderedlist></para>
|
---|
476 | </listitem>
|
---|
477 |
|
---|
478 | <listitem>
|
---|
479 | <para>Finally, the "guest" authentication method performs
|
---|
480 | authentication with a special component that comes with the Guest
|
---|
481 | Additions; as a result, authentication is not performed on the
|
---|
482 | host, but with the <emphasis>guest</emphasis> user
|
---|
483 | accounts.</para>
|
---|
484 |
|
---|
485 | <para>This method is currently still in testing and not yet
|
---|
486 | supported.</para>
|
---|
487 | </listitem>
|
---|
488 | </itemizedlist></para>
|
---|
489 |
|
---|
490 | <para>In addition to the methods described above, you can replace the
|
---|
491 | default "external" authentication module with any other module. For
|
---|
492 | this, VirtualBox provides a well-defined interface that allows you to
|
---|
493 | write your own authentication module. This is described in detail in the
|
---|
494 | VirtualBox Software Development Kit (SDK) reference; please see <xref
|
---|
495 | linkend="VirtualBoxAPI" /> for details.</para>
|
---|
496 | </sect2>
|
---|
497 |
|
---|
498 | <sect2 id="vrde-crypt">
|
---|
499 | <title>RDP encryption</title>
|
---|
500 |
|
---|
501 | <para>RDP features data stream encryption, which is based on the RC4
|
---|
502 | symmetric cipher (with keys up to 128bit). The RC4 keys are being
|
---|
503 | replaced in regular intervals (every 4096 packets).</para>
|
---|
504 |
|
---|
505 | <para>RDP provides different authentication methods:<orderedlist>
|
---|
506 | <listitem>
|
---|
507 | <para>Historically, RDP4 authentication was used, with which the
|
---|
508 | RDP client does not perform any checks in order to verify the
|
---|
509 | identity of the server it connects to. Since user credentials can
|
---|
510 | be obtained using a "man in the middle" (MITM) attack, RDP4
|
---|
511 | authentication is insecure and should generally not be
|
---|
512 | used.</para>
|
---|
513 | </listitem>
|
---|
514 |
|
---|
515 | <listitem>
|
---|
516 | <para>RDP5.1 authentication employs a server certificate for which
|
---|
517 | the client possesses the public key. This way it is guaranteed
|
---|
518 | that the server possess the corresponding private key. However, as
|
---|
519 | this hard-coded private key became public some years ago, RDP5.1
|
---|
520 | authentication is also insecure.</para>
|
---|
521 | </listitem>
|
---|
522 |
|
---|
523 | <listitem>
|
---|
524 | <para>RDP5.2 authentication uses the Enhanced RDP Security, which
|
---|
525 | means that an external security protocol is used to secure the
|
---|
526 | connection. RDP4 and RDP5.1 use Standard RDP Security.
|
---|
527 | The VRDP server supports Enhanced RDP Security with TLS protocol and,
|
---|
528 | as a part of TLS handshake, sends the server certificate to the
|
---|
529 | client.</para>
|
---|
530 |
|
---|
531 | <para>The <computeroutput>Security/Method</computeroutput> VRDE
|
---|
532 | property sets the desired security method, which is used for a
|
---|
533 | connection. Valid values are:<itemizedlist>
|
---|
534 | <listitem>
|
---|
535 | <para>
|
---|
536 | <computeroutput>Negotiate</computeroutput> - both Enhanced (TLS)
|
---|
537 | and Standard RDP Security connections are allowed. The security
|
---|
538 | method is negotiated with the client. This is the default setting.
|
---|
539 | </para>
|
---|
540 | </listitem>
|
---|
541 |
|
---|
542 | <listitem>
|
---|
543 | <para>
|
---|
544 | <computeroutput>RDP</computeroutput> - only Standard RDP Security
|
---|
545 | is accepted.</para>
|
---|
546 | </listitem>
|
---|
547 |
|
---|
548 | <listitem>
|
---|
549 | <para>
|
---|
550 | <computeroutput>TLS</computeroutput> - only Enhanced RDP Security
|
---|
551 | is accepted. The client must support TLS.</para>
|
---|
552 | </listitem>
|
---|
553 | </itemizedlist>
|
---|
554 | For example the following command allows a client to use either Standard
|
---|
555 | or Enhanced RDP Security connection:
|
---|
556 | <screen>vboxmanage modifyvm "VM name" --vrdeproperty "Security/Method=negotiate"</screen>
|
---|
557 | </para>
|
---|
558 |
|
---|
559 | <para>If the <computeroutput>Security/Method</computeroutput> property is
|
---|
560 | set to either <computeroutput>Negotiate</computeroutput> or
|
---|
561 | <computeroutput>TLS</computeroutput>, the TLS protocol will be automatically
|
---|
562 | used by the server, if the client supports TLS. However, in order to use TLS
|
---|
563 | the server must possess the Server Certificate, the Server Private Key and the
|
---|
564 | Certificate Authority (CA) Certificate. The following example shows how to
|
---|
565 | generate a server certificate.<orderedlist>
|
---|
566 | <listitem>
|
---|
567 | Create a CA self signed certificate:
|
---|
568 | <screen>openssl req -new -x509 -days 365 -extensions v3_ca \
|
---|
569 | -keyout ca_key_private.pem -out ca_cert.pem</screen>
|
---|
570 | </listitem>
|
---|
571 |
|
---|
572 | <listitem>
|
---|
573 | Generate a server private key and a request for signing:
|
---|
574 | <screen>openssl genrsa -out server_key_private.pem
|
---|
575 | openssl req -new -key server_key_private.pem -out server_req.pem</screen>
|
---|
576 | </listitem>
|
---|
577 |
|
---|
578 | <listitem>
|
---|
579 | Generate the server certificate:
|
---|
580 | <screen>openssl x509 -req -days 365 -in server_req.pem \
|
---|
581 | -CA ca_cert.pem -CAkey ca_key_private.pem -set_serial 01 -out server_cert.pem</screen>
|
---|
582 | </listitem>
|
---|
583 | </orderedlist>
|
---|
584 | The server must be configured to access the required files:
|
---|
585 | <screen>vboxmanage modifyvm "VM name" \
|
---|
586 | --vrdeproperty "Security/CACertificate=path/ca_cert.pem"</screen>
|
---|
587 | <screen>vboxmanage modifyvm "VM name" \
|
---|
588 | --vrdeproperty "Security/ServerCertificate=path/server_cert.pem"</screen>
|
---|
589 | <screen>vboxmanage modifyvm "VM name" \
|
---|
590 | --vrdeproperty "Security/ServerPrivateKey=path/server_key_private.pem"</screen>
|
---|
591 | </para>
|
---|
592 | </listitem>
|
---|
593 | </orderedlist></para>
|
---|
594 |
|
---|
595 | <para>As the client that connects to the server determines what type
|
---|
596 | of encryption will be used, with rdesktop, the Linux RDP viewer, use the
|
---|
597 | <computeroutput>-4</computeroutput> or
|
---|
598 | <computeroutput>-5</computeroutput> options.</para>
|
---|
599 | </sect2>
|
---|
600 |
|
---|
601 | <sect2 id="vrde-multiconnection">
|
---|
602 | <title>Multiple connections to the VRDP server</title>
|
---|
603 |
|
---|
604 | <para>The VRDP server of VirtualBox supports multiple simultaneous
|
---|
605 | connections to the same running VM from different clients. All connected
|
---|
606 | clients see the same screen output and share a mouse pointer and
|
---|
607 | keyboard focus. This is similar to several people using the same
|
---|
608 | computer at the same time, taking turns at the keyboard.</para>
|
---|
609 |
|
---|
610 | <para>The following command enables multiple connection mode: <screen>VBoxManage modifyvm "VM name" --vrdemulticon on</screen></para>
|
---|
611 | </sect2>
|
---|
612 |
|
---|
613 | <sect2 id="vrde-multimonitor">
|
---|
614 | <title>Multiple remote monitors</title>
|
---|
615 |
|
---|
616 | <para>To access two or more remote VM displays you have to enable the
|
---|
617 | VRDP multiconnection mode (see <xref
|
---|
618 | linkend="vrde-multiconnection" />).</para>
|
---|
619 |
|
---|
620 | <para>The RDP client can select the virtual monitor number to connect to
|
---|
621 | using the <computeroutput>domain</computeroutput> logon parameter
|
---|
622 | (<computeroutput>-d</computeroutput>). If the parameter ends with
|
---|
623 | <computeroutput>@</computeroutput> followed by a number, VirtualBox
|
---|
624 | interprets this number as the screen index. The primary guest screen is
|
---|
625 | selected with <computeroutput>@1</computeroutput>, the first secondary
|
---|
626 | screen is <computeroutput>@2</computeroutput>, etc.</para>
|
---|
627 |
|
---|
628 | <para>The Microsoft RDP6 client does not let you specify a separate
|
---|
629 | domain name. Instead, use
|
---|
630 | <computeroutput>domain\username</computeroutput> in the
|
---|
631 | <computeroutput>Username:</computeroutput> field -- for example,
|
---|
632 | <computeroutput>@2\name</computeroutput>.
|
---|
633 | <computeroutput>name</computeroutput> must be supplied, and must be the
|
---|
634 | name used to log in if the VRDP server is set up to require credentials.
|
---|
635 | If it is not, you may use any text as the username.</para>
|
---|
636 | </sect2>
|
---|
637 |
|
---|
638 | <sect2 id="vrde-videochannel">
|
---|
639 | <title>VRDP video redirection</title>
|
---|
640 |
|
---|
641 | <para>Starting with VirtualBox 3.2, the VRDP server can redirect video
|
---|
642 | streams from the guest to the RDP client. Video frames are compressed
|
---|
643 | using the JPEG algorithm allowing a higher compression ratio than
|
---|
644 | standard RDP bitmap compression methods. It is possible to increase the
|
---|
645 | compression ratio by lowering the video quality.</para>
|
---|
646 |
|
---|
647 | <para>The VRDP server automatically detects video streams in a guest as
|
---|
648 | frequently updated rectangular areas. As a result, this method works
|
---|
649 | with any guest operating system without having to install additional
|
---|
650 | software in the guest; in particular, the Guest Additions are not
|
---|
651 | required.</para>
|
---|
652 |
|
---|
653 | <para>On the client side, however, currently only the Windows 7 Remote
|
---|
654 | Desktop Connection client supports this feature. If a client does not
|
---|
655 | support video redirection, the VRDP server falls back to regular bitmap
|
---|
656 | updates.</para>
|
---|
657 |
|
---|
658 | <para>The following command enables video redirection: <screen>VBoxManage modifyvm "VM name" --vrdevideochannel on</screen></para>
|
---|
659 |
|
---|
660 | <para>The quality of the video is defined as a value from 10 to 100
|
---|
661 | percent, representing a JPEG compression level (where lower numbers mean
|
---|
662 | lower quality but higher compression). The quality can be changed using
|
---|
663 | the following command: <screen>VBoxManage modifyvm "VM name" --vrdevideochannelquality 75</screen></para>
|
---|
664 | </sect2>
|
---|
665 |
|
---|
666 | <sect2 id="vrde-customization">
|
---|
667 | <title>VRDP customization</title>
|
---|
668 |
|
---|
669 | <para>With VirtualBox 4.0 it is possible to disable display output,
|
---|
670 | mouse and keyboard input, audio, remote USB or clipboard individually in
|
---|
671 | the VRDP server.</para>
|
---|
672 |
|
---|
673 | <para>The following commands change corresponding server
|
---|
674 | settings:</para>
|
---|
675 |
|
---|
676 | <screen>VBoxManage modifyvm "VM name" --vrdeproperty Client/DisableDisplay=1
|
---|
677 | VBoxManage modifyvm "VM name" --vrdeproperty Client/DisableInput=1
|
---|
678 | VBoxManage modifyvm "VM name" --vrdeproperty Client/DisableUSB=1
|
---|
679 | VBoxManage modifyvm "VM name" --vrdeproperty Client/DisableAudio=1
|
---|
680 | VBoxManage modifyvm "VM name" --vrdeproperty Client/DisableClipboard=1
|
---|
681 | VBoxManage modifyvm "VM name" --vrdeproperty Client/DisableUpstreamAudio=1</screen>
|
---|
682 |
|
---|
683 | <para>To reenable a feature use a similar command without the trailing
|
---|
684 | 1. For example: <screen>VBoxManage modifyvm "VM name" --vrdeproperty Client/DisableDisplay=</screen></para>
|
---|
685 |
|
---|
686 | <para>These properties were introduced with VirtualBox 3.2.10. However,
|
---|
687 | in the 3.2.x series, it was necessary to use the following commands to
|
---|
688 | alter these settings instead:</para>
|
---|
689 |
|
---|
690 | <screen>VBoxManage setextradata "VM name" "VRDP/Feature/Client/DisableDisplay" 1
|
---|
691 | VBoxManage setextradata "VM name" "VRDP/Feature/Client/DisableInput" 1
|
---|
692 | VBoxManage setextradata "VM name" "VRDP/Feature/Client/DisableUSB" 1
|
---|
693 | VBoxManage setextradata "VM name" "VRDP/Feature/Client/DisableAudio" 1
|
---|
694 | VBoxManage setextradata "VM name" "VRDP/Feature/Client/DisableClipboard" 1</screen>
|
---|
695 |
|
---|
696 | <para>To reenable a feature use a similar command without the trailing
|
---|
697 | 1. For example: <screen>VBoxManage setextradata "VM name" "VRDP/Feature/Client/DisableDisplay"</screen></para>
|
---|
698 | </sect2>
|
---|
699 | </sect1>
|
---|
700 |
|
---|
701 | <sect1 id="teleporting">
|
---|
702 | <title>Teleporting</title>
|
---|
703 |
|
---|
704 | <para>Starting with version 3.1, VirtualBox supports "teleporting" -- that
|
---|
705 | is, moving a virtual machine over a network from one VirtualBox host to
|
---|
706 | another, while the virtual machine is running. This works regardless of
|
---|
707 | the host operating system that is running on the hosts: you can teleport
|
---|
708 | virtual machines between Solaris and Mac hosts, for example.</para>
|
---|
709 |
|
---|
710 | <para>Teleporting requires that a machine be currently running on one
|
---|
711 | host, which is then called the <emphasis role="bold">"source"</emphasis>.
|
---|
712 | The host to which the virtual machine will be teleported will then be
|
---|
713 | called the <emphasis role="bold">"target"</emphasis>; the machine on the
|
---|
714 | target is then configured to wait for the source to contact the target.
|
---|
715 | The machine's running state will then be transferred from the source to
|
---|
716 | the target with minimal downtime.</para>
|
---|
717 |
|
---|
718 | <para>Teleporting happens over any TCP/IP network; the source and the
|
---|
719 | target only need to agree on a TCP/IP port which is specified in the
|
---|
720 | teleporting settings.</para>
|
---|
721 |
|
---|
722 | <para>At this time, there are a few prerequisites for this to work,
|
---|
723 | however:<orderedlist>
|
---|
724 | <listitem>
|
---|
725 | <para>On the target host, you must configure a virtual machine in
|
---|
726 | VirtualBox with exactly the same hardware settings as the machine on
|
---|
727 | the source that you want to teleport. This does not apply to
|
---|
728 | settings which are merely descriptive, such as the VM name, but
|
---|
729 | obviously for teleporting to work, the target machine must have the
|
---|
730 | same amount of memory and other hardware settings. Otherwise
|
---|
731 | teleporting will fail with an error message.</para>
|
---|
732 | </listitem>
|
---|
733 |
|
---|
734 | <listitem>
|
---|
735 | <para>The two virtual machines on the source and the target must
|
---|
736 | share the same storage (hard disks as well as floppy and CD/DVD
|
---|
737 | images). This means that they either use the same iSCSI targets or
|
---|
738 | that the storage resides somewhere on the network and both hosts
|
---|
739 | have access to it via NFS or SMB/CIFS.</para>
|
---|
740 |
|
---|
741 | <para>This also means that neither the source nor the target machine
|
---|
742 | can have any snapshots.</para>
|
---|
743 | </listitem>
|
---|
744 | </orderedlist></para>
|
---|
745 |
|
---|
746 | <para>Then perform the following steps:<orderedlist>
|
---|
747 | <listitem>
|
---|
748 | <para>On the <emphasis>target</emphasis> host, configure the virtual
|
---|
749 | machine to wait for a teleport request to arrive when it is started,
|
---|
750 | instead of actually attempting to start the machine. This is done
|
---|
751 | with the following VBoxManage command:<screen>VBoxManage modifyvm <targetvmname> --teleporter on --teleporterport <port></screen></para>
|
---|
752 |
|
---|
753 | <para>where <computeroutput><targetvmname></computeroutput> is
|
---|
754 | the name of the virtual machine on the target host and
|
---|
755 | <computeroutput><port></computeroutput> is a TCP/IP port
|
---|
756 | number to be used on both the source and the target hosts. For
|
---|
757 | example, use 6000. For details, see <xref
|
---|
758 | linkend="vboxmanage-modifyvm-teleport" />.</para>
|
---|
759 | </listitem>
|
---|
760 |
|
---|
761 | <listitem>
|
---|
762 | <para>Start the VM on the target host. You will see that instead of
|
---|
763 | actually running, it will show a progress dialog. indicating that it
|
---|
764 | is waiting for a teleport request to arrive.</para>
|
---|
765 | </listitem>
|
---|
766 |
|
---|
767 | <listitem>
|
---|
768 | <para>Start the machine on the <emphasis>source</emphasis> host as
|
---|
769 | usual. When it is running and you want it to be teleported, issue
|
---|
770 | the following command on the source host:<screen>VBoxManage controlvm <sourcevmname> teleport --host <targethost> --port <port></screen></para>
|
---|
771 |
|
---|
772 | <para>where <computeroutput><sourcevmname></computeroutput> is
|
---|
773 | the name of the virtual machine on the source host (the machine that
|
---|
774 | is currently running),
|
---|
775 | <computeroutput><targethost></computeroutput> is the host or
|
---|
776 | IP name of the target host on which the machine is waiting for the
|
---|
777 | teleport request, and <computeroutput><port></computeroutput>
|
---|
778 | must be the same number as specified in the command on the target
|
---|
779 | host. For details, see <xref
|
---|
780 | linkend="vboxmanage-controlvm" />.</para>
|
---|
781 | </listitem>
|
---|
782 | </orderedlist></para>
|
---|
783 |
|
---|
784 | <para>For testing, you can also teleport machines on the same host; in
|
---|
785 | that case, use "localhost" as the hostname on both the source and the
|
---|
786 | target host.<note>
|
---|
787 | <para>In rare cases, if the CPUs of the source and the target are very
|
---|
788 | different, teleporting can fail with an error message, or the target
|
---|
789 | may hang. This may happen especially if the VM is running application
|
---|
790 | software that is highly optimized to run on a particular CPU without
|
---|
791 | correctly checking that certain CPU features are actually present.
|
---|
792 | VirtualBox filters what CPU capabilities are presented to the guest
|
---|
793 | operating system. Advanced users can attempt to restrict these virtual
|
---|
794 | CPU capabilities with the <computeroutput>VBoxManage --modifyvm
|
---|
795 | --cpuid</computeroutput> command; see <xref
|
---|
796 | linkend="vboxmanage-modifyvm-teleport" />.</para>
|
---|
797 | </note></para>
|
---|
798 | </sect1>
|
---|
799 | </chapter>
|
---|