Журнал LinuxFormat - перейти на главную

LXF137:libvirt

Материал из Linuxformat
Версия от 11:09, 11 января 2012; Crazy Rebel (обсуждение | вклад)

(разн.) ← Предыдущая | Текущая версия (разн.) | Следующая → (разн.)
Перейти к: навигация, поиск
Подписка на печатную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подписка на электронную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подшивки старых номеров журнала (печатные версии)
Весь 2014 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Се­ти в 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 ста­но­вит­ся со­всем не­слож­ной – не­важ­но, ра­бо­тае­те вы из гра­фи­че­ско­го ок­ру­же­ния или из кон­со­ли.

Источник — «http://wiki.linuxformat.ru/wiki/index.php?title=LXF137:libvirt&oldid=13269»
Персональные инструменты
купить
подписаться
Яндекс.Метрика