LXF137:libvirt

Материал из Linuxformat.

Се­ти в libvirt

libvirt: В виртуальной паутине

Дмит­рий Ми­хи­рев вы­звал­ся ра­зо­брать­ся в на­строй­ках се­тей libvirt. На его удив­ле­ние, там всё ока­за­лось до­воль­но про­сто.

В LXF132 Грэм Мор­ри­сон рас­ска­зал мно­го ин­те­рес­но­го про ра­бо­ту с вир­ту­аль­ной ма­ши­ной KVM. Про­чи­тав­шие его ста­тью на­вер­ня­ка убе­ди­лись, что в её ис­поль­зо­вании нет ниче­го слож­но­го: да­же не осо­бо под­го­тов­лен­ный поль­зо­ва­тель мо­жет соз­дать и на­стро­ить «вир­ту­ал­ку» с по­мо­щью virt-manager и уста­но­вить на неё лю­бую ОС. Во­прос на­строй­ки се­те­во­го со­единения для вир­ту­аль­ной ма­ши­ны, од­на­ко, остал­ся неза­тро­ну­тым, а ведь по­треб­ность в этом возника­ет очень часто. По­про­бу­ем восполнить дан­ное упу­щение.

До­ба­вим вир­ту­аль­но­сти

Итак, что же нам по­на­до­бит­ся? Ра­зу­ме­ет­ся, это сам мо­дуль kvm, QEMU, на­бор ути­лит libvirt и гра­фи­че­ская обо­лоч­ка virt-manager. Я бу­ду ис­поль­зо­вать Mandriva, в ко­то­рой kvm вхо­дит в стан­дарт­ную ком­плек­та­цию яд­ра. Оста­ёт­ся доуста­но­вить па­ке­ты qemu, libvirt-utils, virt-manager, а так­же, для экс­пе­ри­мен­тов с се­тью, bridge-utils. Это де­ла­ет­ся при по­мо­щи коман­ды

su -c “urpmi qemu libvirt-utils virt-manager bridge-utils”

В дру­гих ди­ст­ри­бу­ти­вах на­зва­ния па­ке­тов, ко­неч­но, мо­гут от­ли­чать­ся, но на­бор по­тре­бу­ет­ся та­кой же.

Те­перь ос­та­лось толь­ко за­пус­тить де­мон libvirtd ко­ман­дой

su -c “service libvirtd start”

и мож­но при­сту­пить к на­строй­ке се­ти. Для на­ча­ла про­сто по­смот­рим, что нам пред­ла­га­ет­ся по умол­чанию. Для это­го за­пустим virt-manager и от­кро­ем пункт ме­ню Прав­ка > Па­ра­мет­ры хоста. Здесь на вклад­ке Вир­ту­аль­ные се­ти мож­но уви­деть од­ну-един­ствен­ную сеть default 192.168.122.0/24, ко­то­рой со­от­вет­ству­ет ин­тер­фейс virbr0. Мар­шру­ти­за­ция в ней осу­ще­ств­ля­ет­ся при по­сред­стве транс­ля­ции се­те­вых ад­ре­сов (Network Address Translation, NAT), а ад­ре­са вир­ту­аль­ным ма­ши­нам вы­да­ют­ся ав­то­ма­ти­че­ски по DHCP. Та­кая кон­фи­гу­ра­ция под­хо­дит для боль­шин­ства слу­ча­ев – по­ка у вас не поя­вят­ся осо­бые за­про­сы.

В неко­то­рых слу­ча­ях в госте­вых систе­мах возника­ют про­бле­мы с по­лу­чением на­стро­ек по DHCP: на­при­мер, у ме­ня не сра­бо­та­ла ав­то­ма­ти­че­ская уста­нов­ка со­единения при за­груз­ке с ди­ст­ри­бу­тив­но­го диска Ubuntu 10.04. В та­ком слу­чае вы­ру­ча­ет dhclient – доста­точ­но лишь вы­полнить в госте­вой систе­ме коман­ду

sudo dhclient eth0

и про­бле­ма бу­дет ре­ше­на.

Ес­ли вир­ту­аль­ная ма­ши­на ис­поль­зу­ет­ся не для тести­ро­вания но­вых ди­ст­ри­бу­ти­вов, а для бо­лее серь­ез­ных це­лей, неред­ко возника­ет необ­хо­ди­мость сде­лать госте­вую систе­му ви­ди­мой из внешней се­ти. Для при­ме­ра рас­смот­рим си­туа­цию, когда на ней ра­бо­та­ет web-сер­вер. Здесь есть два ва­ри­ан­та на­строй­ки: «про­брос» TCP-пор­та 80 че­рез NAT или от­каз от NAT во­об­ще.

Ад­ре­са и мас­ки

Ес­ли вы не зна­ко­мы с ос­но­ва­ми мар­шру­ти­за­ции и вас пу­га­ют сло­ва вро­де «мас­ка под­се­ти» – не нерв­ни­чай­те, в этом нет ни­че­го слож­но­го. Фак­ти­че­ски, за­да­вая IP-ад­рес и мас­ку, вы ука­зы­вае­те сво­ей сис­те­ме, ка­кие IP-ад­ре­са ей над­ле­жит ис­кать на том или ином се­те­вом ин­тер­фей­се. IPv4-ад­рес со­сто­ит из 4 байт, то есть 32 бит. На­ча­ла ад­ре­сов, скры­ваю­щих­ся за тем или иным ин­тер­фей­сом, обыч­но оди­на­ко­вы: на­при­мер, при на­строй­ке вир­ту­аль­ной се­ти по умол­ча­нию ин­тер­фей­су virbr0 со­от­вет­ст­ву­ют ад­ре­са ви­да 192.168.122.xxx, где из­ме­ня­ет­ся толь­ко по­след­ний байт. Пер­вые три бай­та, то есть 24 би­та, не­из­мен­ны, что и оз­на­ча­ет чис­ло 24 в за­пи­си 192.168.122.0/24.

Дру­гой спо­соб ска­зать то же са­мое – ука­зать IP-ад­рес ин­тер­фей­са и мас­ку, со­стоя­щую так­же из 4 байт, в ко­то­рой не­из­мен­ным би­там со­от­вет­ст­ву­ют еди­ни­цы, а про­из­воль­ным – ну­ли. Та­ким об­ра­зом, IP-ад­рес ин­тер­фей­са 192.168.122.1 и мас­ка под­се­ти 255.255.255.0 оз­на­ча­ют те же на­строй­ки, что и пре­ды­ду­щая за­пись (ад­рес под­се­ти по­лу­ча­ет­ся из ад­ре­са ин­тер­фей­са пу­тём об­ну­ле­ ния всех из­ме­няе­мых би­тов).

Есть ещё один ню­анс, о ко­то­ром, впро­чем, virt-manager сам на­пом­нит вам при на­строй­ке ин­тер­фей­са. Ес­ли толь­ко вам не вы­де­ле­ны внеш­ние ста­ти­че­ские IP-ад­ре­са, при на­строй­ке сле­ду­ет ис­поль­зо­вать ад­ре­са из трёх спе­ци­аль­но за­ре­зер­ви­ро­ван­ных ча­ст­ных диа­па­зо­нов: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16. Ра­зу­ме­ет­ся, ес­ли ваш про­вай­дер вме­сто внеш­них IP-ад­ре­сов раз­да­ёт поль­зо­ва­те­лям ад­ре­са, на­чи­наю­щие­ся на 10, то для по­строе­ния сво­ей се­ти тот же диа­па­зон ис­поль­зо­вать не сто­ит.

Про­брос пор­та

В пер­вом слу­чае нуж­но на­зна­чить госте­вой ОС ста­ти­че­ский IP-ад­рес, для че­го непло­хо бы сна­ча­ла исклю­чить его из диа­па­зо­на, от­ве­дён­но­го для DHCP (по умол­чанию он по­кры­ва­ет все доступ­ные ад­ре­са). Для это­го из­меним па­ра­метр «Окон­чание DHCP» с 192.168.122.254 на 192.168.122.159. Та­ким об­ра­зом, ад­ре­са с 192.168.122.160 по 192.168.122.254 мож­но ис­поль­зо­вать в ка­че­стве ста­ти­че­ских, не опа­са­ясь кон­флик­тов.

По­сле на­строй­ки госте­вой ОС на ис­поль­зо­вание IP-ад­ре­са – ска­жем, 192.168.122.160 – вам останет­ся толь­ко за­дать пра­ви­ла мар­шру­ти­за­ции. Для это­го мож­но восполь­зо­вать­ся гра­фи­че­ски­ми ути­ли­та­ми, вхо­дя­щи­ми в ди­ст­ри­бу­тив, но мы при­ве­дём универ­саль­ное ре­шение с при­менением iptables:

iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j DNAT --to 192.168.122.160:80
iptables -A INPUT -p tcp -m state --state NEW --dport 80 -i eth0 -j ACCEPT

Пер­вая коман­да здесь за­да­ёт пе­ре­ад­ре­са­цию вхо­дя­щих TCP-со­единений на 80‑й порт на ад­рес госте­вой систе­мы, а вто­рая раз­ре­ша­ет при­ём этих со­единений из внешней се­ти. Ра­зу­ме­ет­ся, ес­ли в Ин­тернет «смот­рит» не eth0, а дру­гой ин­тер­фейс, на­до внести в коман­ды со­от­вет­ствую­щие по­прав­ки.

Не на­до нам NAT’а

Так ли нам ну­жен NAT? Лич­но у ме­ня уже есть один в мар­шру­ти­за­то­ре, и я не ви­жу ре­зо­на чрез­мер­но услож­нять ар­хи­тек­ту­ру се­ти. А при на­ли­чии в ней несколь­ких сер­ве­ров, под­клю­чение к ко­то­рым осу­ще­ств­ля­ет­ся по од­но­му и то­му же пор­ту, возника­ет необ­хо­ди­мость раз­дать им всем «бе­лые» IP-ад­ре­са. Та­кая воз­мож­ность пре­ду­смот­ре­на в libvirt, и она так же лег­ко на­страи­ва­ет­ся че­рез virt-manager.

Для это­го нуж­но до­ба­вить но­вую вир­ту­аль­ную сеть (кно­поч­ка с зе­лё­ным плю­сом при­таи­лась в нижней части ок­на на­стро­ек). Ад­рес­ное про­стран­ство в дан­ном слу­чае сле­ду­ет вы­би­рать та­ким об­ра­зом, что­бы не на­ру­ши­лась мар­шру­ти­за­ция в пре­де­лах всей под­се­ти. На­при­мер, мой мар­шру­ти­за­тор на­стро­ен на локаль­ную сеть 192.168.1.0/24 (то есть с маской под­се­ти 255.255.255.0). В дан­ном слу­чае мне про­ще все­го из­менить в его на­строй­ках маску под­се­ти для LAN на 255.255.0.0, тем са­мым су­ще­ствен­но рас­ши­рив диа­па­зон доступ­ных в локаль­ной се­ти ад­ре­сов. В на­строй­ках но­вой вир­ту­аль­ной се­ти тогда мож­но оста­вить зна­чение по умол­чанию – 192.168.100.0/24.

На­строй­ки DHCP то­же мож­но не тро­гать: по умол­чанию по­ло­ви­на доступ­но­го диа­па­зо­на ад­ре­сов ре­зер­ви­ру­ет­ся под ста­ти­че­ское ис­поль­зо­вание, а дру­гая – для DHCP. Ну и, на­конец, са­мое глав­ное: на­до ука­зать, что вир­ту­аль­ная сеть долж­на быть под­клю­че­на к фи­зи­че­ской, и вы­брать ре­жим «Мар­шру­ти­зи­руе­мая». Когда вир­ту­аль­ная сеть бу­дет го­то­ва, под­клю­чение к ней мож­но бу­дет вы­брать при соз­дании но­вой вир­ту­аль­ной ма­ши­ны.

Мож­но и под­клю­чить к се­ти уже су­ще­ствую­щую ма­ши­ну; для это­го в окне по­следней (вклад­ка «Под­роб­но­сти») нуж­но до­ба­вить но­вый се­те­вой ин­тер­фейс, ука­зав в ка­че­стве хост-уст­рой­ства [host device] мар­шру­ти­зи­руе­мую сеть. Ес­ли один или несколь­ко вир­ту­аль­ных се­те­вых ин­тер­фей­сов уже бы­ли под­клю­че­ны к ма­шине ранее, их мож­но уда­лить.

Без virt-manager

Virt-manager, безуслов­но, удо­бен, но иногда при­хо­дит­ся на­страи­вать сеть и в от­сут­ствие гра­фи­че­ской сре­ды. С libvirt это не так уж слож­но: для этих це­лей слу­жит про­грам­ма virsh, пре­достав­ляю­щая для на­строй­ки тек­сто­вый ин­тер­фейс команд­ной обо­лоч­ки.

Основ­ное за­труднение за­клю­ча­ет­ся в том, что кон­фи­гу­ра­ци­он­ный файл се­ти при­дёт­ся пи­сать в фор­ма­те XML. По сча­стью, он не та­кой уж боль­шой, что­бы на­де­лать в нём оши­бок. Что­бы ра­зо­брать­ся, что к че­му, взглянем на файл с на­строй­ка­ми по умол­чанию:

<network>
   <name>default</name>
  <uuid>271151ec-efa7-4cfd-99e8-ce7d4d4f848d</uuid>
  <bridge name=”virbr0” />
  <forward/>
  <ip address=”192.168.122.1” netmask=”255.255.255.0”>
   <dhcp>
    <range start=”192.168.122.2” end=”192.168.122.254” />
   </dhcp>
   </ip>
  </network>

Пер­вое: все на­строй­ки долж­ны быть за­клю­че­ны в тэг <network>. Имя се­ти – обя­за­тель­ный эле­мент, он за­клю­ча­ет­ся в тэг <name>. В имени мож­но ис­поль­зо­вать толь­ко бу­к­вы ла­тиницы и циф­ры. Важ­но, что­бы оно не сов­па­да­ло с именем уже су­ще­ствую­щей се­ти. Иден­ти­фи­ка­тор се­ти в тэ­ге <uuid> вруч­ную ука­зы­вать не нуж­но – он бу­дет соз­дан при до­бав­лении се­ти ав­то­ма­ти­че­ски.

Тэг <bridge> со­дер­жит опи­сание ин­тер­фей­са се­те­во­го моста; в боль­шин­стве слу­ча­ев доста­точ­но за­дать его имя. Ре­ко­мен­ду­ет­ся на­чи­нать имя ин­тер­фей­са с пре­фик­са vir; при этом нуж­но сле­дить, что­бы оно не дуб­ли­ро­ва­ло имя уже су­ще­ствую­ще­го. Имя virbr0 за­ре­зер­ви­ро­ва­но для вир­ту­аль­ной се­ти по умол­чанию, по­это­му при напи­сании кон­фи­гу­ра­ции но­вых се­тей его ис­поль­зо­вать нель­зя.

Тэг <forward> оз­на­ча­ет, что вир­ту­аль­ная сеть долж­на быть со­единена с фи­зи­че­ской. Для него мож­но за­дать ат­ри­бу­ты mode, принимаю­щий зна­чения «nat» или «route» (для се­ти с NAT или мар­ш­ру­ти­зи­руе­мой, со­от­вет­ствен­но), и dev, зна­чение ко­то­ро­го за­да­ёт фи­зи­че­ский се­те­вой ин­тер­фейс. Так, что­бы на­стро­ить мар­шру­ти­зи­руе­мую сеть че­рез ин­тер­фейс eth0, на­до бу­дет напи­сать

<forward mode=”route” dev=”eth0” />

Ес­ли вир­ту­аль­ную сеть с фи­зи­че­ской со­еди­нять не на­до, тэг <forward> сле­ду­ет опустить.

Ну и, на­конец, са­мое глав­ное – тэг <ip>. Ат­ри­бут address за­да­ёт IPv4‑ад­рес се­те­во­го ин­тер­фей­са; для вир­ту­аль­ных ма­шин он бу­дет ад­ре­сом шлю­за. Ат­ри­бут netmask, как неслож­но до­га­дать­ся, за­да­ёт маску под­се­ти; зна­чение “255.255.255.0” в боль­шин­стве слу­ча­ев бу­дет оп­ти­маль­ным. За­клю­чён­ный в тэг <ip> тэг <dhcp> слу­жит для опи­сания на­стро­ек DHCP-сер­ве­ра. Па­ра­мет­ра­ми тэ­га <range> за­да­ёт­ся диа­па­зон IP-ад­ре­сов. Сю­да мож­но так­же до­ба­вить один или несколь­ко тэ­гов <host>, ко­то­рые из­ба­вят нас от необ­хо­ди­мо­сти на­страи­вать ста­ти­че­ские IP-ад­ре­са для вир­ту­аль­ных ма­шин. На­при­мер, тэг

<host mac=”52:54:00:13:ee:56” name=”www.home” ip=”192.168.122.1” />

за­ре­зер­ви­ру­ет IP-ад­рес 192.168.122.1 и имя хос­та www.home для вир­ту­аль­ной ма­ши­ны с MAC-ад­ре­сом 52:54:00:13:ee:56. Уз­нать MAC-ад­рес мож­но, про­смот­рев кон­фи­гу­ра­ци­он­ный файл вир­ту­аль­ной ма­ши­ны с по­мо­щью ко­ман­ды

virsh dumpxml example | less

Здесь example – это имя ма­ши­ны.

С учё­том все­го из­ло­жен­но­го, кон­фи­гу­ра­ци­он­ный файл се­ти, со­от­вет­ст­вую­щий вто­ро­му из опи­сан­ных в пре­ды­ду­щем раз­де­ле ва­ри­ан­тов на­строй­ки, бу­дет вы­гля­деть так:

<network>
  <name>network1</name>
  <forward mode='route' />
  <bridge name='virbr1' />
  <ip address='192.168.100.1' netmask='255.255.255.0'>
   <dhcp>
     <range start='192.168.100.128' end='192.168.100.254' />
   </dhcp>
  </ip>
 </network>

Этот файл на­до со­хра­нить в лю­бом ка­та­ло­ге, по­сле че­го от име­ни root дать ко­ман­ду

virsh net-create network1.xml

где network1.xml – имя фай­ла. Что­бы сеть за­пус­ка­лась ав­то­ма­ти­че­ски, нуж­но вы­пол­нить ко­ман­ду

virsh net-autostart network1

Здесь network1 – это имя се­ти, ука­зан­ное на­ми в тэ­ге <name>.

Что­бы от­клю­чить ав­то­ма­ти­че­ский за­пуск се­ти default, нуж­но ис­поль­зо­вать ту же ко­ман­ду с клю­чом --disable:

virsh net-autostart default --disable

Хо­ро­шо, а как же быть, ес­ли воз­ни­ка­ет не­об­хо­ди­мость вне­сти ис­прав­ле­ния в на­строй­ки се­ти? Virsh по­мо­жет и здесь: ко­ман­да virsh net-edit network1 от­кро­ет кон­фи­гу­ра­ци­он­ный файл в ре­дак­то­ре Vim. Ес­ли вы пло­хо зна­ко­мы с ним, мож­но ис­поль­зо­вать дру­гой, за­дав его че­рез пе­ре­мен­ную ок­ру­же­ния $VISUAL. На­при­мер, ко­ман­да

VISUAL=”nano” virsh net-edit network1

от­кро­ет файл в ре­дак­то­ре Nano.

Стро­им мост

Рас­смот­рим ещё один ва­ри­ант на­строй­ки се­ти, ко­то­рый по­дой­дёт, ес­ли вир­ту­аль­ной ма­шине тре­бу­ет­ся ши­ро­кий ка­нал, под ко­то­рый име­ет­ся от­дель­ная се­те­вая кар­та. Соб­ствен­но, оче­вид­ным ре­шением ка­жет­ся пре­доста­вить госте­вой систе­ме пря­мой доступ к уст­рой­ству, но это воз­мож­но толь­ко на сравнитель­но но­вом обо­ру­до­вании с под­держ­кой IOMMU. Бо­лее универ­саль­ное ре­шение – на­стро­ить мост, от­дав фи­зи­че­ский ин­тер­фейс в пол­ное рас­по­ря­жение вир­ту­аль­ной ма­ши­ны. К со­жа­лению, де­ло это не та­кое про­стое, а глав­ное – в раз­ных ди­ст­ри­бу­ти­вах на­строй­ку при­дёт­ся вы­пол­нять по-раз­но­му. Кро­ме то­го, вряд ли по­лу­чит­ся на­стро­ить мост на бес­про­вод­ной ин­тер­фейс.

В Fedora, а так­же ди­ст­ри­бу­ти­вах, про­из­вод­ных от Red Hat, вклю­чая Mandriva, на­строй­ка про­из­во­дит­ся сле­дую­щим об­ра­зом. Пер­вым де­лом от­ре­дак­ти­ру­ем файл /etc/sysconfig/network-scripts/ifcfg-eth0 (в слу­чае на­строй­ки фи­зи­че­ско­го ин­тер­фей­са eth0), при­ве­дя его к сле­дую­ще­му ви­ду:

DEVICE=eth0
HWADDR=00:1E:8C:47:D2:53
ONBOOT=yes
BRIDGE=br0
NM_CONTROLLED=no

Па­ра­метр DEVICE дол­жен со­от­вет­ст­во­вать име­ни ин­тер­фей­са, HWADDR – его MAC-ад­ре­су. Уз­нать MAC-ад­рес мож­но с по­мо­щью ко­ман­ды

ifconfig eth0

Па­ра­метр BRIDGE=br0 ука­зы­ва­ет, что ин­тер­фейс дол­жен быть свя­зан с мостом br0, ко­то­рый мы соз­да­дим чуть поз­же. На­конец, стро­ка NM_CONTROLLED=no оз­на­ча­ет, что ин­тер­фейс не дол­жен управ­лять­ся NetworkManager, ко­то­рый не под­дер­жи­ва­ет со­единения мостом. В мо­ём слу­чае с Mandriva по­следний па­ра­метр, воз­мож­но, и лишний, по­сколь­ку NetworkManager в систе­ме от­сут­ству­ет, но ху­же от него точ­но не бу­дет.

Да­лее необ­хо­ди­мо соз­дать в ка­та­ло­ге /etc/sysconfig/network-scripts но­вый файл ifcfg-br0 со сле­дую­щим со­дер­жи­мым:

DEVICE=br0
TYPE=Bridge
BOOTPROTO=dhcp
ONBOOT=yes
DELAY=0
NM_CONTROLLED=no

Об­ра­ти­те внимание, что в стро­ке TYPE=Bridge сло­во «Bridge» долж­но на­чи­нать­ся с за­глав­ной бу­к­вы! Ес­ли вме­сто ис­поль­зо­вания DHCP необ­хо­ди­мо на­зна­чить ста­ти­че­ский IP-ад­рес, то па­ра­мет­ру BOOTPROTO над­ле­жит при­сво­ить зна­чение

BOOTPROTO=static

и за­дать па­ра­мет­ры се­ти, на­при­мер

IPADDR=192.168.1.128
NETMASK=255.255.255.0
GATEWAY=192.168.1.1
DNS1=192.168.1.1

По­сле это­го на­до пе­ре­за­пус­тить сер­вис network:

service network restart

Не по­ме­ша­ет так­же от­клю­чить бранд­мау­эр на со­еди­не­ни­ях ти­па «мост» (воз­мож­но, это уже сде­ла­но по умол­ча­нию). Про­верь­те на­ли­чие в фай­ле /etc/sysctl.conf сле­дую­щих строк:

net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0

Ес­ли они от­сут­ст­ву­ют, то до­бавь­те их. За­тем при­ме­ним из­ме­не­ния:

sysctl -p /etc/sysctl.conf

Для Debian, Ubuntu и дру­гих ба­зи­рую­щих­ся на Debian ди­ст­ри­бу­ти­вов на­строй­ка не­сколь­ко от­ли­ча­ет­ся. Пер­вым де­лом по­тре­бу­ет­ся от­клю­чить NetworkManager, вы­пол­нив ко­ман­ды

sudo /etc/dbus-1/event.d/26NetworkManagerDispatcher stop
sudo /etc/dbus-1/event.d/25NetworkManager stop

За­тем нуж­но за­пре­тить его за­пуск в даль­ней­шем. Это де­ла­ет­ся сле­дую­щим об­ра­зом:

sudo echo “exit” > /etc/default/NetworkManager
sudo echo “exit” > /etc/default/NetworkManagerDispatcher

По­сле это­го по­тре­бу­ет­ся ис­пра­вить файл /etc/network/interfaces. Сна­ча­ла най­ди­те там стро­ки вро­де

allow-hotplug eth0
iface eth0 inet static

и от­ре­дак­ти­руй­те их и сле­дую­щие за ни­ми, при­ве­дя к та­ко­му ви­ду:

auto br0
iface br0 inet static
bridge_ports eth0
bridge_stp on
bridge_maxwait 0
bridge_fd 0

На­строй­ки ста­ти­че­ско­го IP или DHCP сле­ду­ет ос­та­вить без из­ме­не­ний. По­сле со­хра­не­ния фай­ла ос­та­ёт­ся под­нять со­еди­не­ние ко­ман­дой

sudo ifup br0

Да­лее, как и в пре­ды­ду­щем слу­чае, нуж­но от­клю­чить бранд­мау­эр для мос­то­вых со­еди­не­ний, до­ба­вив в файл /etc/sysctl.conf стро­ки

net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0

и вы­пол­нив ко­ман­ду

sudo sysctl -p /etc/sysctl.conf

Пус­тим ма­ши­ны

На­де­ем­ся, вы­ше­при­ве­дён­ное опи­сание на­стро­ек се­те­во­го моста по­мог­ло спра­вить­ся с этой за­да­чей боль­шин­ству чи­та­те­лей. Поль­зо­ва­те­лям ди­ст­ри­бу­ти­вов, не род­ствен­ных Red Hat или Debian, при­дёт­ся по­искать ре­шение са­мо­стоя­тель­но. В неко­то­рых слу­ча­ях оно пре­дель­но про­стое: на­при­мер в openSUSE мост до­бав­ля­ет­ся при по­мо­щи YaST, в раз­де­ле Се­те­вые уст­рой­ства > Се­те­вые на­строй­ки. На ху­дой конец, все­гда мож­но соз­дать вре­мен­ный мост, «жи­ву­щий» до пе­ре­за­груз­ки систе­мы, непо­сред­ствен­ным вы­зо­вом команд из па­ке­та bridge-utils. Все под­роб­но­сти мож­но най­ти в до­ку­мен­та­ции к па­ке­ту.

Когда с соз­данием моста бу­дет по­кон­че­но, останет­ся толь­ко под­клю­чить его к вир­ту­аль­ной ма­шине. Де­ла­ет­ся это точ­но так же, как и под­клю­чение вир­ту­аль­но­го се­те­во­го ин­тер­фей­са. В окне вир­ту­аль­ной ма­ши­ны, на вклад­ке «Под­роб­но­сти», нуж­но до­ба­вить се­те­вой ин­тер­фейс, в ка­че­стве host device вы­брав мост br0.

Ес­ли гра­фи­че­ский ин­тер­фейс по той или иной при­чине недосту­пен, нуж­но бу­дет внести ис­прав­ления в кон­фи­гу­ра­ци­он­ный файл вир­ту­аль­ной ма­ши­ны. Для это­го в слу­чае ма­ши­ны с на­званием example нуж­но вы­полнить от имени root коман­ду

virsh edit example

по­сле че­го до­ба­вить внут­ри тэ­га <devices> при­мер­но та­кие стро­ки:

<interface type='bridge'>
  <source bridge='br0' />
  <target dev='vnet7' />
  <mac address=”00:11:22:33:44:55” />
 </interface>

Ат­ри­бут dev в тэ­ге <target> дол­жен ука­зы­вать на­звание вир­ту­аль­но­го се­те­во­го ин­тер­фей­са, ко­то­рое бы не дуб­ли­ро­ва­ло на­звание уже су­ще­ствую­ще­го. С тэ­гом <mac>, ду­маю, всё по­нят­но: ат­ри­бут address име­ет зна­чение, оп­ре­де­ляю­щее MAC-ад­рес это­го ин­тер­фей­са.

За­клю­чение

Как вид­но, в плане ра­бо­ты в се­ти вир­ту­аль­ная ма­ши­на ма­ло чем от­ли­ча­ет­ся от ре­аль­ной. Един­ствен­ное раз­ли­чие за­клю­ча­ет­ся в том, что со­единение осу­ще­ств­ля­ет­ся че­рез мост – вир­ту­аль­ный или «на­стоя­щий». Бла­го­да­ря это­му вир­ту­аль­ные ма­ши­ны на ба­зе KVM мож­но ис­поль­зо­вать и для са­мых раз­ных экс­пе­ри­мен­тов с по­строением се­тей, и для за­пуска на них ра­бо­чих сер­ве­ров, никак не свя­зан­ных с основ­ной сис­те­мой. А с libvirt на­строй­ка KVM ста­но­вит­ся со­всем не­слож­ной – не­важ­но, ра­бо­тае­те вы из гра­фи­че­ско­го ок­ру­же­ния или из кон­со­ли.