Внимание! Статья устарела и содержит неточности. Вам нужна статья Debian, KVM, финальные статьи. Настраиваем сеть для KVM. KVM и 2/3+ подсети на одном сервере.
Как вы уже знаете, я использую связку Debian+KVM+virsh+virt-install+virt-manager для виртуализации. Связка уже доказала свою жизнеспособность. Более того, она показала отличные показатели производительности и минимальные показатели затрат ресурсов.
Но в ходе первых шагов в изучении KVM меня постиг fail. Большой такой fail и жирный. Настраивал я первое время серверы по своему же мануалу — http://debian.pro/16
И всё было хорошо, быстро, прикольно, за исключением сети. Скорость работы сети была прекрасной, но вот понимания того, как оно работает, и почему оно работает так странно не было никакого. Какие были проблемы…. Ну, во-первых, FreeBSD ни в какую не хотела ходить в сеть. На гостевых FreeBSD гуру-фряшники смогли настроить сеть…. Но в интернет VDSы попали с трудом. Это вам и дупликация пакетов, и редирректы пакетов… Всего уже и не упомню.
Причин всё поломать и построить заново было две. Во-первых, мне необходимо было понимать, как же оно работает. Во-вторых, после одной перезагрузки хост-сервер так и не изъявил желания отвечать на пинги. 7 часов были убиты на попытки понять что произошло и 5 минут ушло на решение проблемы.
Потом появились IP адреса из второй подсети и всплыли проблемы с их использованием…. В общем предлагаю вашему вниманию пример органичной настройки сети для виртуализации KVM. Особенности данного способа:
1) VDS получают ip адреса, прописанные на их внутренних сетевых интерейсах и с этими адресами могут выходить в интернет. Прямо как физические серверы.
2) VDS «не понимают», что они находятся за шлюзом или их сетевые возможности как-то ограничены. А значит, мы можем поднимать на них pptp/pppoe серверы, спокойно ставить ispmanager и многое другое
3) администратор VDSа может самостоятельно изменить IP адрес для своей VDS, прописав его в /etc/network/interfaces гостевой системы. Да, это минус, это проблема. Решать мы её будем в следующих статьях цикла.
4) мы не экономим IP адреса для организации сети в рамках этого мануала. Если вы не желаете «тратить IP адреса на какую то фигню» — ищите другой мануал.
5) мы получаем максимально высокопроизводительное и прозрачное решение.
6) каждый виртуальный сетевой интерфейс сможет получать IP адреса только из одной подсети. Но никто не мешает к виртуалкам прикручивать второй сетевой интерфейс.
Внимание! Статья устарела и содержит неточности. Вам нужна статья Debian, KVM, финальные статьи. Настраиваем сеть для KVM. KVM и 2/3+ подсети на одном сервере.
Теперь к практике.
У нас есть сервер. Башой такой, в дата-центре, за цисками. В сети дата-центра нет DHCP, но есть фильтр MAC адресов на цисках, который не позволяет получить IP адрес, предназначенный для другого сервера.
Нашему серверу выделены IP адреса из общей подсети датацентра и личная /29я подсеть. Обозначим их так:
1) маска общей подсети 255.255.255.192, IP адреса в этой подсети: aaa.bbb.ccc.137, aaa.bbb.ccc.175, aaa.bbb.ccc.176, aaa.bbb.ccc.177
2) личная подсеть, маска — 255.255.255.248, IP адреса — xxx.yyy.zzz.33, xxx.yyy.zzz.34, xxx.yyy.zzz.35, xxx.yyy.zzz.36, xxx.yyy.zzz.37, xxx.yyy.zzz.38
Итого — 10 IP адресов в 2 подсетях. К сожалению, виртуалки получат только 7 из них. Если бы все они были в одной подсети — получили бы 8.
Приступим к настройке. Будьте внимательны, некоторые опции не подойдут для вас. Ну и не забывайте, что копипастить нижеследующее нельзя, нужно понимать, что делаете и вводить всё ручками.
Приводим /etc/network/interfaces к следующему виду:
Debian:~# cat /etc/network/interfaces
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address aaa.bbb.ccc..137
broadcast aaa.bbb.ccc..191
netmask 255.255.255.192
gateway aaa.bbb.ccc..129
# default route to access subnet
up route add -net aaa.bbb.ccc.128 netmask 255.255.255.192 gw aaa.bbb.ccc.129 eth0
Будьте предельно внимательны, проверьте все настройки. Перезагрузим сетевой демон:
Debian:~# cat /etc/init.d/networking restart
Теперь самое время установить bridge-utils, если вы этого ещё не сделали (aptitude install все помнят как пишется).
Теперь следует активировать возможности ядра хоста по маршрутизации пакетов:
Debian:~# echo 1 > /proc/sys/net/ipv4/ip_forward
Эту строчку можно положить в /etc/rc.local. Остальное я бы не советовал добавлять туда. Всё нижеследующее я оформил в стартовый скрипт, который уже прописал в rc.local. В случае чего, я могу максимально быстро удалить эту строчку из liveCD или LivePXEboot.
Начинаем настройку личной подсети сервера (xxx.yyy.zzz.33-38):
Создадим виртуальный интерфейс br0, который будет отвечать за маршрутизацию VDS с IP адресами из личной подсети:
Debian:~# brctl addbr br0
Назначим ему IP адрес из личной подсети, сконфигурируем и запустим его:
Debian:~# ifconfig br0 xxx.yyy.zzz.33 netmask 255.255.255.248 up
А теперь, собственно, назначим маршрутизацию для виртуальных машин:
Debian:~# route add -host xxx.yyy.zzz.34 dev br0
Debian:~# route add -host xxx.yyy.zzz.35 dev br0
Debian:~# route add -host xxx.yyy.zzz.36 dev br0
Debian:~# route add -host xxx.yyy.zzz.37 dev br0
Debian:~# route add -host xxx.yyy.zzz.38 dev br0
Теперь создадим виртуальный интерфейс br1. Он будет отвечать за маршрутизацию VDSов из общей подсети:
Debian:~# brctl addbr br1
Назначим ему IP адрес, сконфигурируем и запустим его:
Debian:~# ifconfig br1 aaa.bbb.ccc.175 up
Обратите особое внимание на то, что для br1 мы НЕ указываем netmask. Эта простая истина стоила мне 5 часов активного гуглежа и недоступного сервера. Причина очень простая — если у вас в linux есть 2 устройства/интерфейса, IP адреса которых принадлежат к одной подсети — маску подсети следует указывать только для одного из них.
Ну а теперь, донастроим маршрутизацию для VDS с IP адресами из общей подсети:
Debian:~# route add -host aaa.bbb.ccc.176 dev br1
Debian:~# route add -host aaa.bbb.ccc.177 dev br1
Всё, сеть настроена. Пишем нужный вам скрипт или кидаем команды в rc.local, тестируем, доступен ли сервер после перезагрузки… Ну и приступаем к установке своей первой VDS (ну или не первой, какая разница).
Вбиваем знакомую нам команду:
Debian:~# virt-install -n vm1 -r 1024 -f /vms/vm1.img -s 50 -c /iso/debian-cd/5.0.4/amd64/iso-cd/debian-504-amd64-CD-1.iso –accelerate –os-type=linux –os-variant=generic26 -v –vnc -w bridge:brX
Обратите особое внимание на опцию -w bridge:brX. Вместо X — ставим номер нужного нам br. В принципе, вы можете настроить сколько угодно bridge-устройств. При помощи wondershaper (см. статью /43 на этом сайте) вы можете ограничить суммарную скорость всех виртуальных машин на одном bridge устройстве. Главное, не забывайте про netmask для br1 (ну или его аналога в ваших условиях).
Ну и собственно сетевые настройки для одной из наших KVM виртуалок:
IP адрес — xxx.yyy.zzz.34
Netmask — 255.255.255.248 (та же, что и у brX интерфейса. В случае с br1 — та же, что у eth0)
Gateway — xxx.yyy.zzz.33 (IP адрес устройств brX)
DNS серверы — те же, что и у физического сервера.
Указываем эти настройки в сетевом установщике Debian или в конфигурации любого другого дистрибутива/ОС и… и пользуемся)
Внимание! Статья устарела и содержит неточности. Вам нужна статья Debian, KVM, финальные статьи. Настраиваем сеть для KVM. KVM и 2/3+ подсети на одном сервере.
Господа, Вы проблему безопасности при использовании бриджа так и не решили?
Безопасности чего?
НУ когда новая статья будет?)) С использованием 1-го ip для нескольких подсетей.