1 | <?xml version="1.0" encoding="UTF-8"?>
|
---|
2 | <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
|
---|
3 | "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd">
|
---|
4 | <chapter id="networkingdetails">
|
---|
5 | <title>Virtual networking</title>
|
---|
6 |
|
---|
7 | <para>As briefly mentioned in <xref linkend="settings-network" />,
|
---|
8 | VirtualBox provides up to eight virtual PCI Ethernet cards for each virtual
|
---|
9 | machine. For each such card, you can individually select<orderedlist>
|
---|
10 | <listitem>
|
---|
11 | <para>the hardware that will be virtualized as well as</para>
|
---|
12 | </listitem>
|
---|
13 |
|
---|
14 | <listitem>
|
---|
15 | <para>the virtualization mode that the virtual card will be operating
|
---|
16 | in with respect to your physical networking hardware on the
|
---|
17 | host.</para>
|
---|
18 | </listitem>
|
---|
19 | </orderedlist></para>
|
---|
20 |
|
---|
21 | <para>Four of the network cards can be configured in the "Network" section
|
---|
22 | of the settings dialog in the graphical user interface of VirtualBox. You
|
---|
23 | can configure all eight network cards on the command line via VBoxManage
|
---|
24 | modifyvm; see <xref linkend="vboxmanage-modifyvm" />.</para>
|
---|
25 |
|
---|
26 | <para>This chapter explains the various networking settings in more
|
---|
27 | detail.</para>
|
---|
28 |
|
---|
29 | <sect1 id="nichardware">
|
---|
30 | <title>Virtual networking hardware</title>
|
---|
31 |
|
---|
32 | <para>For each card, you can individually select what kind of
|
---|
33 | <emphasis>hardware</emphasis> will be presented to the virtual machine.
|
---|
34 | VirtualBox can virtualize the following six types of networking
|
---|
35 | hardware:<itemizedlist>
|
---|
36 | <listitem>
|
---|
37 | <para>AMD PCNet PCI II (Am79C970A);</para>
|
---|
38 | </listitem>
|
---|
39 |
|
---|
40 | <listitem>
|
---|
41 | <para>AMD PCNet FAST III (Am79C973, the default);</para>
|
---|
42 | </listitem>
|
---|
43 |
|
---|
44 | <listitem>
|
---|
45 | <para>Intel PRO/1000 MT Desktop (82540EM);</para>
|
---|
46 | </listitem>
|
---|
47 |
|
---|
48 | <listitem>
|
---|
49 | <para>Intel PRO/1000 T Server (82543GC);</para>
|
---|
50 | </listitem>
|
---|
51 |
|
---|
52 | <listitem>
|
---|
53 | <para>Intel PRO/1000 MT Server (82545EM);</para>
|
---|
54 | </listitem>
|
---|
55 |
|
---|
56 | <listitem>
|
---|
57 | <para>Paravirtualized network adapter (virtio-net).</para>
|
---|
58 | </listitem>
|
---|
59 | </itemizedlist></para>
|
---|
60 |
|
---|
61 | <para>The PCNet FAST III is the default because it is supported by nearly
|
---|
62 | all operating systems out of the box, as well as the GNU GRUB boot
|
---|
63 | manager. As an exception, the Intel PRO/1000 family adapters are chosen
|
---|
64 | for some guest operating system types that no longer ship with drivers for
|
---|
65 | the PCNet card, such as Windows Vista.</para>
|
---|
66 |
|
---|
67 | <para>The Intel PRO/1000 MT Desktop type works with Windows Vista and
|
---|
68 | later versions. The T Server variant of the Intel PRO/1000 card is
|
---|
69 | recognized by Windows XP guests without additional driver installation.
|
---|
70 | The MT Server variant facilitates OVF imports from other platforms.</para>
|
---|
71 |
|
---|
72 | <para>The <emphasis role="bold">"Paravirtualized network adapter
|
---|
73 | (virtio-net)"</emphasis> is special. If you select this, then VirtualBox
|
---|
74 | does <emphasis>not</emphasis> virtualize common networking hardware (that
|
---|
75 | is supported by common guest operating systems out of the box). Instead,
|
---|
76 | VirtualBox then expects a special software interface for virtualized
|
---|
77 | environments to be provided by the guest, thus avoiding the complexity of
|
---|
78 | emulating networking hardware and improving network performance. Starting
|
---|
79 | with version 3.1, VirtualBox provides support for the industry-standard
|
---|
80 | "virtio" networking drivers, which are part of the open-source KVM
|
---|
81 | project.</para>
|
---|
82 |
|
---|
83 | <para>The "virtio" networking drivers are available for the following
|
---|
84 | guest operating systems:</para>
|
---|
85 |
|
---|
86 | <para><itemizedlist>
|
---|
87 | <listitem>
|
---|
88 | <para>Linux kernels version 2.6.25 or later can be configured to
|
---|
89 | provide virtio support; some distributions also back-ported virtio
|
---|
90 | to older kernels.</para>
|
---|
91 | </listitem>
|
---|
92 |
|
---|
93 | <listitem>
|
---|
94 | <para>For Windows 2000, XP and Vista, virtio drivers can be
|
---|
95 | downloaded and installed from the KVM project web page.<footnote>
|
---|
96 | <para><ulink
|
---|
97 | url="http://www.linux-kvm.org/page/WindowsGuestDrivers">http://www.linux-kvm.org/page/WindowsGuestDrivers</ulink>.</para>
|
---|
98 | </footnote></para>
|
---|
99 | </listitem>
|
---|
100 | </itemizedlist></para>
|
---|
101 |
|
---|
102 | <para>VirtualBox also has limited support for so-called <emphasis
|
---|
103 | role="bold">jumbo frames</emphasis>, i.e. networking packets with more
|
---|
104 | than 1500 bytes of data, provided that you use the Intel card
|
---|
105 | virtualization and bridged networking. In other words, jumbo frames are
|
---|
106 | not supported with the AMD networking devices; in those cases, jumbo
|
---|
107 | packets will silently be dropped for both the transmit and the receive
|
---|
108 | direction. Guest operating systems trying to use this feature will observe
|
---|
109 | this as a packet loss, which may lead to unexpected application behavior
|
---|
110 | in the guest. This does not cause problems with guest operating systems in
|
---|
111 | their default configuration, as jumbo frames need to be explicitly
|
---|
112 | enabled.</para>
|
---|
113 | </sect1>
|
---|
114 |
|
---|
115 | <sect1 id="networkingmodes">
|
---|
116 | <title>Introduction to networking modes</title>
|
---|
117 |
|
---|
118 | <para>Each of the eight networking adapters can be separately configured
|
---|
119 | to operate in one of the following modes:<glosslist>
|
---|
120 | <glossentry>
|
---|
121 | <glossterm>Not attached</glossterm>
|
---|
122 |
|
---|
123 | <glossdef>
|
---|
124 | <para>In this mode, VirtualBox reports to the guest that a network
|
---|
125 | card is present, but that there is no connection -- as if no
|
---|
126 | Ethernet cable was plugged into the card. This way it is possible
|
---|
127 | to "pull" the virtual Ethernet cable and disrupt the connection,
|
---|
128 | which can be useful to inform a guest operating system that no
|
---|
129 | network connection is available and enforce a
|
---|
130 | reconfiguration.</para>
|
---|
131 | </glossdef>
|
---|
132 | </glossentry>
|
---|
133 |
|
---|
134 | <glossentry>
|
---|
135 | <glossterm>Network Address Translation (NAT)</glossterm>
|
---|
136 |
|
---|
137 | <glossdef>
|
---|
138 | <para>If all you want is to browse the Web, download files and
|
---|
139 | view e-mail inside the guest, then this default mode should be
|
---|
140 | sufficient for you, and you can safely skip the rest of this
|
---|
141 | section. Please note that there are certain limitations when using
|
---|
142 | Windows file sharing (see <xref linkend="nat-limitations" /> for
|
---|
143 | details).</para>
|
---|
144 | </glossdef>
|
---|
145 | </glossentry>
|
---|
146 |
|
---|
147 | <glossentry>
|
---|
148 | <glossterm>NAT Network</glossterm>
|
---|
149 |
|
---|
150 | <glossdef>
|
---|
151 | <para>The NAT network is a new NAT flavour introduced in
|
---|
152 | VirtualBox 4.3. See
|
---|
153 | <xref linkend="network_nat_service" xrefstyle="template: %n" />
|
---|
154 | for details.</para>
|
---|
155 | </glossdef>
|
---|
156 | </glossentry>
|
---|
157 |
|
---|
158 | <glossentry>
|
---|
159 | <glossterm>Bridged networking</glossterm>
|
---|
160 |
|
---|
161 | <glossdef>
|
---|
162 | <para>This is for more advanced networking needs such as network
|
---|
163 | simulations and running servers in a guest. When enabled,
|
---|
164 | VirtualBox connects to one of your installed network cards and
|
---|
165 | exchanges network packets directly, circumventing your host
|
---|
166 | operating system's network stack.</para>
|
---|
167 | </glossdef>
|
---|
168 | </glossentry>
|
---|
169 |
|
---|
170 | <glossentry>
|
---|
171 | <glossterm>Internal networking</glossterm>
|
---|
172 |
|
---|
173 | <glossdef>
|
---|
174 | <para>This can be used to create a different kind of
|
---|
175 | software-based network which is visible to selected virtual
|
---|
176 | machines, but not to applications running on the host or to the
|
---|
177 | outside world.</para>
|
---|
178 | </glossdef>
|
---|
179 | </glossentry>
|
---|
180 |
|
---|
181 | <glossentry>
|
---|
182 | <glossterm>Host-only networking</glossterm>
|
---|
183 |
|
---|
184 | <glossdef>
|
---|
185 | <para>This can be used to create a network containing the host and
|
---|
186 | a set of virtual machines, without the need for the host's
|
---|
187 | physical network interface. Instead, a virtual network interface
|
---|
188 | (similar to a loopback interface) is created on the host,
|
---|
189 | providing connectivity among virtual machines and the host.</para>
|
---|
190 | </glossdef>
|
---|
191 | </glossentry>
|
---|
192 |
|
---|
193 | <glossentry>
|
---|
194 | <glossterm>Generic networking</glossterm>
|
---|
195 |
|
---|
196 | <glossdef>
|
---|
197 | <para>Rarely used modes share the same generic network interface,
|
---|
198 | by allowing the user to select a driver which can be included with
|
---|
199 | VirtualBox or be distributed in an extension pack.</para>
|
---|
200 |
|
---|
201 | <para>At the moment there are potentially two available
|
---|
202 | sub-modes:</para>
|
---|
203 |
|
---|
204 | <para><glosslist>
|
---|
205 | <glossentry>
|
---|
206 | <glossterm>UDP Tunnel</glossterm>
|
---|
207 |
|
---|
208 | <glossdef>
|
---|
209 | <para>This can be used to interconnect virtual machines
|
---|
210 | running on different hosts directly, easily and
|
---|
211 | transparently, over existing network
|
---|
212 | infrastructure.</para>
|
---|
213 | </glossdef>
|
---|
214 | </glossentry>
|
---|
215 |
|
---|
216 | <glossentry>
|
---|
217 | <glossterm>VDE (Virtual Distributed Ethernet)
|
---|
218 | networking</glossterm>
|
---|
219 |
|
---|
220 | <glossdef>
|
---|
221 | <para>This option can be used to connect to a Virtual
|
---|
222 | Distributed Ethernet switch on a Linux or a FreeBSD host.
|
---|
223 | At the moment this needs compiling VirtualBox from
|
---|
224 | sources, as the Oracle packages do not include it.</para>
|
---|
225 | </glossdef>
|
---|
226 | </glossentry>
|
---|
227 | </glosslist></para>
|
---|
228 | </glossdef>
|
---|
229 | </glossentry>
|
---|
230 | </glosslist></para>
|
---|
231 |
|
---|
232 | <para>The following table provides a quick overview of the most important
|
---|
233 | networking modes:</para>
|
---|
234 | <table>
|
---|
235 | <title>Overview</title>
|
---|
236 | <tgroup cols="5">
|
---|
237 | <colspec align="left" />
|
---|
238 | <colspec align="center" />
|
---|
239 | <colspec align="center" />
|
---|
240 | <colspec align="center" />
|
---|
241 | <colspec align="center" />
|
---|
242 | <thead valign="middle">
|
---|
243 | <row>
|
---|
244 | <entry></entry>
|
---|
245 | <entry><emphasis role="bold">VM ↔ Host</emphasis></entry>
|
---|
246 | <entry><emphasis role="bold">VM1 ↔ VM2</emphasis></entry>
|
---|
247 | <entry><emphasis role="bold">VM → Internet</emphasis></entry>
|
---|
248 | <entry><emphasis role="bold">VM ← Internet</emphasis></entry>
|
---|
249 | </row>
|
---|
250 | </thead>
|
---|
251 | <tbody valign="middle">
|
---|
252 | <row>
|
---|
253 | <entry>Host-only</entry>
|
---|
254 | <entry><emphasis role="bold">+</emphasis></entry>
|
---|
255 | <entry align="center"><emphasis role="bold">+</emphasis></entry>
|
---|
256 | <entry>–</entry>
|
---|
257 | <entry>–</entry>
|
---|
258 | </row>
|
---|
259 | <row>
|
---|
260 | <entry>Internal</entry>
|
---|
261 | <entry>–</entry>
|
---|
262 | <entry><emphasis role="bold">+</emphasis></entry>
|
---|
263 | <entry>–</entry>
|
---|
264 | <entry>–</entry>
|
---|
265 | </row>
|
---|
266 | <row>
|
---|
267 | <entry>Bridged</entry>
|
---|
268 | <entry><emphasis role="bold">+</emphasis></entry>
|
---|
269 | <entry><emphasis role="bold">+</emphasis></entry>
|
---|
270 | <entry><emphasis role="bold">+</emphasis></entry>
|
---|
271 | <entry><emphasis role="bold">+</emphasis></entry>
|
---|
272 | </row>
|
---|
273 | <row>
|
---|
274 | <entry>NAT</entry>
|
---|
275 | <entry>–</entry>
|
---|
276 | <entry>–</entry>
|
---|
277 | <entry><emphasis role="bold">+</emphasis></entry>
|
---|
278 | <entry><link linkend="natforward">Port forwarding</link></entry>
|
---|
279 | </row>
|
---|
280 | <row>
|
---|
281 | <entry>NAT Network</entry>
|
---|
282 | <entry>–</entry>
|
---|
283 | <entry><emphasis role="bold">+</emphasis></entry>
|
---|
284 | <entry><emphasis role="bold">+</emphasis></entry>
|
---|
285 | <entry><link linkend="network_nat_service">Port forwarding</link></entry>
|
---|
286 | </row>
|
---|
287 | </tbody>
|
---|
288 | </tgroup>
|
---|
289 | </table>
|
---|
290 |
|
---|
291 | <para>The following sections describe the available network modes in more
|
---|
292 | detail.</para>
|
---|
293 | </sect1>
|
---|
294 |
|
---|
295 | <sect1 id="network_nat">
|
---|
296 | <title>Network Address Translation (NAT)</title>
|
---|
297 |
|
---|
298 | <para>Network Address Translation (NAT) is the simplest way of accessing
|
---|
299 | an external network from a virtual machine. Usually, it does not require
|
---|
300 | any configuration on the host network and guest system. For this reason,
|
---|
301 | it is the default networking mode in VirtualBox.</para>
|
---|
302 |
|
---|
303 | <para>A virtual machine with NAT enabled acts much like a real computer
|
---|
304 | that connects to the Internet through a router. The "router", in this
|
---|
305 | case, is the VirtualBox networking engine, which maps traffic from and to
|
---|
306 | the virtual machine transparently. In VirtualBox this router is placed
|
---|
307 | between each virtual machine and the host. This separation maximizes
|
---|
308 | security since by default virtual machines cannot talk to each
|
---|
309 | other.</para>
|
---|
310 |
|
---|
311 | <para>The disadvantage of NAT mode is that, much like a private network
|
---|
312 | behind a router, the virtual machine is invisible and unreachable from the
|
---|
313 | outside internet; you cannot run a server this way unless you set up port
|
---|
314 | forwarding (described below).</para>
|
---|
315 |
|
---|
316 | <para>The network frames sent out by the guest operating system are
|
---|
317 | received by VirtualBox's NAT engine, which extracts the TCP/IP data and
|
---|
318 | resends it using the host operating system. To an application on the host,
|
---|
319 | or to another computer on the same network as the host, it looks like the
|
---|
320 | data was sent by the VirtualBox application on the host, using an IP
|
---|
321 | address belonging to the host. VirtualBox listens for replies to the
|
---|
322 | packages sent, and repacks and resends them to the guest machine on its
|
---|
323 | private network.</para>
|
---|
324 |
|
---|
325 | <para>The virtual machine receives its network address and configuration
|
---|
326 | on the private network from a DHCP server integrated into VirtualBox. The
|
---|
327 | IP address thus assigned to the virtual machine is usually on a completely
|
---|
328 | different network than the host. As more than one card of a virtual
|
---|
329 | machine can be set up to use NAT, the first card is connected to the
|
---|
330 | private network 10.0.2.0, the second card to the network 10.0.3.0 and so
|
---|
331 | on. If you need to change the guest-assigned IP range for some reason,
|
---|
332 | please refer to <xref linkend="changenat" />.</para>
|
---|
333 |
|
---|
334 | <sect2 id="natforward">
|
---|
335 | <title>Configuring port forwarding with NAT</title>
|
---|
336 |
|
---|
337 | <para>As the virtual machine is connected to a private network internal
|
---|
338 | to VirtualBox and invisible to the host, network services on the guest
|
---|
339 | are not accessible to the host machine or to other computers on the same
|
---|
340 | network. However, like a physical router, VirtualBox can make selected
|
---|
341 | services available to the world outside the guest through <emphasis
|
---|
342 | role="bold">port forwarding.</emphasis> This means that VirtualBox
|
---|
343 | listens to certain ports on the host and resends all packets which
|
---|
344 | arrive there to the guest, on the same or a different port.</para>
|
---|
345 |
|
---|
346 | <para>To an application on the host or other physical (or virtual)
|
---|
347 | machines on the network, it looks as though the service being proxied is
|
---|
348 | actually running on the host. This also means that you cannot run the
|
---|
349 | same service on the same ports on the host. However, you still gain the
|
---|
350 | advantages of running the service in a virtual machine -- for example,
|
---|
351 | services on the host machine or on other virtual machines cannot be
|
---|
352 | compromised or crashed by a vulnerability or a bug in the service, and
|
---|
353 | the service can run in a different operating system than the host
|
---|
354 | system.</para>
|
---|
355 |
|
---|
356 | <para>To configure Port Forwarding you can use the graphical Port
|
---|
357 | Forwarding editor which can be found in the Network Settings dialog
|
---|
358 | for Network Adaptors configured to use NAT. Here you can map host
|
---|
359 | ports to guest ports to allow network traffic to be routed to a
|
---|
360 | specific port in the guest.</para>
|
---|
361 |
|
---|
362 | <para>Alternatively command line tool <computeroutput>VBoxManage</computeroutput> could be used;
|
---|
363 | for details, please refer to <xref linkend="vboxmanage-modifyvm" />.</para>
|
---|
364 |
|
---|
365 | <para>You will need to know which ports on the guest the service uses
|
---|
366 | and to decide which ports to use on the host (often but not always you
|
---|
367 | will want to use the same ports on the guest and on the host). You can
|
---|
368 | use any ports on the host which are not already in use by a service. For
|
---|
369 | example, to set up incoming NAT connections to an
|
---|
370 | <computeroutput>ssh</computeroutput> server in the guest, use the
|
---|
371 | following command: <screen>VBoxManage modifyvm "VM name" --natpf1 "guestssh,tcp,,2222,,22"</screen>With
|
---|
372 | the above example, all TCP traffic arriving on port 2222 on any host
|
---|
373 | interface will be forwarded to port 22 in the guest. The protocol name
|
---|
374 | <computeroutput>tcp</computeroutput> is a mandatory attribute defining
|
---|
375 | which protocol should be used for forwarding
|
---|
376 | (<computeroutput>udp</computeroutput> could also be used). The name
|
---|
377 | <computeroutput>guestssh</computeroutput> is purely descriptive and will
|
---|
378 | be auto-generated if omitted. The number after
|
---|
379 | <computeroutput>--natpf</computeroutput> denotes the network card, like
|
---|
380 | in other parts of VBoxManage.</para>
|
---|
381 |
|
---|
382 | <para>To remove this forwarding rule again, use the following command:
|
---|
383 | <screen>VBoxManage modifyvm "VM name" --natpf1 delete "guestssh"</screen></para>
|
---|
384 |
|
---|
385 | <para>If for some reason the guest uses a static assigned IP address not
|
---|
386 | leased from the built-in DHCP server, it is required to specify the
|
---|
387 | guest IP when registering the forwarding rule: <screen>VBoxManage modifyvm "VM name" --natpf1 "guestssh,tcp,,2222,10.0.2.19,22"</screen>This
|
---|
388 | example is identical to the previous one, except that the NAT engine is
|
---|
389 | being told that the guest can be found at the 10.0.2.19 address.</para>
|
---|
390 |
|
---|
391 | <para>To forward <emphasis>all</emphasis> incoming traffic from a
|
---|
392 | specific host interface to the guest, specify the IP of that host
|
---|
393 | interface like this:<screen>VBoxManage modifyvm "VM name" --natpf1 "guestssh,tcp,127.0.0.1,2222,,22"</screen>This
|
---|
394 | forwards all TCP traffic arriving on the localhost interface (127.0.0.1)
|
---|
395 | via port 2222 to port 22 in the guest.</para>
|
---|
396 |
|
---|
397 | <para>It is possible to configure incoming NAT connections while the
|
---|
398 | VM is running, see <xref linkend="vboxmanage-controlvm"/>.</para>
|
---|
399 | </sect2>
|
---|
400 |
|
---|
401 | <sect2 id="nat-tftp">
|
---|
402 | <title>PXE booting with NAT</title>
|
---|
403 |
|
---|
404 | <para>PXE booting is now supported in NAT mode. The NAT DHCP server
|
---|
405 | provides a boot file name of the form
|
---|
406 | <computeroutput>vmname.pxe</computeroutput> if the directory
|
---|
407 | <computeroutput>TFTP</computeroutput> exists in the directory where the
|
---|
408 | user's <computeroutput>VirtualBox.xml</computeroutput> file is kept. It
|
---|
409 | is the responsibility of the user to provide
|
---|
410 | <computeroutput>vmname.pxe</computeroutput>.</para>
|
---|
411 | </sect2>
|
---|
412 |
|
---|
413 | <sect2 id="nat-limitations">
|
---|
414 | <title>NAT limitations</title>
|
---|
415 |
|
---|
416 | <para>There are four <emphasis role="bold">limitations</emphasis> of NAT
|
---|
417 | mode which users should be aware of:</para>
|
---|
418 |
|
---|
419 | <glosslist>
|
---|
420 | <glossentry>
|
---|
421 | <glossterm>ICMP protocol limitations:</glossterm>
|
---|
422 |
|
---|
423 | <glossdef>
|
---|
424 | <para>Some frequently used network debugging tools (e.g.
|
---|
425 | <computeroutput>ping</computeroutput> or tracerouting) rely on the
|
---|
426 | ICMP protocol for sending/receiving messages. While ICMP support
|
---|
427 | has been improved with VirtualBox 2.1
|
---|
428 | (<computeroutput>ping</computeroutput> should now work), some
|
---|
429 | other tools may not work reliably.</para>
|
---|
430 | </glossdef>
|
---|
431 | </glossentry>
|
---|
432 |
|
---|
433 | <glossentry>
|
---|
434 | <glossterm>Receiving of UDP broadcasts is not reliable:</glossterm>
|
---|
435 |
|
---|
436 | <glossdef>
|
---|
437 | <para>The guest does not reliably receive broadcasts, since, in
|
---|
438 | order to save resources, it only listens for a certain amount of
|
---|
439 | time after the guest has sent UDP data on a particular port. As a
|
---|
440 | consequence, NetBios name resolution based on broadcasts does not
|
---|
441 | always work (but WINS always works). As a workaround, you can use
|
---|
442 | the numeric IP of the desired server in the
|
---|
443 | <computeroutput>\\server\share</computeroutput> notation.</para>
|
---|
444 | </glossdef>
|
---|
445 | </glossentry>
|
---|
446 |
|
---|
447 | <glossentry>
|
---|
448 | <glossterm>Protocols such as GRE are unsupported:</glossterm>
|
---|
449 |
|
---|
450 | <glossdef>
|
---|
451 | <para>Protocols other than TCP and UDP are not supported. This
|
---|
452 | means some VPN products (e.g. PPTP from Microsoft) cannot be used.
|
---|
453 | There are other VPN products which use simply TCP and UDP.</para>
|
---|
454 | </glossdef>
|
---|
455 | </glossentry>
|
---|
456 |
|
---|
457 | <glossentry>
|
---|
458 | <glossterm>Forwarding host ports < 1024 impossible:</glossterm>
|
---|
459 |
|
---|
460 | <glossdef>
|
---|
461 | <para>On Unix-based hosts (e.g. Linux, Solaris, Mac OS X) it is
|
---|
462 | not possible to bind to ports below 1024 from applications that
|
---|
463 | are not run by <computeroutput>root</computeroutput>. As a result,
|
---|
464 | if you try to configure such a port forwarding, the VM will refuse
|
---|
465 | to start.</para>
|
---|
466 | </glossdef>
|
---|
467 | </glossentry>
|
---|
468 | </glosslist>
|
---|
469 |
|
---|
470 | <para>These limitations normally don't affect standard network use. But
|
---|
471 | the presence of NAT has also subtle effects that may interfere with
|
---|
472 | protocols that are normally working. One example is NFS, where the
|
---|
473 | server is often configured to refuse connections from non-privileged
|
---|
474 | ports (i.e. ports not below 1024).</para>
|
---|
475 | </sect2>
|
---|
476 | </sect1>
|
---|
477 |
|
---|
478 | <sect1 id="network_nat_service">
|
---|
479 | <title>Network Address Translation Service</title>
|
---|
480 |
|
---|
481 | <para>The Network Address Translation (NAT) service works in a similar way
|
---|
482 | to a home router, grouping the systems using it into a network and
|
---|
483 | preventing systems outside of this network from directly accessing systems
|
---|
484 | inside it, but letting systems inside communicate with each other and with
|
---|
485 | systems outside using TCP and UDP over IPv4 and IPv6.</para>
|
---|
486 |
|
---|
487 | <para>A NAT service is attached to an internal network. Virtual machines
|
---|
488 | which are to make use of it should be attached to that internal network.
|
---|
489 | The name of internal network is chosen when the NAT service is created and
|
---|
490 | the internal network will be created if it does not already exist. An
|
---|
491 | example command to create a NAT network is:
|
---|
492 | </para>
|
---|
493 | <para><screen>VBoxManage natnetwork add --netname natnet1 --network "192.168.15.0/24" --enable</screen></para>
|
---|
494 | <para>
|
---|
495 | Here, "natnet1" is the name of the internal network to be used and
|
---|
496 | "192.168.15.0/24" is the network address and mask of the NAT service
|
---|
497 | interface. By default in this static configuration the gateway will be
|
---|
498 | assigned the address 192.168.15.1 (the address following the interface
|
---|
499 | address), though this is subject to change. To attach a DHCP server to the
|
---|
500 | internal network, we modify the example as follows:</para>
|
---|
501 | <para><screen>VBoxManage natnetwork add --netname natnet1 --network "192.168.15.0/24" --enable --dhcp on</screen></para>
|
---|
502 | <para> or to add a DHCP server to the network after creation:</para>
|
---|
503 | <para><screen>VBoxManage natnetwork modify --netname natnet1 --dhcp on</screen></para>
|
---|
504 | <para>To disable it again, use:</para>
|
---|
505 | <para><screen>VBoxManage natnetwork modify --netname natnet1 --dhcp off</screen></para>
|
---|
506 | <para>DHCP server provides list of registered nameservers, but doesn't map
|
---|
507 | servers from 127/8 network.</para>
|
---|
508 | <para>To start the NAT service, use the following command:</para>
|
---|
509 | <para><screen>VBoxManage natnetwork start --netname natnet1</screen></para>
|
---|
510 | <para>If the network has a DHCP server attached then it will start together
|
---|
511 | with the NAT network service.</para>
|
---|
512 | <para><screen>VBoxManage natnetwork stop --netname natnet1</screen> stops
|
---|
513 | the NAT network service, together with DHCP server if any.</para>
|
---|
514 | <para>To delete the NAT network service use:</para>
|
---|
515 | <para><screen>VBoxManage natnetwork remove --netname natnet1</screen></para>
|
---|
516 | <para>This command does not remove the DHCP server if one is enabled on the
|
---|
517 | internal network.</para>
|
---|
518 | <para>Port-forwarding is supported (using the
|
---|
519 | <computeroutput>--port-forward-4</computeroutput> switch for IPv4 and
|
---|
520 | <computeroutput>--port-forward-6</computeroutput>
|
---|
521 | for IPv6):</para>
|
---|
522 | <para><screen>VBoxManage natnetwork modify --netname natnet1 --port-forward-4 "ssh:tcp:[]:1022:[192.168.15.5]:22"</screen></para>
|
---|
523 | <para>This adds a port-forwarding rule from the host's TCP 1022 port to
|
---|
524 | the port 22 on the guest with IP address 192.168.15.5. Host port, guest port and guest IP
|
---|
525 | are mandatory. To delete the rule, use:</para>
|
---|
526 | <para><screen>VBoxManage natnetwork modify --netname natnet1 --port-forward-4 delete ssh</screen></para>
|
---|
527 | <para>It's possible to bind NAT service to specified interface:</para>
|
---|
528 | <screen>VBoxManage setextradata global "NAT/win-nat-test-0/SourceIp4" 192.168.1.185</screen>
|
---|
529 | <para>To see the list of registered NAT networks, use:</para>
|
---|
530 | <para><screen>VBoxManage list natnetworks</screen></para>
|
---|
531 | </sect1>
|
---|
532 |
|
---|
533 | <sect1 id="network_bridged">
|
---|
534 | <title>Bridged networking</title>
|
---|
535 |
|
---|
536 | <para>With bridged networking, VirtualBox uses a device driver on your
|
---|
537 | <emphasis>host</emphasis> system that filters data from your physical
|
---|
538 | network adapter. This driver is therefore called a "net filter" driver.
|
---|
539 | This allows VirtualBox to intercept data from the physical network and
|
---|
540 | inject data into it, effectively creating a new network interface in
|
---|
541 | software. When a guest is using such a new software interface, it looks to
|
---|
542 | the host system as though the guest were physically connected to the
|
---|
543 | interface using a network cable: the host can send data to the guest
|
---|
544 | through that interface and receive data from it. This means that you can
|
---|
545 | set up routing or bridging between the guest and the rest of your
|
---|
546 | network.</para>
|
---|
547 |
|
---|
548 | <para>For this to work, VirtualBox needs a device driver on your host
|
---|
549 | system. The way bridged networking works has been completely rewritten
|
---|
550 | with VirtualBox 2.0 and 2.1, depending on the host operating system. From
|
---|
551 | the user perspective, the main difference is that complex configuration is
|
---|
552 | no longer necessary on any of the supported host operating
|
---|
553 | systems.<footnote>
|
---|
554 | <para>For Mac OS X and Solaris hosts, net filter drivers were already
|
---|
555 | added in VirtualBox 2.0 (as initial support for Host Interface
|
---|
556 | Networking on these platforms). With VirtualBox 2.1, net filter
|
---|
557 | drivers were also added for the Windows and Linux hosts, replacing the
|
---|
558 | mechanisms previously present in VirtualBox for those platforms;
|
---|
559 | especially on Linux, the earlier method required creating TAP
|
---|
560 | interfaces and bridges, which was complex and varied from one
|
---|
561 | distribution to the next. None of this is necessary anymore. Bridged
|
---|
562 | network was formerly called "Host Interface Networking" and has been
|
---|
563 | renamed with version 2.2 without any change in functionality.</para>
|
---|
564 | </footnote></para>
|
---|
565 |
|
---|
566 | <para><note>
|
---|
567 | <para>Even though TAP is no longer necessary on Linux with bridged
|
---|
568 | networking, you <emphasis>can</emphasis> still use TAP interfaces for
|
---|
569 | certain advanced setups, since you can connect a VM to any host
|
---|
570 | interface -- which could also be a TAP interface.</para>
|
---|
571 | </note>To enable bridged networking, all you need to do is to open the
|
---|
572 | Settings dialog of a virtual machine, go to the "Network" page and select
|
---|
573 | "Bridged network" in the drop down list for the "Attached to" field.
|
---|
574 | Finally, select desired host interface from the list at the bottom of the
|
---|
575 | page, which contains the physical network interfaces of your systems. On a
|
---|
576 | typical MacBook, for example, this will allow you to select between "en1:
|
---|
577 | AirPort" (which is the wireless interface) and "en0: Ethernet", which
|
---|
578 | represents the interface with a network cable.</para>
|
---|
579 |
|
---|
580 | <note><para>Bridging to a wireless interface is done differently from
|
---|
581 | bridging to a wired interface, because most wireless adapters do not
|
---|
582 | support promiscuous mode. All traffic has to use the MAC address of the
|
---|
583 | host's wireless adapter, and therefore VirtualBox needs to replace the
|
---|
584 | source MAC address in the Ethernet header of an outgoing packet to make
|
---|
585 | sure the reply will be sent to the host interface. When VirtualBox sees
|
---|
586 | an incoming packet with a destination IP address that belongs to one of
|
---|
587 | the virtual machine adapters it replaces the destination MAC address in
|
---|
588 | the Ethernet header with the VM adapter's MAC address and passes it on.
|
---|
589 | VirtualBox examines ARP and DHCP packets in order to learn the IP
|
---|
590 | addresses of virtual machines.</para></note>
|
---|
591 |
|
---|
592 | <para>Depending on your host operating system, the following limitations
|
---|
593 | should be kept in mind:<itemizedlist>
|
---|
594 | <listitem>
|
---|
595 | <para>On <emphasis role="bold">Macintosh</emphasis> hosts,
|
---|
596 | functionality is limited when using AirPort (the Mac's wireless
|
---|
597 | networking) for bridged networking. Currently, VirtualBox supports
|
---|
598 | only IPv4 and IPv6 over AirPort. For other protocols (such as IPX),
|
---|
599 | you must choose a wired interface.</para>
|
---|
600 | </listitem>
|
---|
601 |
|
---|
602 | <listitem>
|
---|
603 | <para>On <emphasis role="bold">Linux</emphasis> hosts, functionality
|
---|
604 | is limited when using wireless interfaces for bridged networking.
|
---|
605 | Currently, VirtualBox supports only IPv4 and IPv6 over wireless.
|
---|
606 | For other protocols (such as IPX), you must choose a wired
|
---|
607 | interface.</para>
|
---|
608 |
|
---|
609 | <para>Also, setting the MTU to less than 1500 bytes on wired
|
---|
610 | interfaces provided by the sky2 driver on the Marvell Yukon II EC
|
---|
611 | Ultra Ethernet NIC is known to cause packet losses under certain
|
---|
612 | conditions.</para>
|
---|
613 |
|
---|
614 | <para>Some adapters strip VLAN tags in hardware. This does not allow
|
---|
615 | to use VLAN trunking between VM and the external network with
|
---|
616 | pre-2.6.27 Linux kernels nor with host operating systems other than
|
---|
617 | Linux.</para>
|
---|
618 | </listitem>
|
---|
619 |
|
---|
620 | <listitem>
|
---|
621 | <para>On <emphasis role="bold">Solaris</emphasis> hosts, there is no
|
---|
622 | support for using wireless interfaces. Filtering guest traffic using
|
---|
623 | IPFilter is also not completely supported due to technical
|
---|
624 | restrictions of the Solaris networking subsystem. These issues would
|
---|
625 | be addressed in a future release of Solaris 11.</para>
|
---|
626 |
|
---|
627 | <para>Starting with VirtualBox 4.1, on Solaris 11 hosts (build 159
|
---|
628 | and above), it is possible to use Solaris' Crossbow Virtual Network
|
---|
629 | Interfaces (VNICs) directly with VirtualBox without any additional
|
---|
630 | configuration other than each VNIC must be exclusive for every guest
|
---|
631 | network interface.</para>
|
---|
632 |
|
---|
633 | <para>Starting with VirtualBox 2.0.4 and up to VirtualBox 4.0, VNICs
|
---|
634 | can be used but with the following caveats:</para>
|
---|
635 |
|
---|
636 | <itemizedlist>
|
---|
637 | <listitem>
|
---|
638 | <para>A VNIC cannot be shared between multiple guest network
|
---|
639 | interfaces, i.e. each guest network interface must have its own,
|
---|
640 | exclusive VNIC.</para>
|
---|
641 | </listitem>
|
---|
642 |
|
---|
643 | <listitem>
|
---|
644 | <para>The VNIC and the guest network interface that uses the
|
---|
645 | VNIC must be assigned identical MAC addresses.</para>
|
---|
646 | </listitem>
|
---|
647 | </itemizedlist>
|
---|
648 |
|
---|
649 | <para>When using VLAN interfaces with VirtualBox, they must be named
|
---|
650 | according to the PPA-hack naming scheme (e.g. "e1000g513001"), as
|
---|
651 | otherwise the guest may receive packets in an unexpected
|
---|
652 | format.</para>
|
---|
653 | </listitem>
|
---|
654 | </itemizedlist></para>
|
---|
655 | </sect1>
|
---|
656 |
|
---|
657 | <sect1 id="network_internal">
|
---|
658 | <title>Internal networking</title>
|
---|
659 |
|
---|
660 | <para>Internal Networking is similar to bridged networking in that the VM
|
---|
661 | can directly communicate with the outside world. However, the "outside
|
---|
662 | world" is limited to other VMs on the same host which connect to the same
|
---|
663 | internal network.</para>
|
---|
664 |
|
---|
665 | <para>Even though technically, everything that can be done using internal
|
---|
666 | networking can also be done using bridged networking, there are security
|
---|
667 | advantages with internal networking. In bridged networking mode, all
|
---|
668 | traffic goes through a physical interface of the host system. It is
|
---|
669 | therefore possible to attach a packet sniffer (such as Wireshark) to the
|
---|
670 | host interface and log all traffic that goes over it. If, for any reason,
|
---|
671 | you prefer two or more VMs on the same machine to communicate privately,
|
---|
672 | hiding their data from both the host system and the user, bridged
|
---|
673 | networking therefore is not an option.</para>
|
---|
674 |
|
---|
675 | <para>Internal networks are created automatically as needed, i.e. there is
|
---|
676 | no central configuration. Every internal network is identified simply by
|
---|
677 | its name. Once there is more than one active virtual network card with the
|
---|
678 | same internal network ID, the VirtualBox support driver will automatically
|
---|
679 | "wire" the cards and act as a network switch. The VirtualBox support
|
---|
680 | driver implements a complete Ethernet switch and supports both
|
---|
681 | broadcast/multicast frames and promiscuous mode.</para>
|
---|
682 |
|
---|
683 | <para>In order to attach a VM's network card to an internal network, set
|
---|
684 | its networking mode to "internal networking". There are two ways to
|
---|
685 | accomplish this:</para>
|
---|
686 |
|
---|
687 | <para><itemizedlist>
|
---|
688 | <listitem>
|
---|
689 | <para>You can use a VM's "Settings" dialog in the VirtualBox
|
---|
690 | graphical user interface. In the "Networking" category of the
|
---|
691 | settings dialog, select "Internal Networking" from the drop-down
|
---|
692 | list of networking modes. Now select the name of an existing
|
---|
693 | internal network from the drop-down below or enter a new name into
|
---|
694 | the entry field.</para>
|
---|
695 | </listitem>
|
---|
696 |
|
---|
697 | <listitem>
|
---|
698 | <para>You can use <screen>VBoxManage modifyvm "VM name" --nic<x> intnet</screen>
|
---|
699 | Optionally, you can specify a network name with the command <screen>VBoxManage modifyvm "VM name" --intnet<x> "network name"</screen>
|
---|
700 | If you do not specify a network name, the network card will be
|
---|
701 | attached to the network <computeroutput>intnet</computeroutput> by
|
---|
702 | default.</para>
|
---|
703 | </listitem>
|
---|
704 | </itemizedlist></para>
|
---|
705 |
|
---|
706 | <para>Unless you configure the (virtual) network cards in the guest
|
---|
707 | operating systems that are participating in the internal network to use
|
---|
708 | static IP addresses, you may want to use the DHCP server that is built
|
---|
709 | into VirtualBox to manage IP addresses for the internal network. Please
|
---|
710 | see <xref linkend="vboxmanage-dhcpserver" /> for details.</para>
|
---|
711 |
|
---|
712 | <para>As a security measure, by default, the Linux implementation of internal
|
---|
713 | networking only allows VMs running under the same user ID to establish an
|
---|
714 | internal network. However, it is possible to create a shared
|
---|
715 | internal networking interface, accessible by users with different UUIds.</para>
|
---|
716 | </sect1>
|
---|
717 |
|
---|
718 | <sect1 id="network_hostonly">
|
---|
719 | <title>Host-only networking</title>
|
---|
720 |
|
---|
721 | <para>Host-only networking is another networking mode that was added with
|
---|
722 | version 2.2 of VirtualBox. It can be thought of as a hybrid between the
|
---|
723 | bridged and internal networking modes: as with bridged networking, the
|
---|
724 | virtual machines can talk to each other and the host as if they were
|
---|
725 | connected through a physical Ethernet switch. Similarly, as with internal
|
---|
726 | networking however, a physical networking interface need not be present,
|
---|
727 | and the virtual machines cannot talk to the world outside the host since
|
---|
728 | they are not connected to a physical networking interface.</para>
|
---|
729 |
|
---|
730 | <para>Instead, when host-only networking is used, VirtualBox creates a new
|
---|
731 | software interface on the host which then appears next to your existing
|
---|
732 | network interfaces. In other words, whereas with bridged networking an
|
---|
733 | existing physical interface is used to attach virtual machines to, with
|
---|
734 | host-only networking a new "loopback" interface is created on the host.
|
---|
735 | And whereas with internal networking, the traffic between the virtual
|
---|
736 | machines cannot be seen, the traffic on the "loopback" interface on the
|
---|
737 | host can be intercepted.</para>
|
---|
738 |
|
---|
739 | <para>Host-only networking is particularly useful for preconfigured
|
---|
740 | virtual appliances, where multiple virtual machines are shipped together
|
---|
741 | and designed to cooperate. For example, one virtual machine may contain a
|
---|
742 | web server and a second one a database, and since they are intended to
|
---|
743 | talk to each other, the appliance can instruct VirtualBox to set up a
|
---|
744 | host-only network for the two. A second (bridged) network would then
|
---|
745 | connect the web server to the outside world to serve data to, but the
|
---|
746 | outside world cannot connect to the database.</para>
|
---|
747 |
|
---|
748 | <para>To change a virtual machine's virtual network interface to "host
|
---|
749 | only" mode:<itemizedlist>
|
---|
750 | <listitem>
|
---|
751 | <para>either go to the "Network" page in the virtual machine's
|
---|
752 | settings notebook in the graphical user interface and select
|
---|
753 | "Host-only networking", or</para>
|
---|
754 | </listitem>
|
---|
755 |
|
---|
756 | <listitem>
|
---|
757 | <para>on the command line, type <computeroutput>VBoxManage modifyvm
|
---|
758 | "VM name" --nic<x> hostonly</computeroutput>; see <xref
|
---|
759 | linkend="vboxmanage-modifyvm" /> for details.</para>
|
---|
760 | </listitem>
|
---|
761 | </itemizedlist></para>
|
---|
762 |
|
---|
763 | <para>Before you can attach a VM to a host-only network you have to
|
---|
764 | create at least one host-only interface, either from the GUI:
|
---|
765 | "File" → "Preferences" → "Network" → "Host-only network"
|
---|
766 | → "(+)Add host-only network", or via command line with</para>
|
---|
767 | <screen>VBoxManage hostonlyif create</screen>
|
---|
768 | <para>see <xref linkend="vboxmanage-hostonlyif" /> for details.</para>
|
---|
769 |
|
---|
770 | <para>For host-only networking, like with internal networking, you may
|
---|
771 | find the DHCP server useful that is built into VirtualBox. This can be
|
---|
772 | enabled to then manage the IP addresses in the host-only network since
|
---|
773 | otherwise you would need to configure all IP addresses
|
---|
774 | statically.<itemizedlist>
|
---|
775 | <listitem>
|
---|
776 | <para>In the VirtualBox graphical user interface, you can configure
|
---|
777 | all these items in the global settings via "File" → "Preferences"
|
---|
778 | → "Network", which lists all host-only networks which are
|
---|
779 | presently in use. Click on the network name and then on the "Edit"
|
---|
780 | button to the right, and you can modify the adapter and DHCP
|
---|
781 | settings.</para>
|
---|
782 | </listitem>
|
---|
783 |
|
---|
784 | <listitem>
|
---|
785 | <para>Alternatively, you can use <computeroutput>VBoxManage
|
---|
786 | dhcpserver</computeroutput> on the command line; please see <xref
|
---|
787 | linkend="vboxmanage-dhcpserver" /> for details.</para>
|
---|
788 | </listitem>
|
---|
789 | </itemizedlist>
|
---|
790 | </para>
|
---|
791 |
|
---|
792 | <para><note><para>On Linux and Mac OS X hosts the number of host-only
|
---|
793 | interfaces is limited to 128. There is no such limit for Solaris and
|
---|
794 | Windows hosts.</para></note></para>
|
---|
795 | </sect1>
|
---|
796 |
|
---|
797 | <sect1 id="network_udp_tunnel">
|
---|
798 | <title>UDP Tunnel networking</title>
|
---|
799 |
|
---|
800 | <para>This networking mode allows to interconnect virtual machines running
|
---|
801 | on different hosts.</para>
|
---|
802 |
|
---|
803 | <para>Technically this is done by encapsulating Ethernet frames sent or
|
---|
804 | received by the guest network card into UDP/IP datagrams, and sending them
|
---|
805 | over any network available to the host.</para>
|
---|
806 |
|
---|
807 | <para>UDP Tunnel mode has three parameters:<glosslist>
|
---|
808 | <glossentry>
|
---|
809 | <glossterm>Source UDP port</glossterm>
|
---|
810 |
|
---|
811 | <glossdef>
|
---|
812 | <para>The port on which the host listens. Datagrams arriving on
|
---|
813 | this port from any source address will be forwarded to the
|
---|
814 | receiving part of the guest network card.</para>
|
---|
815 | </glossdef>
|
---|
816 | </glossentry>
|
---|
817 |
|
---|
818 | <glossentry>
|
---|
819 | <glossterm>Destination address</glossterm>
|
---|
820 |
|
---|
821 | <glossdef>
|
---|
822 | <para>IP address of the target host of the transmitted
|
---|
823 | data.</para>
|
---|
824 | </glossdef>
|
---|
825 | </glossentry>
|
---|
826 |
|
---|
827 | <glossentry>
|
---|
828 | <glossterm>Destination UDP port</glossterm>
|
---|
829 |
|
---|
830 | <glossdef>
|
---|
831 | <para>Port number to which the transmitted data is sent.</para>
|
---|
832 | </glossdef>
|
---|
833 | </glossentry>
|
---|
834 | </glosslist></para>
|
---|
835 |
|
---|
836 | <para>When interconnecting two virtual machines on two different hosts,
|
---|
837 | their IP addresses must be swapped. On single host, source and destination
|
---|
838 | UDP ports must be swapped.</para>
|
---|
839 |
|
---|
840 | <para>In the following example host 1 uses the IP address 10.0.0.1 and
|
---|
841 | host 2 uses IP address 10.0.0.2. Configuration via command-line:<screen> VBoxManage modifyvm "VM 01 on host 1" --nic<x> generic
|
---|
842 | VBoxManage modifyvm "VM 01 on host 1" --nicgenericdrv<x> UDPTunnel
|
---|
843 | VBoxManage modifyvm "VM 01 on host 1" --nicproperty<x> dest=10.0.0.2
|
---|
844 | VBoxManage modifyvm "VM 01 on host 1" --nicproperty<x> sport=10001
|
---|
845 | VBoxManage modifyvm "VM 01 on host 1" --nicproperty<x> dport=10002</screen>
|
---|
846 | and <screen> VBoxManage modifyvm "VM 02 on host 2" --nic<y> generic
|
---|
847 | VBoxManage modifyvm "VM 02 on host 2" --nicgenericdrv<y> UDPTunnel
|
---|
848 | VBoxManage modifyvm "VM 02 on host 2" --nicproperty<y> dest=10.0.0.1
|
---|
849 | VBoxManage modifyvm "VM 02 on host 2" --nicproperty<y> sport=10002
|
---|
850 | VBoxManage modifyvm "VM 02 on host 2" --nicproperty<y> dport=10001</screen></para>
|
---|
851 |
|
---|
852 | <para>Of course, you can always interconnect two virtual machines on the
|
---|
853 | same host, by setting the destination address parameter to 127.0.0.1 on
|
---|
854 | both. It will act similarly to "Internal network" in this case, however
|
---|
855 | the host can see the network traffic which it could not in the normal
|
---|
856 | Internal network case.</para>
|
---|
857 |
|
---|
858 | <para><note><para>On Unix-based hosts (e.g. Linux, Solaris, Mac OS X) it is
|
---|
859 | not possible to bind to ports below 1024 from applications that are not run
|
---|
860 | by <computeroutput>root</computeroutput>. As a result, if you try to
|
---|
861 | configure such a source UDP port, the VM will refuse to
|
---|
862 | start.</para></note></para>
|
---|
863 | </sect1>
|
---|
864 |
|
---|
865 | <sect1 id="network_vde">
|
---|
866 | <title>VDE networking</title>
|
---|
867 |
|
---|
868 | <para>Virtual Distributed Ethernet (VDE<footnote>
|
---|
869 | <para>VDE is a project developed by Renzo Davoli, Associate Professor
|
---|
870 | at the University of Bologna, Italy.</para>
|
---|
871 | </footnote>) is a flexible, virtual network infrastructure system,
|
---|
872 | spanning across multiple hosts in a secure way. It allows for L2/L3
|
---|
873 | switching, including spanning-tree protocol, VLANs, and WAN emulation. It
|
---|
874 | is an optional part of VirtualBox which is only included in the source
|
---|
875 | code.</para>
|
---|
876 |
|
---|
877 | <para>The basic building blocks of the infrastructure are VDE switches,
|
---|
878 | VDE plugs and VDE wires which inter-connect the switches.</para>
|
---|
879 |
|
---|
880 | <para>The VirtualBox VDE driver has one parameter:<glosslist>
|
---|
881 | <glossentry>
|
---|
882 | <glossterm>VDE network</glossterm>
|
---|
883 |
|
---|
884 | <glossdef>
|
---|
885 | <para>The name of the VDE network switch socket to which the VM
|
---|
886 | will be connected.</para>
|
---|
887 | </glossdef>
|
---|
888 | </glossentry>
|
---|
889 | </glosslist></para>
|
---|
890 |
|
---|
891 | <para>The following basic example shows how to connect a virtual machine
|
---|
892 | to a VDE switch:</para>
|
---|
893 |
|
---|
894 | <para><orderedlist>
|
---|
895 | <listitem>
|
---|
896 | <para>Create a VDE switch: <screen>vde_switch -s /tmp/switch1</screen></para>
|
---|
897 | </listitem>
|
---|
898 |
|
---|
899 | <listitem>
|
---|
900 | <para>Configuration via command-line: <screen>VBoxManage modifyvm "VM name" --nic<x> generic</screen>
|
---|
901 | <screen>VBoxManage modifyvm "VM name" --nicgenericdrv<x> VDE</screen>
|
---|
902 | To connect to automatically allocated switch port, use: <screen>VBoxManage modifyvm "VM name" --nicproperty<x> network=/tmp/switch1</screen>
|
---|
903 | To connect to specific switch port <n>, use: <screen>VBoxManage modifyvm "VM name" --nicproperty<x> network=/tmp/switch1[<n>]</screen>
|
---|
904 | The latter option can be useful for VLANs.</para>
|
---|
905 | </listitem>
|
---|
906 |
|
---|
907 | <listitem>
|
---|
908 | <para>Optionally map between VDE switch port and VLAN: (from switch
|
---|
909 | CLI) <screen>vde$ vlan/create <VLAN></screen> <screen>vde$ port/setvlan <port> <VLAN></screen></para>
|
---|
910 | </listitem>
|
---|
911 | </orderedlist></para>
|
---|
912 |
|
---|
913 | <para>VDE is available on Linux and FreeBSD hosts only. It is only
|
---|
914 | available if the VDE software and the VDE plugin library from the
|
---|
915 | VirtualSquare project are installed on the host system<footnote>
|
---|
916 | <para>For Linux hosts, the shared library libvdeplug.so must be
|
---|
917 | available in the search path for shared libraries</para>
|
---|
918 | </footnote>. For more information on setting up VDE networks, please see
|
---|
919 | the documentation accompanying the software.<footnote>
|
---|
920 | <para><ulink
|
---|
921 | url="http://wiki.virtualsquare.org/wiki/index.php/VDE_Basic_Networking">http://wiki.virtualsquare.org/wiki/index.php/VDE_Basic_Networking</ulink>.</para>
|
---|
922 | </footnote></para>
|
---|
923 | </sect1>
|
---|
924 |
|
---|
925 | <sect1 id="network_bandwidth_limit">
|
---|
926 | <title>Limiting bandwidth for network I/O</title>
|
---|
927 |
|
---|
928 | <para>Starting with version 4.2, VirtualBox allows for limiting the
|
---|
929 | maximum bandwidth used for network transmission. Several network adapters
|
---|
930 | of one VM may share limits through bandwidth groups. It is possible
|
---|
931 | to have more than one such limit.</para>
|
---|
932 | <note><para>VirtualBox shapes VM traffic only in the transmit direction,
|
---|
933 | delaying the packets being sent by virtual machines. It does not limit
|
---|
934 | the traffic being received by virtual machines.</para>
|
---|
935 | </note>
|
---|
936 |
|
---|
937 | <para>Limits are configured through
|
---|
938 | <computeroutput>VBoxManage</computeroutput>. The example below creates a
|
---|
939 | bandwidth group named "Limit", sets the limit to 20 Mbit/s and assigns the
|
---|
940 | group to the first and second adapters of the VM:<screen>VBoxManage bandwidthctl "VM name" add Limit --type network --limit 20m
|
---|
941 | VBoxManage modifyvm "VM name" --nicbandwidthgroup1 Limit
|
---|
942 | VBoxManage modifyvm "VM name" --nicbandwidthgroup2 Limit</screen></para>
|
---|
943 |
|
---|
944 | <para>All adapters in a group share the bandwidth limit, meaning that in the
|
---|
945 | example above the bandwidth of both adapters combined can never exceed 20
|
---|
946 | Mbit/s. However, if one adapter doesn't require bandwidth the other can use the
|
---|
947 | remaining bandwidth of its group.</para>
|
---|
948 |
|
---|
949 | <para>The limits for each group can be changed while the VM is running,
|
---|
950 | with changes being picked up immediately. The example below changes the
|
---|
951 | limit for the group created in the example above to 100 Kbit/s:<screen>VBoxManage bandwidthctl "VM name" set Limit --limit 100k</screen></para>
|
---|
952 |
|
---|
953 | <para>To completely disable shaping for the first adapter of VM use the
|
---|
954 | following command:
|
---|
955 | <screen>VBoxManage modifyvm "VM name" --nicbandwidthgroup1 none</screen></para>
|
---|
956 |
|
---|
957 | <para>It is also possible to disable shaping for all adapters assigned to a
|
---|
958 | bandwidth group while VM is running, by specifying the zero limit for the
|
---|
959 | group. For example, for the bandwidth group named "Limit" use:
|
---|
960 | <screen>VBoxManage bandwidthctl "VM name" set Limit --limit 0</screen></para>
|
---|
961 | </sect1>
|
---|
962 | <sect1 id="network_performance">
|
---|
963 | <title>Improving network performance</title>
|
---|
964 |
|
---|
965 | <para>VirtualBox provides a variety of virtual network adapters that can be
|
---|
966 | "attached" to the host's network in a number of ways. Depending on which
|
---|
967 | types of adapters and attachments are used the network performance will
|
---|
968 | be different. Performance-wise the <emphasis>virtio</emphasis> network
|
---|
969 | adapter is preferable over <emphasis>Intel PRO/1000</emphasis> emulated
|
---|
970 | adapters, which are preferred over <emphasis>PCNet</emphasis> family of
|
---|
971 | adapters. Both <emphasis>virtio</emphasis> and <emphasis>Intel PRO/1000
|
---|
972 | </emphasis> adapters enjoy the benefit of segmentation and checksum
|
---|
973 | offloading. Segmentation offloading is essential for high performance as
|
---|
974 | it allows for less context switches, dramatically increasing the sizes
|
---|
975 | of packets that cross VM/host boundary.</para>
|
---|
976 | <note><para>Neither <emphasis>virtio</emphasis> nor <emphasis>Intel PRO/1000
|
---|
977 | </emphasis> drivers for Windows XP support segmentation
|
---|
978 | offloading. Therefore Windows XP guests never reach the same
|
---|
979 | transmission rates as other guest types. Refer to MS Knowledge base
|
---|
980 | article 842264 for additional information.</para>
|
---|
981 | </note>
|
---|
982 | <para>Three attachment types: <emphasis>internal</emphasis>,
|
---|
983 | <emphasis>bridged</emphasis> and <emphasis>host-only</emphasis>, have
|
---|
984 | nearly identical performance, the <emphasis>internal</emphasis> type
|
---|
985 | being a little bit faster and using less CPU cycles as the packets never
|
---|
986 | reach the host's network stack. The <emphasis>NAT</emphasis> attachment
|
---|
987 | is the slowest (and safest) of all attachment types as it provides
|
---|
988 | network address translation. The generic driver attachment is special and
|
---|
989 | cannot be considered as an alternative to other attachment types.</para>
|
---|
990 | <para>The number of CPUs assigned to VM does not improve network
|
---|
991 | performance and in some cases may hurt it due to increased concurrency in
|
---|
992 | the guest.</para>
|
---|
993 | <para>Here is the short summary of things to check in order to improve
|
---|
994 | network performance:</para>
|
---|
995 | <para><orderedlist>
|
---|
996 | <listitem>
|
---|
997 | <para>Whenever possible use <emphasis>virtio</emphasis> network
|
---|
998 | adapter, otherwise use one of <emphasis>Intel PRO/1000</emphasis>
|
---|
999 | adapters;</para>
|
---|
1000 | </listitem>
|
---|
1001 | <listitem>
|
---|
1002 | <para>Use <emphasis>bridged</emphasis> attachment instead of
|
---|
1003 | <emphasis>NAT</emphasis>;</para>
|
---|
1004 | </listitem>
|
---|
1005 | <listitem>
|
---|
1006 | <para>Make sure segmentation offloading is enabled in the guest OS.
|
---|
1007 | Usually it will be enabled by default. You can check and modify
|
---|
1008 | offloading settings using <computeroutput>ethtool</computeroutput>
|
---|
1009 | command in Linux guests.</para>
|
---|
1010 | </listitem>
|
---|
1011 | <listitem>
|
---|
1012 | <para>Perform a full, detailed analysis of network traffic on
|
---|
1013 | the VM's network adaptor using a 3rd party tool such as Wireshark.
|
---|
1014 | To do this, a promiscuous mode policy needs to be used on the
|
---|
1015 | VM's network adaptor. Use of this mode is only possible on
|
---|
1016 | networks: NAT Network, Bridged Adapter, Internal Network and Host-only Adapter.</para>
|
---|
1017 | <para>To setup a promiscuous mode policy, either select from the drop down list
|
---|
1018 | located in the Network Settings dialog for the network adaptor
|
---|
1019 | or use the command line tool <computeroutput>VBoxManage</computeroutput>;
|
---|
1020 | for details, refer to <xref linkend="vboxmanage-modifyvm" />.</para>
|
---|
1021 | <para>Promiscuous mode policies are: </para>
|
---|
1022 | <para><orderedlist>
|
---|
1023 | <listitem>
|
---|
1024 | <para><computeroutput>deny</computeroutput> (default setting) which hides
|
---|
1025 | any traffic not intended for this VM's network adaptor.</para>
|
---|
1026 | </listitem>
|
---|
1027 | <listitem>
|
---|
1028 | <para><computeroutput>allow-vms</computeroutput> which hides all host
|
---|
1029 | traffic from this VM's network adaptor, but allows it to see traffic from/to other
|
---|
1030 | VMs.</para>
|
---|
1031 | </listitem>
|
---|
1032 | <listitem>
|
---|
1033 | <para><computeroutput>allow-all</computeroutput> which removes all
|
---|
1034 | restrictions - this VM's network adaptor sees all traffic.</para>
|
---|
1035 | </listitem>
|
---|
1036 | </orderedlist></para>
|
---|
1037 | </listitem>
|
---|
1038 | </orderedlist></para>
|
---|
1039 | </sect1>
|
---|
1040 | </chapter>
|
---|