Subnets.ru blog

Добро пожаловать в блог! Надеемся, что Вы еще вернетесь.

Продолжая тему туннелей привожу ещё один способ поднять туннель между серверами под OS FreeBSD — это netgraph туннели.

Netgraph туннель как и OpenVPN туннель позволяет выбрать порт и протокол по которому будет устанавливаться туннель.

Их основное отличие в том, что netgraph туннель реализован на уровне ядра системы и использует все доступные ядра CPU, а OpenVPN реализован в userland`е и использует только одно ядро CPU.

Задача

Поднять netgraph туннель между двумя FreeBSD серверами и пророутить через туннель некоторые подсети.

Дано

• Внешний IP-адрес сервера FreeBSD1: 1.1.1.1
• Внешний IP-адрес сервера FreeBSD2: 2.2.2.2
• Тунельный IP-адрес сервера FreeBSD1: 10.0.0.1
• Тунельный IP-адрес сервера FreeBSD2: 10.0.0.2

Настройка

Туннель устанавливается между двумя внешнему IP-адресами по выбранному нами порту 2000 и протоколу UDP,  на туннеле назначаются IP-адреса из серой подсети 10.0.0.0/30.

Я приведу настройку только одной стороны, т.к. вторая сторона это просто зеркальное отражение первой.

Создадим интерфейс ng:
# ngctl mkpeer iface dummy inet

Укажем что будем использовать протокол UDP:
# ngctl mkpeer ng0: ksocket inet inet/dgram/udp

Укажем внешний IP сервера FreeBSD-1 (с которого мы и начали настройку) и зададим порт:
# ngctl msg ng0:inet bind inet/1.1.1.1:2000

Укажем внешний IP сервера FreeBSD-2 и порт, на которой мы и устанавливаем туннель:
ngctl msg ng0:inet connect inet/2.2.2.2:2000

Назначим IP-адреса на сам туннель (созданный интерфейс ng0):
ifconfig ng0 10.0.0.1 10.0.0.2 netmask 255.255.255.252

Теперь можно посмотреть что получилось:

# ifconfig ng0

ng0: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1500
        inet 10.0.0.1 --> 10.0.0.2 netmask 0xfffffffc

Туннель с одной стороны готов, настройте зеркально вторую сторону (сервер FreeBSD-2) и вы должны «увидеть» (пинговать) туннельные IP-адреса с обоих сторон.
После чего можно уже роутить что угодно через установленный вами туннель.

Команда для уничтожения netgraph туннеля:

# ngctl shutdown ng0:

Внимание ! Символ двоеточия в конце это не очепятка, как многие думают, он должен там быть.

Для автозапуска туннеля заглянем в предоставленный нам пример /usr/share/examples/netgraph/udp.tunnel и создадим свой стартовый скрипт /usr/local/etc/rc.d/ng_tun_start.sh

#!/bin/sh

case "$1" in
stop)
        if ifconfig ng0 >/dev/null 2>&1; then
                ifconfig ng0 inet down delete >/dev/null 2>&1
                ngctl shutdown ng0:
                echo "tunnel ng0 was destroyed";
        fi
        ;;
start)
        LOC_EXTERIOR_IP=1.1.1.1
        REM_EXTERIOR_IP=2.2.2.2

        LOC_INTERIOR_IP=10.0.0.1
        REM_INTERIOR_IP=10.0.0.2

        UDP_TUNNEL_PORT=2000
        if ifconfig ng0 >/dev/null 2>&1; then
                echo "tunnel ng0 already up";
        else
                ngctl mkpeer iface dummy inet
                ngctl mkpeer ng0: ksocket inet inet/dgram/udp
                ngctl msg ng0:inet bind inet/${LOC_EXTERIOR_IP}:${UDP_TUNNEL_PORT}
                ngctl msg ng0:inet connect inet/${REM_EXTERIOR_IP}:${UDP_TUNNEL_PORT}
                ifconfig ng0 ${LOC_INTERIOR_IP} ${REM_INTERIOR_IP} netmask 255.255.255.252
        fi
        ;;
*)
        echo "Usage: `basename $0` {start|stop}" >&2
        ;;
esac

Теперь при старте сервера туннель будет автоматически создан и у вас есть возможность в ручную стартовать туннель:
# /usr/local/etc/rc.d/ng_tun_start.sh start

или разрушать его:
# /usr/local/etc/rc.d/ng_tun_start.sh stop

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА ! Пожалуйста, уважайте чужой труд.

Автор: Панфилов Алексей (lehis (at) subnets.ru)

NetFlow — Netflow — протокол 5 (сеансового) уровня сетевой модели OSI, разработанный компанией Cisco и предназначенный для сбора информации об IP-трафике.

Стандартный пакет flow-tools, помимо приложений, которые показывают содержимое файлов статистики, содержит еще и две интересные службы flow-capture и flow-fanout.
Flow-capure служит для сохранения полученной статистики. Flow-fanout служит для дублирования статистики на разные машины. Обовсем подробнее.

Программно-аппаратное обеспечение
1. ПК P4 — CPU 2.4 GHz, RAM 512 Mb, HDD 1Tb.
2. ОС — FreeBSD 7.2, swap 4 Gb

Установка
1. Обновляем порты:

# portsnap fetch update

или если вы используете команду portsnap впервые:

# portsnap fetch extract

2.  Устанавливаем порт:

# cd /usr/ports/net-mgmt/flow-tools
# make install clean

Настройка

Правим файл /etc/rc.conf:

Так настраивается flow-capture:

# Запускаем flow-capture
flow_capture_enable=»YES»

# Указываем ip-адрес на котором слушается соединение (принимается поток)
flow_capture_localip=»IP_ADDRESS«
вместо IP_ADDRESS укажите IP-адрес сервера, пример: 10.0.0.1

# Указываем ip с которого принимать поток (по умолчанию 0.0.0.0 — принимать с любого ip)
flow_capture_remoteip=»0.0.0.0″

# Указываем порт на который будет приниматься поток
flow_capture_port=»9998″

# указываем путь, по которому будем складывать статистику
flow_capture_datadir=»/usr/local/_dump/ng»

# Параметры работы демона
flow_capture_flags=»-keyvalue»

Так настраивается flow-fanout:

#Включаем flow-fanout
flow_fanout_enable=»YES»

# Указываем ip-адрес на котором слушается соединение(принимается поток)
flow_fanout_ip=»IP_ADDRESS«

# Указываем ip с которого принимать поток (по умолчанию 0.0.0.0 — принимать с любого ip)
flow_fanout_remoteip=»0.0.0.0″

# Указываем порт на который будет приниматься поток
flow_fanout_port=»PORT_NUMBER«

# Указываем правила экспорта статистики
flow_fanout_export=»<source_ip1>/<det_ip1>/<dest_port1> <source_ip2>/<det_ip2>/<dest_port2>»

Перед настройкой следует определиться, каким образом будет осуществляться хранение статистики и её получение.
Вариантов существует по меньшей мере 2:

• непосредственно принимать поток при помощи flow-capture и сохранять на этой же машине
• принимать поток при помощи flow-capture и дублировать этот же поток на другую машину

Рассмотри оба варианта на примере использования mpd5 в связке с netflow.

Первый вариант

Допустим, mpd5 и flow-capture у нас работают на одной машине.

Эти параметры следует прописать в mpd.conf:
set iface enable netflow-in
set iface enable netflow-out
set netflow peer 127.0.0.1 9996 #Кому передаем
set netflow self 127.0.0.1 65500 #свой порт, от которого будет происходить передача

Это прописываем в /etc/rc.conf:
flow_capture_enable=»YES»
flow_capture_localip=»127.0.0.1″
flow_capture_remoteip=»0.0.0.0″
flow_capture_port=»9998″
flow_capture_datadir=»/usr/local/_dump/»
flow_capture_flags=»-S60 -z9 -n95 -N0″

Таким образом демон mpd5 будет скидывать, с порта 65500, на порт 9996, flow-capture, информацию о входящем и исходящем трафике,

а flow-capture, в свою очередь, будет складывать её по пути /usr/local/_dump .

Второй вариант
Допустим, mpd5 и flow-fanout у нас работают на одной машине, а flow-capture на другой и нам нужно сливать поток как на коллектор flow-capture, так и на еще одну стороннюю машину.

• mpd5 и flow-fanout — IP 10.10.0.1
• flow-capture — ip 10.10.0.2
• сторонняя машина — ip 10.10.0.3

Сервер 1:
mpd.conf берем из предыдущего примера:
set iface enable netflow-in
set iface enable netflow-out
set netflow peer 127.0.0.1 9996 #Кому передаем
set netflow self 127.0.0.1 65500 #свой порт, от которого будет происходить передача

А вот в /etc/rc.conf настраиваем уже flow-fanout:
flow_fanout_enable=»YES»
flow_fanout_ip=»127.0.0.1″
flow_fanout_remoteip=»127.0.0.1″
# Укажу свой loopback, т.к. нет смысла слушать «с любого адреса»
flow_fanout_port=»9996″
flow_fanout_export=»10.10.0.1/10.10.0.2/9997 10.10.0.1/10.10.0.3/9998″

Сервер 2:
Именно на нем поднимаем flow-capture:
flow_capture_enable=»YES»
flow_capture_localip=»10.10.0.2″
flow_capture_remoteip=»10.10.0.1″
# Можно указать и 0.0.0.0
flow_capture_port=»9997″
flow_capture_datadir=»/usr/local/_dump/»
flow_capture_flags=»-S60 -z9 -n95 -N0″

Сервер 3:
Любое приложение которое принимает flow-поток, будь то биллинг, другой сервер статистики или что-то еще.

Объясню что происходит во втором случае:
Демон mpd5 будет скидывать, с порта 65500, на порт 9996, flow-fanout, информацию о входящем и исходящем трафике. Flow-fanout, в свою очередь, будет сливать это на второй сервер, на котором настроен flow-capture, на порт 9997, и так же он будет сливать эту статистику на третий сервер, порт 9998.

Связка flow-capture И flow-fanout довольно гибкая и позволяет работать с flow-потоком так, как это нужно в зависимости от сложившейся ситуации.

Ключи к flow-capture можно посмотреть в соответствующем man’е.

После всего проделанного запускаем используемые нами сервисы:

# /usr/local/etc/rc.d/flow_capture start

# /usr/local/etc/rc.d/flow_fanout start

Литература и ссылки:
Википедия

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА !

Автор: Andrey

Топология

В качестве бордера c7206-npe-g1, на него принимаю 2 фул от ISP1 и ISP2.
Один из клиентов , со своей AS ходит через меня анонсами в обоих аплинков…
Каналы на аплинков разной толщины :

• ISP1 — 200 мб/с
• ISP2 — 155 мб/с

Описание поставленной задачи

Клиент подписал договор со следующими условиями:

• при нормальной работе обоих аплинков клиент работает только через ISP1
• при падении ISP1 клиент работает через ISP2

При этом чтобы клиент не ел полосу у ISP2 я решил его туда не анонсировать пока не упадет ISP1 …

Решение

router bgp OurAS
~skip~
neighbor Peering_IP_Customer remote-as CustomerAS
neighbor Peering_IP_Customer update-source GigabitEthernet0/3
neighbor Peering_IP_Customer fall-over
neighbor Peering_IP_ISP2 remote-as ISP2AS
neighbor Peering_IP_ISP2 update-source POS1/0
neighbor Peering_IP_ISP1 remote-as ISP2AS
neighbor Peering_IP_ISP1 update-source GigabitEthernet0/2
neighbor Peering_IP_ISP1 fall-over
!
address-family ipv4
~skip~

описываем пир с абонентом

neighbor Peering_IP_Customer activate
neighbor Peering_IP_Customer default-originate
neighbor Peering_IP_Customer prefix-list Customer_in in
neighbor Peering_IP_Customer prefix-list Customer_out out

описываем пир с ISP2, юзаем Advertise Condition Т.е. пока есть маршрут полученный через ISP1 сети 217.150.32.0/19 не анонсировать сеть абонента

neighbor Peering_IP_ISP2 activate
neighbor  Peering_IP_ISP2 advertise-map Cus2ISP2 non-exist-map NON-EXIST

при этом в любом случае анонсировать свои сети

neighbor Peering_IP_ISP2 route-map ISP2-in in
neighbor Peering_IP_ISP2 route-map ISP2-out out

описываем пир с ISP1

neighbor Peering_IP_ISP1 activate
neighbor Peering_IP_ISP1 route-map ISP1-in in
neighbor Peering_IP_ISP1 route-map ISP1-out out
~skip~
exit-address-family
!

собственно роутмапы
выпускаем только наши сети + абонент и режем то, что может не дай бог вылететь не нужное

!
route-map ISP1-out deny 5
match ip address prefix-list lan
!
route-map ISP1-out permit 10
match ip address prefix-list ourAS.all
!
route-map ISP1-out permit 20
match ip address prefix-list CustomerAS
!

тоже самое на второго апстрима

route-map ISP2-out deny 5
match ip address prefix-list lan
!
route-map ISP2-out permit 10
match ip address prefix-list ourAS.all CustomerAS
!

роутмап для определения есть ли анонс интересующей нас сети через первый апстрим

route-map NON-EXIST permit 10
match ip address prefix-list ISP1-in-net
match as-path 1
!

собственно роутмап анонса клиента

route-map Cus2ISP2 deny 5
match ip address prefix-list lan
!
route-map Cus2ISP2 permit 10
match ip address prefix-list CustomerAS
!

префикс листы

ip prefix-list ourAS.all seq 5 permit our_net1/21 le 24
ip prefix-list ourAS.all seq 10 permit our_net2/21 le 24
!
ip prefix-list CustomerAS seq 5 permit customer_net/22
!

собственно сеть которую мониторим

ip prefix-list ISP1-in-net seq 5 permit 217.150.32.0/19
!

так как на этом роутере у нас используются дополнительные демоны динамической маршрутизации (eigrp + ospf), в случае ошибки эти сети !не будут анонсированы нашим апстримам и абоненту

ip prefix-list lan seq 5 permit 0.0.0.0/0
ip prefix-list lan seq 10 permit 10.0.0.0/8 le 32
ip prefix-list lan seq 15 permit 172.16.0.0/12 le 32
ip prefix-list lan seq 20 permit 192.168.0.0/16 le 32
!

as-path лист для фильтра номера автономки ISP1

ip as-path access-list 1 permit ^AS_ISP1_NUM$
!

Результат

При такой настройке получаем:

1. наши сети анонсятся через обоих апстримов
2. абонент анонсится
   • при нормальной работе ISP1 только через него
   • при падении ISP1 идет анонс через ISP2

При этом вы могли заметить что на ISP2 прописано анонсить route-map ISP2-out в данный роут-мап входит и подсеть абонента.
Но она не будет анонсироваться пока не выполниться условие advertise-map Cus2ISP2 non-exist-map NON-EXIST, что нам и требовалось.
З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА !

Автор: Green

Один из наших читателей (пожелавший остаться анонимом) прислал нам по мылу конфигурацию для схемы с Juniper MX80, в которой прокидывается vlan через trunk проходящий через 80тые Juniper`ы.
Спасибо ему за инфу, т.к. она точно будет полезна всем кто столкнется с подобной задачей.

Топология

MX80-client [ge-1/0/2] <—> [ge-1/0/4] MX80-1 [ge-1/0/1] <—> [ge-1/0/7] MX80-2 [ge-1/1/1] <—> [ge-2/0/0] M120-client

Описание топологии

Access port   <—>    (Trunk port back to back)  <—>    Access port

IP-адрес на MX80-client (слева) — 200.200.200.1/30
IP-адрес на M120-client  (справа) — 200.200.200.2/30

Конфиги

MX80-1

root@MX80-1# show interfaces ge-1/0/1

flexible-vlan-tagging;
native-vlan-id 100;
encapsulation flexible-ethernet-services;
unit 2 {
    encapsulation vlan-bridge;
    vlan-id 10;
}

root@MX80-1# show interfaces ge-1/0/4

encapsulation ethernet-bridge;
unit 0 {
    family bridge;
}

root@MX80-1# show bridge-domains

DEV {
    domain-type bridge;
    vlan-id 10;
    interface ge-1/0/1.2;
    interface ge-1/0/4.0;
}

MX80-2

root@MX80-2# show interfaces ge-1/0/7

flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
unit 2 {
    encapsulation vlan-bridge;
    vlan-id 10;
}

root@MX80-2# show interfaces ge-1/1/1

encapsulation ethernet-bridge;
unit 0 {
    family bridge;
}

root@MX80-2# show bridge-domains

DEV {
     domain-type bridge;
     vlan-id 10;
     interface ge-1/0/7.2;
     interface ge-1/1/1.0;
}

MX80-client

root@MX80-client# show interfaces ge-1/0/2

unit 0 {
    family inet {
        address 200.200.200.1/30;
    }
}

root@MX80-client# run show interfaces ge-1/0/2

Physical interface: ge-1/0/2, Enabled, Physical link is Up
Interface index: 160, SNMP ifIndex: 514
Link-level type: Ethernet, MTU: 1514, Speed: 1000mbps, BPDU Error:
None, MAC-REWRITE Error: None, Loopback: Disabled,
Source filtering: Disabled, Flow control: Enabled, Auto-negotiation:
Enabled, Remote fault: Online, Speed-negotiation: Disabled,
Auto-MDIX: Enabled
Device flags   : Present Running
Interface flags: SNMP-Traps Internal: 0x0
Link flags     : None
CoS queues     : 8 supported, 8 maximum usable queues
Current address: 80:71:1f:c2:05:62, Hardware address: 80:71:1f:c2:05:62
Last flapped   : 2011-01-19 13:12:48 UTC (17:20:05 ago)
Input rate     : 0 bps (0 pps)
Output rate    : 0 bps (0 pps)
Active alarms  : None
Active defects : None

Logical interface ge-1/0/2.0 (Index 71) (SNMP ifIndex 656)
Flags: SNMP-Traps 0x0 Encapsulation: ENET2
Input packets : 30
Output packets: 9
Protocol inet, MTU: 1500
Flags: Sendbcast-pkt-to-re
Addresses, Flags: Is-Preferred Is-Primary
Destination: 200.200.200.0/30, Local: 200.200.200.1,
Broadcast: 200.200.200.3
Protocol multiservice, MTU: Unlimited

M120-client

root@M120# show interfaces ge-2/0/0

unit 0 {
    family inet {
        address 200.200.200.2/30;
    }
}

root@M120# run show interfaces ge-2/0/0

Physical interface: ge-2/0/0, Enabled, Physical link is Up
Interface index: 143, SNMP ifIndex: 523
Link-level type: Ethernet, MTU: 1514, Speed: 1000mbps, Loopback:
Disabled, Source filtering: Disabled, Flow control: Enabled,
Auto-negotiation: Enabled, Remote fault: Online
Device flags   : Present Running
Interface flags: SNMP-Traps Internal: 0x4000
Link flags     : None
CoS queues     : 8 supported, 8 maximum usable queues
Current address: 00:19:e2:67:f3:fc, Hardware address: 00:19:e2:67:f3:fc
Last flapped   : 2011-01-19 18:32:34 UTC (17:19:47 ago)
Input rate     : 0 bps (0 pps)
Output rate    : 0 bps (0 pps)
Active alarms  : None
Active defects : None

Logical interface ge-2/0/0.0 (Index 87) (SNMP ifIndex 310)
Flags: SNMP-Traps Encapsulation: ENET2
Input packets : 7
Output packets: 2430
Protocol inet, MTU: 1500
Flags: None
Addresses, Flags: Is-Preferred Is-Primary
Destination: 200.200.200.0/30, Local: 200.200.200.2,
Broadcast: 200.200.200.3

Проверка ICMP запросами

root@M120# run ping 200.200.200.1

PING 200.200.200.1 (200.200.200.1): 56 data bytes
64 bytes from 200.200.200.1: icmp_seq=0 ttl=64 time=0.541 ms
64 bytes from 200.200.200.1: icmp_seq=1 ttl=64 time=0.499 ms
64 bytes from 200.200.200.1: icmp_seq=2 ttl=64 time=0.496 ms
64 bytes from 200.200.200.1: icmp_seq=3 ttl=64 time=0.505 ms
^C
--- 200.200.200.1 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.496/0.510/0.541/0.018 ms

root@MX80-client# run ping 200.200.200.2

PING 200.200.200.2 (200.200.200.2): 56 data bytes
64 bytes from 200.200.200.2: icmp_seq=0 ttl=64 time=0.652 ms
64 bytes from 200.200.200.2: icmp_seq=1 ttl=64 time=0.511 ms
64 bytes from 200.200.200.2: icmp_seq=2 ttl=64 time=0.445 ms
64 bytes from 200.200.200.2: icmp_seq=3 ttl=64 time=0.504 ms
^C
--- 200.200.200.2 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.445/0.528/0.652/0.076 ms

Таблица MAC адресов на MX80`ых расположенных в центре по топологии

root@MX80-1# run show bridge mac-table

MAC flags (S -static MAC, D -dynamic MAC,
SE -Statistics enabled, NM -Non configured MAC)

Routing instance : default-switch
Bridging domain : DEV, VLAN : 10
MAC                 MAC      Logical
address             flags    interface
00:19:e2:67:f3:fc   D        ge-1/0/1.2
80:71:1f:c2:05:62   D        ge-1/0/4.0

root@MX80-2# run show bridge mac-table

MAC flags (S -static MAC, D -dynamic MAC,
SE -Statistics enabled, NM -Non configured MAC)

Routing instance : default-switch
Bridging domain : DEV, VLAN : 10
MAC                 MAC      Logical
address             flags    interface
00:19:e2:67:f3:fc   D        ge-1/1/1.0
80:71:1f:c2:05:62   D        ge-1/0/7.2

Появилась у нас недавно задача, под которую выделять отдельный реальный сервер жалко, а юзать один сервер совместно с другими задачами геморно.

Давно хотели попробовать (модную нынче) виртуализацию, когда на одном физическом сервере располагается более одной системы и вот как раз такой случай.

На просторах тырнета с помощью гугла была найдена статейка «Ставим VirtualBox на FreeBSD без использования X11«, собственно хорошая статья для старта разборок с виртуализацией.

Приведу копию статьи с моими дополнениями после нее.

Текущая актуальная версия порта VirtualBox — 3.2.4. Начиная, с 3.1.0 версии порт разбит на два: virtualbox-ose-kmod (модули ядра) и virtualbox-ose (сам virtualbox).

 

В текущей версии порта решена проблема с установкой VirtualBox без X11 и со встроенным vnc сервером. Поэтому процесс установки сводится к стандартным действиям.
Действия по шагам:
# cd /usr/ports/net/libvncserver
# make
# make install
# cd /usr/ports/emulators/virtualbox-ose-kmod
# make
# make install

После этого ставим непосредственно VirtualBox:
# cd /usr/ports/emulators/virtualbox-ose
# make config

далее, выбираем нужные нам опции:

# make
# make install

Добавляем загрузку модуля VirtualBox и запуск скрипта для возможности работы адаптера виртульной машины в bridge-режиме (без нее — только NAT):
# echo ‘vboxdrv_load=»YES»‘ >> /boot/loader.conf
# echo ‘vboxnet_enable=»YES»‘ >> /etc/rc.conf

Чтобы лишний раз не перезагружаться, вручную грузим модуль и скрипт:
# kldload vboxdrv
# /usr/local/etc/rc.d/vboxnet start

Создание и настройка виртуальной машины

 

Создаем виртуальную машину (посмотреть все возможные ostype: VBoxManage list ostypes)

# VBoxManage createvm --name MicroXP --ostype WindowsXP --register --basefolder /usr/vbox

Задаем парамерты виртуалки (bridgeadapter1 указывает адаптер хоста, к которому привязываем виртуалку)

# VBoxManage modifyvm MicroXP --memory 512 --floppy disabled --audio none --nic1 bridged --bridgeadapter1 em0 --vram 4 --accelerate3d off --boot1 disk --acpi on --cableconnected1 on

Создаем жесткий диск, размер указывается в мегабайтах

# VBoxManage createhd --filename /usr/local/vbox/iso/MicroXP.vdi --size 1000 --register

Создаем контроллер на виртуалке

# VBoxManage storagectl MicroXP --name "IDE Controller" --add ide

Подключаем диск к контроллеру

# VBoxManage storageattach MicroXP --storagectl "IDE Controller" --port 0 --device 0 --type hdd --medium /usr/local/vbox/MicroXP.vdi

Подключаем установочный образ к контроллеру

# VBoxManage storageattach MicroXP --storagectl "IDE Controller" --port 1 --device 0 --type dvddrive --medium /usr/local/vbox/MicroXP-v0.82.iso

Устанавливаем загрузку с установочного образа

# VBoxManage modifyvm MicroXP --boot1 dvd

Далее, запускаем машину и указываем ей параметры vnc:

# VBoxHeadless -s MicroXP -n -m 5900 -o password

Подключаемся любым vnc-клиентом (например, RealVNC или UltraVNC) и ставим ОС.

—————————————————

Добавлено 24.01.2013

Внимание.

Virtualbox с версии 4.2 изменил работу виртуалок с VNC. Теперь вместо ключа -n нужно запускать так:

# VBoxManage setproperty vrdeextpack VNC
# VBoxManage modifyvm MicroXP --vrdeproperty VNCPassword=password
# VBoxManage modifyvm MicroXP --vrdeauthlibrary null
# VBoxManage modifyvm MicroXP --vrdeport 5900
# VBoxHeadless --startvm MicroXP

Ссылки:

• Build VNC Extension Pack from SVN
• VNC in virtualbox-ose-4.2.6

—————————————————

Затем нужно поставить guest additions в виртуалку, без них vnc сервер иногда глючит:

# VBoxManage storageattach MicroXP --storagectl "IDE Controller" --port 1 --device 0 --type dvddrive --medium /usr/local/lib/virtualbox/additions/VBoxGuestAdditions_3.2.4.iso

После этого, виртуальная машина готова к использованию.

Правда, несмотря на установленные guest additions, заставить работать курсор мыши мне не удалось.

—————————

Мои дополнения/заметки

Вышеописанным способом мне удалось установить две виртуальные машины с OS:

1. FreeBSD 8.1 — в кач-ве сервера
2. Windows XP — в кач-ве клиента

Запускать с vnc нужно тогда когда необходим доступ к консоли сервера, т.е. получается как удаленная KVM.
Если нужно просто запустить уже готовую и настроенную виртуальную машину, то пользуем:

# VBoxManage startvm MicroXP --type headless

Останавливаем виртуальную машину  через acpi:

# VBoxManage controlvm MicroXP acpipowerbutton

или более жестко:

# VBoxManage controlvm MicroXP poweroff

Выставляем hdd как загрузчик, послее того как установили OS:

# VBoxManage modifyvm MicroXP --boot1 disk

Отцепить установочный диск:

 # VBoxManage storageattach MicroXP —storagectl «IDE Controller» —port 1 —device 0 —medium none

Просмотр всех запущенных машин:

# VBoxManage list runningvms

Просмотр всех зарегистрированных машин:

# VBoxManage list vms

Просмотр информации о виртуальной машине:

# VBoxManage showvminfo MicroXP

Backup

Бекап виртуальных машин можно сделать через команду export, перед выполнением команды export необходимо выключить виртуалку или поставить сделать сохранение состояния:

Выключение:

# VBoxManage controlvm MicroXP poweroff

Сохранение состояния:

# VBoxManage controlvm MicroXP savestate

После чего можно выполнить export:

# VBoxManage export MicroXP -o /usr/WinXP.ovf

Внимание: после выполнения команды на выключение или команды на сохранения состояния виртуальную машину необходимо запускать снова, не забудьте об этом.

Недавно я заморочился над темой автоматического резервного копирование виртуальных машин Virtualbox, чтобы они сами ежедневно бекапились. Почитал в Инете каждый «во что горазд» делает. Кто то через export, кто то через clonehd, а кто то через snapshot.

Поразмыслив я для себя все же остановился на варианте с export. Для выполнения задачи резервного копирования виртуальных машин Virtualbox я накатал скрипт на PERL, который запихнул в /etc/crontab OS FreeBSD.

Кому интересно, то вот исходник скрипта для backup`а всех запущенных виртуальных машин: http://subnets.ru/files/virtualbox_backup.pl.txt

Что делает скрипт автоматического backup`а для virtualbox машин:

• получает листинг всех запущенных виртуальных машин, которые и будут подвергаться бекапу
• создает директорию для backup`а: /some/path/backup/год/месяц/день/имя_виртуальной_машины
• создает в backup дире файл readme.txt куда помещает вывод команды showvminfo по бекапируемой виртуалке
• выполняет savestate виртуальной машины
• выполняет export виртуальной машины
• выполняет запуск виртуальной машины
• после завершения бекапирования всех запущенных машин, скрипт выполняет удаление папки с бекапом месячной давности

Import

Импорт виртуальных машин:
Может понадобиться или при восстановлении из backup`а или просто при переносе на другой физический сервер.
По умолчанию каталог для хранения виртуальных машин является home каталогом юзера под котором вы вошли в систему, чтобы изменить местоположение выполним:

# mkdir -p /usr/vbox/machines
# mkdir /usr/vbox/hdd
# VBoxManage setproperty machinefolder /usr/vbox/machines
# VBoxManage setproperty hdfolder /usr/vbox/hdd

Сначала проверим как оно импортнется:

# VBoxManage import /usr/WinXP.ovf --dry-run

Если все ОК, то теперь можно импортить:

# VBoxManage import /usr/WinXP.ovf

Отныне все виртуалки будут «жить» в каталоге /usr/vbox.

Добавить ещё сетевуху можно командой:

# VBoxManage modifyvm MicroXP --nic2 bridged --bridgeadapter2 vlan4 --cableconnected2 on

Этим мы добавили вторую сетевую карту, забриджевали её с vlan4 на реальном сервере.
Все последущие карты добавляются/изменяются/удаляются так же с указанием —nicX, где X это номер карты

Махнуть MAC-адрес на втором адаптере можно командой:

# VBoxManage modifyvm MicroXP --macaddress2 auto

MAC-адрес будет выбран автоматически, либо можно самому задать мак:

# VBoxManage modifyvm MicroXP --macaddress2 444444444444

Удалить любую сетевуху из виртуалки можно по её номеру, мы удалим вторую, которую создали выше:

# VBoxManage modifyvm MicroXP --nic2 none

Проблем или отличий в работе виртуальной машины и реальной я не заметил. Все работает как надо.

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

Например мы собирали тестовый стенд из 3-х виртуалок и гоняли на них BGP с использованием Quagga.

—————————

Добавлено 24.01.2013

Внимание. Virtualbox с версии 4.2 инсталит свои модули в папку с ядром /boot/kernel вместо папки /boot/modules:

# ls -la /boot/kernel/vbox*
-r-xr-xr-x  1 root  wheel  243579 24 янв 17:38 /boot/kernel/vboxdrv.ko
-r-xr-xr-x  1 root  wheel  639853 24 янв 17:38 /boot/kernel/vboxdrv.ko.symbols
-r-xr-xr-x  1 root  wheel    9075 24 янв 17:38 /boot/kernel/vboxnetadp.ko
-r-xr-xr-x  1 root  wheel   48281 24 янв 17:38 /boot/kernel/vboxnetadp.ko.symbols
-r-xr-xr-x  1 root  wheel   23080 24 янв 17:38 /boot/kernel/vboxnetflt.ko
-r-xr-xr-x  1 root  wheel   76126 24 янв 17:38 /boot/kernel/vboxnetflt.ko.symbols

Поэтому если вы апгрейднули версию Virtualbox и у вас полезли ошибки такого плана:

# /usr/local/etc/rc.d/vboxnet start
/usr/local/etc/rc.d/vboxnet: WARNING: Can't load vboxnetflt module.

А в /var/log/messages у вас появилось:

kernel: link_elf: symbol ng_free_item undefined

То вам необходимо:

• выгрузить vboxdrv.ko если он загружен: # kldunload vboxdrv.ko
• пересобрать virtualbox-ose-kmod
• загрузить vboxdrv: # kldload vboxdrv.ko
• # /usr/local/etc/rc.d/vboxnet start

Если и это не помогает, то нужно пересобрать ядро, а потом снова повторить вышеописанную процедуру.

Пересбор ядра:

# cd /usr/src
# make kernel KERNCONF=YOUR_KERNEL_NAME

И с этого момента не забывайте, что если вы по какой то причине пересобирали ядро, то вам нужно после этого пересобирать и virtualbox-ose-kmod.

Ссылки:

• Can’t load vboxnetflt.ko after update virtualbox to 4.2.6

—————————

Ссылки

• http://livevolgograd.ru/blog/3.html
• http://habrahabr.ru/blogs/bsdelniki/84469/
• http://mediaunix.com/2010/11/22/virtualbox-virtualizaciya-vo-freebsd-bez-x11-ustanovka-sozdanie-virtualnoj-mashiny/
• http://wiki.freebsd.org/VirtualBox
• [PATCH] VirtualBox headless VNC support by LibVNCServer (20100211)
• www.virtualbox.org

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА ! Пожалуйста, уважайте чужой труд.

Автор: Николаев Дмитрий (virus (at) subnets.ru)