Piped Serial port: Доступ к COM порту в VBox для Windows и использование socat в Linux.

В меморизз:
http://www.reactos.org/wiki/VirtualBox#Redirect_to_virtual_serial_port_.28named_pipes.2C_Windows_host.2C_com0com_.29
http://technostuff.blogspot.ru/2008/10/piped-serial-port-on-virtualbox.html
Доступ к COM порту в VBox для Windows и использование socat в Linux.
Для Windows:
VBox: enable serial port / COM1 / port mode=host pipe / create pipe / file path=\\.\pipe\asa-pipe

Putty:
serial line=\\.\pipe\asa-pipe
speed=9600

---
Linux:
enable serial port / COM1 / port mode=host pipe / create pipe / file path=/tmp/asa-pipe

socat UNIX-CONNECT:/tmp/asa-pipe TCP-LISTEN:8042
telnet localhost:8042

JunOS Olive установка в Virtual Box, апгрейд.

На просторах Интернета полно статей по установке JunOS поверх фряхи.
Например, полезняшки здесь:
http://habrahabr.ru/post/111974/
здесь:
http://pauldotcom.com/2011/05/virtualizing-junos-on-vmware.html
здесь:
http://www.packetmischief.ca/2011/03/24/installing-olive-10-4r1-under-vmware/
и, конечно, здесь:
http://juniper.cluepon.net/index.php/Olive
В целом, алгоритм ясен:
- ставим фряху с большим разделом /var,
- достаем в "труднодоступных" местах jinstall-xxx.tgz,
- распаковываем и правим ряд параметров,
- пакуем с правками тарболл взад и,
- ставим во фре, как обычный пакет pkg_add.
В процессе изучения сабжа выяснилось несколько моментов:
- не каждая фряха одинаково полезна, наилучшие результаты достигались на версии 4.11 (это при живущей уже 9ке!),
- вопреки расхожему мнению, jinstall тарболл извлекается и из iso'шников,
- патчить / править тарбол можно на любой машине, где есть tar.
Начнем с подготовки виртуалки:
- выделяем 768Мб ОЗУ,
- выделяем IDE хард на 6Гб,
- отключаем звук, USB,
- создаем serial host pipe для COM1, пусть на /tmp/junos9com1
Собственно, скопипастенные действия для JunOS 9.6:
cd /var/tmp
mkdir jinst ; cd jinst ; tar xvzf ../jinstall-9.6R1.13-domestic-olive.tgz
# rm *.md5 *.sha1 *.sig
mkdir domestic ; cd domestic ; tar xvzf ../jbundle-9.6R1.13-domestic.tgz
rm *.md5 *.sha1 *.sig
mkdir pkgtools ; cd pkgtools ; tar xvzf ../pkgtools.tgz
cd pkg ; rm *.md5 *.sha1 *.sig ; cd ..
все распаковано и все контрольные суммы прибиты, теперь подменяем скрипт проверки (обращение будет возвращать код true)
cp /usr/bin/true bin/checkpic
пакуем все обратно, стирая созданные каталоги:
tar cvzf ../pkgtools.tgz *
cd .. ; rm -rf pkgtools
tar cvzf ../jbundle-9.6R1.13-domestic.tgz *
cd .. ; rm -rf domestic/
tar cvzf ../jinstall-9.6R1.13-domestic-no-checkpic.tgz *
cd .. ; rm -rf jinst/
В результате получаем тарболл jinstall-9.6R1.13-domestic-no-checkpic.tgz, который и будет установлен:
pkg_add jinstall-9.6R1.13-domestic-no-checkpic.tgz
перезагружаемся - reboot, параллельно можно открыть консольный вывод, чтобы видеть процесс установки JunOS, или, как рекомендуемый вариант, поправим запись:
chmod +w /boot/loader.conf
vi /boot/loader.conf
находим запись console="comconsole" и исправляем ее на
    console="vidconsole"
если этого параметра нет - просто дописываем в конец файла и сохраняем.
Да, консольный вывод (используя socat), мне нравится такой вариант:
screen sudo socat /tmp/junos9com1 -
После всех проделанных процедур, получаем виртуальный рутер с ПО для Juniper M / T / MX Series.
В данной серии оборудования функционал распределяется по аппаратным модулям, ОС же играет роль центра управления, так что огромное количество фич будет не доступно, например, для работы NAT необходим service-interface (sr-0/0/0.0). Без него настройки NAT просто не применятся, кстати, в данной серии девайсов настройка NAT осуществляется через edit services nat.
Пошарив по задворкам тырнета наткнулся на пару утверждений, что для Оливки самый правильный JunOS - тот, который для J-Series (JSR?) рутеров - типа там у них все софтово творится, так что на эмуляторе пойдет кучеряво.
Надыбал  junos-jsr-10.3R1.9-domestic.tgz, который сам по себе на фряху не ставится, но им можно проапгрейдить имеющийся 9.6 JunOS.
Правим тарбол практически аналогично, с добавками (для 10й и старших версий) - везде, где видим файлы +INSTALL и +REQUIRE находим в них строки проверки архитектуры и подменяем (в vi):
check_arch_compatibility()
{
    #re_name=`/sbin/sysctl -n hw.re.name 2>/dev/null`
    re_name='olive'
    if [ -z "$re_name" ]; then
        Error "hw.re.name sysctl not supported."
    fi
комментируем строку re_name... и создаем свою с именем "olive", сохраняем все правки и пакуем обратно.
Теперь процедура обновления, в моем случае, патченный тарболл находится на локальном ftp серваке, так из cli выполняем:
request system software add unlink no-copy ftp://_username_:_password_@_ip_ftp_server_/Software/Juniper/junos-jsr-10.3R1.9-domestic-patched.tgz
Дожидаемся примерно таких строк:
JUNOS 10.3R1.9 will become active at next reboot
cat: /packages/junos-10.3R1.9-domestic.sha1: No such file or directory
Saving state for rollback ...
Removing /var/tmp/junos-10.3R1.9.tgz
и перезагружаем виртулку:
request system reboot
Новый рутер начал определяться уже как J4300, однако при настройке NAT (эта проверка настоятельно рекомендуется тем, кто планирует использовать сабж, как пограничное устройство), опять постиг облом:
error: usp_ipc_client_open: failed to connect to the server after 1 retries
поиск по ошибке указал на то, что в девайсе не хватает модуля, что проверка шасси и подтвердила:
show chassis fpc             
                     Temp  CPU Utilization (%)   Memory    Utilization (%)
Slot State            (C)  Total  Interrupt      DRAM (MB) Heap     Buffer
  0  Empty          
  1  Empty          
  2  Empty          
  3  Empty          
  4  Empty          
  5  Empty          
  6  Empty          
Кстати, здесь NAT настраивается через edit security nat...

Привилегированный доступ к машинам Virtual Box для подключения к среде GNS3

Для создания интерфейсов подключения GNS3 запускается с правами суперпользователя (параметры запуска предваряются вариантом sudo для графических приложений - gksudo /home/_username_/GNS3-0.8.2-BETA-src/gns3.pyw). Аналогично для подключения vbox хостов приложению Virtual Box также необходимо запускаться через gksudo, при этом, файл со списком настроенных виртуалок будет использовать путь /root/.VirtualBox/VirtualBox.xml, то есть при старте мы не увидим ни одной машины. Для исправления:
бэкапим существующий файл
sudo cp /root/.VirtualBox/VirtualBox.xml /root/.VirtualBox/VirtualBox.xml.backup
копируем не-sudo файл )из домашнего каталога
sudo cp /home/_username_/.VirtualBox/VirtualBox.xml /root/.VirtualBox/VirtualBox.xml
Теперь, машины, созданные не с использованием путей по-умолчанию, будут полностью доступны и работоспособны, а те, что создавались с дефолтными параметрами, будут ссылаться на конфиги и vHHD в каталогах
src="Machines/_виртуалка_", эти сокращенные пути по факту: /home/_username_/.VirtualBox/Machines/, так что это необходимо поправить в файле
sudo vim /root/.VirtualBox/VirtualBox.xml
в разделе MachineRegistry

Virtual Box ошибка выключения и запуск в среде GNS3

При использовании Oracle Virtual Box версии 4.1.8 было замечено два глюка:
1. при выключении питания, если в работе использовались виртуалки с vboxnetX адаптерами, это выключение замораживалось с ошибкой unregister_netdevice waiting for vboxnetX to become free
2. при тестировании подключения виртуальных машин Virtual Box в среде GNS3 выдавалась ошибка vboxapi module cannot be loaded
Обе эти проблемы решались сначала полным удалением существующего приложения (4.1.8) и новой установкой пакета версии 4.1.20, собранного конкретно под текущую версию ОС - не All distributions! В моем случае, это пакет для Ubuntu 12.04 LTS ("Precise Pangolin")  i386 (http://download.virtualbox.org/virtualbox/4.1.20/virtualbox-4.1_4.1.20-80170~Ubuntu~precise_i386.deb).
В результате 1й глюк успешно побеждается, 2й же немного видоизменяется - при тесте выдается ошибка failed to start xdotool, но это чинится установкой этих самых тулзов:
sudo apt-get install xdotool

Появление новых интерфейсов ethN при смене MAC адресов

При миграции или перемещении виртуальной машины (в моем случае под Virtual Box) при ее старте в логах присутствуют сообщения вида:
dmesg | grep network
udev[xxx]: renamed network interface eth0 to ethN
Это происходит по причине привязки MAC адреса виртуальной сетевухи к номеру интерфейса. Также, так как IP адреса назначены на "старые" интерфейсы (eth0, eth1...), то новосозданные eth2... без сетевых настроек.
Для решения этой проблемы редактируем файл
sudo vim /etc/udev/rules.d/70-persistent-net.rules
Исправляем мак-адреса интерфейсов для нужных eth0/eth1, пользуясь новыми записями (ниже в файле), а эти новые записи затираем:
...
# PCI device 0x1022:0x2000 (pcnet32)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="08:00:27:4a:90:da", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
...
# PCI device 0x8086:0x1004 (e1000)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="08:00:27:84:48:e3", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2"
...
Жирным выделены МАСи, которые нужно "махнуть не глядя", а вторую запись потом удалить.

Веб интерфейс для VirtualBox - phpvirtualbox

Для удаленного руления виртуалками на десктопе, без VNC и прочих Иксов, обнаружит тут этот самый веб интерфейс. В процессе установки вскрылась парочка граблей, к счастью, успешно преодоленных.
Итак десктоп Ubuntu 10.04 с беспроводкой (это важно, так как одни грабли заключаются именно в этой беспроводке), ставим на него веб сервер с соответствующими модулями (сам VirtualBox уже установлен).
sudo apt-get update
sudo apt-get install apache2 libapache2-mod-php5
cd /var/www
sudo mkdir vboxphp
cd vboxphp
качаем туда сабж:
sudo wget http://phpvirtualbox.googlecode.com/files/phpvirtualbox-4.1-7.zip
и распаковываем
unzip phpvirtualbox-4.1-7.zip
Теперь настроим конфиги, которыми веб-морда будет пользоваться:
sudo vim /etc/default/virtualbox
  VBOXWEB_USER=mik17
  VBOXWEB_HOST=172.17.17.101
в данном случае, указаны логин "хозяина" будущих и текущих виртуалок, а также адрес беспроводного интерфейса.
sudo cp /var/www/vboxphp/phpvirtualbox-4.1-7/config.php-example /var/www/vboxphp/phpvirtualbox-4.1-7/config.php
Копируем шаблон конфига и правим его:
sudo vim /var/www/vboxphp/phpvirtualbox-4.1-7/config.php
...
/* Username / Password for system user that runs VirtualBox */
var $username = 'mik17';
var $password = '***';

/* SOAP URL of vboxwebsrv (not phpVirtualBox's URL) */
var $location = 'http://172.17.17.101:18083/';
...
Проверяем статус сервиса Web VirtualBox (vboxweb-service):
sudo /etc/init.d/vboxweb-service status
несмотря на то, что статус сервиса running, в выводе netstat'а нет прослушиваемого порта 18083. В результате при обращении на страницу веб-морды после аутентификации будет выдаваться ошибка о невозможности соединиться с сервисом на этом порту. Причина в том, что беспроводной интерфейс получает сетевые параметры после аутентификации пользователя, так что для открытия порта на прослушивание нужно перезапустить сервис:
sudo /etc/init.d/vboxweb-service stop
sudo /etc/init.d/vboxweb-service start
Проверим порты:
netstat -a | grep LISTEN
tcp 0 0 *:ssh *:* LISTEN
tcp 0 0 localhost:ipp *:* LISTEN
tcp 0 0 mik17-note.local:18083 *:* LISTEN
Теперь, скорее всего веб интерфейс заведется, но может и выдать такую ошибку (это вторые грабли):
- error - "Error logging to vboxwebsrv".
Лечится данный недуг так:
VBoxManage setproperty websrvauthlibrary default
В результате получаем удаленное управление виртуалками на ноуте.

Подключение машин Virtual Box к виртуальному свичу VDE

После установки свича в систему (Ubuntu)
sudo apt-get install vde2
создаем конфигурационный файл для портов на свиче, например, такой:
vim vde_switch1.cfg

port/create 1
port/create 2
port/create 3
port/create 4
port/create 5
port/create 6
vlan/create 2
vlan/create 3
port/setvlan 1 2
port/setvlan 2 2
port/setvlan 3 2
port/setvlan 4 2
port/setvlan 5 3
port/setvlan 6 3

здесь создаются 6 портов, 2 VLAN'а и эти порты раскидыватся 4 порта на 2й ВЛАН и 2 порта на 3й
порты не тегированные (в терминах cisco - это switchport access vlan 2 ... vlan 3 порты).

Свич можно запустить, например, такой командой (не требует спец прав):
vde_switch -s /tmp/switch1 -f /home/mik17/VDE/vde_switch1.cfg
указанные в файле команды можно вводить в консоли свича (приглашение vde$)

На сетевых интерфейсах виртуальных машин Virtual Box настраиваем:
Attached to: Generic Driver
Name: VDE
Advanced
...
Generic Properties: network=/tmp/switch1[1]
где network=/tmp/switch1 путь к запущенному VDE свичу, а [1] - номер порта

!ВАЖНО! Перед стартом виртуальных машин необходимо создать ссылку на библиотеку подключения VDE, иначе будет выведена примерно такая ошибка:
rtldrNativeLoad: dlopen('libvdeplug.so', RTLD_NOW | RTLD_LOCAL) failed: libvdeplug.so: cannot open shared object file: No such file or directory
Исправляется так:
sudo ln -sf /usr/lib/libvdeplug.so.2 /usr/lib/libvdeplug.so