Виртуальная лаборатория

Как построить лабораторию на базе домашнего сервера?
Из бесплатных вариантов немного.
1.GNS3
2.IOU — вебморда iou-web перешла в другой проект — Unetlab

Проще в настройках, конечно, GNS3, к тому же переписанный в версию 1.х
Для GNS3 необходимо установить собственно сам GNS3 и wireshark для просмотра трафика

#apt-get install gns3 wireshark wireshark-common

Wireshark возможно ставить только для внутренних интерфейсов GNS или в promiscuos mode, тогда возможно будет отслеживать пакеты реальных сетевых интерфейсов.

# dpkg-reconfigure wireshark-common
# adduser $USER wireshark
#exit (logout)

Добыть образы для Cisco устройств, изначально на них можно построить только моршрутизацию, но при добавлении платы NM-16ESW можно получить реализацию комутатора.

Или в новом GNS3 использовать IOU/IOL

Для остальных устройств в GNS3 есть масса возможностей -встроенный эмулятор PC, облако для подключения внешней сети и использование виртуальных устройств на виртуальных машинах QEMU и VirtualBox.

На QEMU реализованы виртуализация более сложных маршрутизаторов Cisco ASA и Juniper vMX, vSRX, Olive
Описание есть в интернете
Ценное — реализация виртуализации.
http://illumium.org/node/83
Работа с образами

Родной формат образов жестких дисков Qemu называется Qcow2. Образ в данном формате имеет нефиксированный размер, увеличивающийся в процессе выполнения операций записи. Технология работает на «железном» по отношению к гостевой операционной системе уровне, поэтому никак не ограничивает выбор файловых систем.

Многие люди не используют Qcow2 поскольку raw образы можно монтировать базовыми средствами и работать с ними напрямую. Однако, образы Qcow2 тоже можно монтировать с использованием модуля ядра nbd.
Снимки (Snapshots)

Эта особенность связана с устройством Qcow2 и заключается в возможности зафиксировать некий образ в текущем состоянии, а дальнейшие изменения производить уже в другой постоянный или временный образ.

Различные архитектуры

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

С другой стороны, сам Qemu способен работать на не меньшем числе аппаратных архитектур и операционных систем в том числе на мобильных устройствах, как бы это ни «ломало» для некоторых «шаблон».
Нескучная практическая часть

Достоинства Qemu можно перечислять долго, так что самое время перейти к практике.
Создание базового образа

Итак, нет ничего проще:

$ qemu-img create -f qcow2 base.qcow2 10G
Formatting 'test.qcow2', fmt=qcow2 size=10737418240 encryption=off cluster_size=65536
$ du -skh test.qcow2
136K test.qcow2

Мы создали образ base.qcow2, который может иметь максимальный размер 10G. Однако, пока он пуст и занимает всего 136K места в нашей файловой системе.

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

$ kvm -m 512M -hda base.qcow2 -cdrom guess.iso -boot d

Здесь я использовал команду kvm вместо qemu, потому что в моём дистрибутиве таким образом задействуется функционал виртуализации ядра, ускоряющий работу виртуальной машины с аналогичной хост-системе архитектурой.

Виртуальная машина загрузит установщик с образа guess.iso, которому будет доступен наш базовый образ base.qcow2. Я выделил машине 512M оперативной памяти, а опция -boot с параметров d заставляет загружаться с устройства cdrom. Делаем там всю грязную работу по установке операционной, или вообще находим готовый подходящий образ в «доверенном источнике».
Тюнинг гостевой системы

На самом деле у меня уже были готовые образы, поэтому далее требовалось только несколько подшаманить с ними в плане улучшения, так сказать, эксплуатационных характеристик.

Главное, что нужно сделать, это отучить операционку срать ненадлежащим образом использовать наш образ. Отключаем все возможные свопы/подкачки/или что там у вас, временные каталоги типа /tmp переводим куда-нибудь в другой раздел.

Например, можно создать отдельный образ temp.qcow2 аналогично базовому, а затем подключить его как второй винчестер:

$ qemu-img create test-temp.qcow2 1G
Formatting 'test-temp.qcow2', fmt=raw size=1073741824
$ kvm -m 512M -hda base.qcow2 -hdc temp.qcow2

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

Если сравнить объём занятого операционной системой места с объёмом образа, то почти наверняка последний будет больше где-то порядка на 15-25%. Это нормально, но суровые оптимизаторы обязаны это недоразумение исправить. Я просто создал ещё один такой же пустой базовый образ, отформатировал его в гостевой операционной системе и скопировал все файлы с исходного образа, после чего установил на него системный загрузчик. Новый образ получился уже значительно меньше предшественника, пробуем загрузиться с него, если всё в порядке, то первоначальный можно упокоить с миром.
Подключение образа Qcow2

С копированием файлов то всё понятно, а вот с переносом загрузчика бывает далеко не всё так просто, а зачастую самым тривиальным решением может оказаться использование dd. Это первый случай, когда нам может потребоваться работать с образом гостевой системы как с устройством.

Нам потребуется модуль ядра nbd:

$ sudo modprobe nbd max_part=12
$ ls -al /dev/nbd*
brw-rw---T 1 root disk 43, 0 Май 31 22:36 /dev/nbd0

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

$ sudo qemu-nbd -c /dev/nbd0 $PWD/base.qcow2
$ ls -al /dev/nbd0*
brw-rw---T 1 root disk 43, 0 Май 31 23:05 /dev/nbd0
brw-rw---T 1 root disk 43, 1 Май 31 23:05 /dev/nbd0p1

Как видим, появилось ещё одно устройство, это наш первичный раздел, можно делать с ними обоими, как если бы они были обычными устройствами, вот так просто это работает, и никаких петель. Например, просто примонтируем файловую систему первичного раздела:

$ mkdir base
$ sudo mount /dev/nbd0p1 base

Отключить образ можно, когда все его разделы отмонтированы, командой:

$ sudo qemu-nbd -d /dev/nbd0
/dev/nbd0 disconnected
$ ls -al /dev/nbd0*
brw-rw---T 1 root disk 43, 0 Май 31 23:05 /dev/nbd0

Устройство снова одно.
Особенности крионики снимков

Когда базовый образ готов, самое время его «заморозить». Делаем его доступным только для чтения, ведь больше мы его менять никогда не будем. Теперь создадим новый образ, но совсем не такой как раньше:

$ qemu-img create -f qcow2 -b base.qcow2 variant.qcow2
Formatting 'variant.qcow2', fmt=qcow2 size=10737418240 backing_file='base.qcow2' encryption=off cluster_size=65536
$ du -skh variant.qcow2
136K variant.qcow2

Новый образ унаследован от базового, теперь при работе с ним чтение происходит либо из базового, либо с него, а запись только в него. Теперь мы можем загрузиться с этого нового образа и внести какие-то изменения, чтобы получить первый вариант конфигурации виртуальной системы. Аналогично можно создать любое число подобных образов, имеющих в качестве основы один базовый.

А можно пойти ещё дальше, нарастив глубину наследования, в зависимости от потребности в конкретных конфигурациях, главное не забывать всякий раз «замораживать» образ, который будет использоваться в качестве базы, чтобы предотвратить любую возможность его изменения, в противном случае наследующие образы могут оказаться некорректными.

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

kvm -m 512M -hda variant.qcow2 -hdc temp.qcow2 -shapshot

При запуске машины таким образом все операции записи будут производиться во временный снимок, который, кстати, при желании можно и сохранить, воспользовавшись консолью Qemu.

Запись опубликована в рубрике How to, linux. Добавьте в закладки постоянную ссылку.