Все это в точности совпадает с настройками интерфейса eth0 в UML:

uml:~ # ifconfig eth0

eth0      Link encap:Ethernet  HWaddr FE:FD:C0:A8:01:00

          inet addr:192.168.254.2  Bcast:192.168.254.255  Mask:255.255.255.0

          inet6 addr: fe80::fcfd:c0ff:fea8:100/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:103 errors:0 dropped:0 overruns:0 frame:0

          TX packets:7 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:18261 (17.8 Kb)  TX bytes:518 (518.0 b)

          Interrupt:5

Таким образом, продемонстрирована работоспособность полностью виртуальной сети. В данном случае необходимость такой сети вызвана тем, что нужно было создать средство «общения» запускаемых виртуальных машин с хостовым сервером.

Например, им всем через внутреннюю сеть «раздается» рабочий дистрибутив:

server:~ # showmount -e

Export list for server:

/srv/susedvd/SU1000_001 192.168.254.0/255.255.255.0,localhost

Эта связь может стать особенно важной, если сам сервер не будет иметь иного способа подключиться к гостевой машине. Спросите, как это может быть? Очень просто! Для этого рассмотрим второй виртуальный интерфейс на рис. 3, который подключает и сервер, и его гостевую ОС к локальной сети. Для этого используется мост eth0:

server:~ # brctl show

bridge name     bridge id               STP enabled     interfaces

eth0            8000.000479661b70       no              hweth3

                                                        hweth5

                                                        tap1