Заметки: QEMU, KVM

Для удобства управления виртуальными машинами можно поставить пакет aqemu. Но если это лениво или по каким-либо причинам недопустимо то следующие заметки, так сказать, "на память".

Создаём диск:

qemu-img create -f raw Knoppix_HDA.img 4G

Запускаем загрузку с LifeCD:

kvm -no-acpi -m 384 -cdrom KNOPPIX_V7.0.3CD-2012-06-25-EN.iso -hda Knoppix_HDA.img -boot d

или так:

kvm -monitor stdio -enable-kvm -m 1024 -localtime -cdrom KNOPPIX_V7.0.3CD-2012-06-25-EN.iso -hda Knoppix_HDA.img -boot order=dc,menu=on -net nic,vlan=0 -net user,vlan=0 -name "Knoppix" -vnc :10

Можно сконвертировать образ, если необходимо:

qemu-img convert -f raw Knoppix_HDA.img -O qcow2 Knoppix_QCOW2.img

Приоритет загрузки CD-ROM, затем HDD:

kvm -monitor stdio -enable-kvm -m 512 -localtime -hda Knoppix_HDA.img -boot order=dc,menu=on -net nic,vlan=0 -net user,vlan=0 -name "Knoppix" -vnc :10

Приоритет загрузки HDD, затем CD-ROM:

kvm -monitor stdio -enable-kvm -m 512 -localtime -hda Knoppix_HDA.img -boot order=cd,menu=on -net nic,vlan=0 -net user,vlan=0 -name "Knoppix" -vnc :10

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

Для начала, как и в статье про сеть в VirtualBox, установим все необходимые для этого пакеты:

sudo aptitude install uml-utilities

не забываем добавить нашего пользователя, для которого будет разрешено использовать сеть в виртуальной машине, в группу uml-net:

sudo adduser olden uml-net

Далее в /etc/network/interfaces пропишем настройки для нашего tap-интерфейса, который будет подвязан к виртуальной машине:

auto tap2
iface tap2 inet static
        address 172.16.24.5
        network 172.16.24.4
        netmask 255.255.255.252
        broadcast 172.16.24.7
        tunctl_user username

Собственно после этого можно запустить виртуальную машину и указать ей использовать только что построенный интерфейс:

kvm -monitor stdio -enable-kvm -m 512 -localtime -hda Knoppix_HDA.img -boot order=cd,menu=on -net nic,vlan=0 -net tap,vlan=0,ifname=tap2 -name "Knoppix" -vnc :10

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

Ограничение входа по SSH с конкретных IP адресов

Многие используют вход по ssh с использованием ключей авторизации (в блоге немного рассказывалось об этом), но мало кто знает о том, что при этом можно ограничить вход с заведомо доверенных ip-адресов.

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

Для введения ограничений доступа с конкретного ip, как и для авторизации по ключу, используется .ssh/authorized_keys. Например если мы хотим чтобы доступ с конкретным ключом авторизации осуществлялся только лишь с ip-адреса 1.2.3.4 то в начало соответствующей ключу строки файла .ssh/authorized_keys необходимо добавить значение from:

from="1.2.3.4" ssh-rsa  ....

Если хочется чтобы таких адресов было несколько или это была сеть то перечисляем нужные значения:

from="1.2.3.0/24,44.55.66.77" ssh-rsa ...

Таким-же образом можно ввести и другие ограничения, например:

from="1.2.3.4",no-agent-forwarding,no-port-forwarding,no-X11-forwarding ssh-rsa ...

это ограничит agent-forwarding, port-forwarding и т.д., оставив только интерактивный вход в систему. ssh можно ограничить ещё больше, например запретив интерактивный вход, заставив выполнить заданную команду:

command="/usr/local/bin/my-prog" ssh-rsa ..

Это может быть полезным для организации удалённого резервного копирования rsync + ssh, когда будет запущен строго определённый скрипт и ничего более.

Bonding - резервирование каналов на Layer 2

Устанавливаем пакеты согласно Debian Wiki.


Типы агрегации (объединения) интерфейсов в Linux

mode=0 (balance-rr)
Этот режим используется по-умолчанию, если в настройках не указано другое. balance-rr обеспечивает балансировку нагрузки и отказоустойчивость. В данном режиме пакеты отправляются "по кругу" от первого интерфейса к последнему и сначала. Если выходит из строя один из интерфейсов, пакеты отправляются на остальные оставшиеся.При подключении портов к разным коммутаторам, требует их настройки.

mode=1 (active-backup)
При active-backup один интерфейс работает в активном режиме, остальные в ожидающем. Если активный падает, управление передается одному из ожидающих. Не требует поддержки данной функциональности от коммутатора.

mode=2 (balance-xor)
Передача пакетов распределяется между объединенными интерфейсами по формуле ((MAC-адрес источника) XOR (MAC-адрес получателя)) % число интерфейсов. Один и тот же интерфейс работает с определённым получателем. Режим даёт балансировку нагрузки и отказоустойчивость.

mode=3 (broadcast)
Происходит передача во все объединенные интерфейсы, обеспечивая отказоустойчивость.

mode=4 (802.3ad)
Это динамическое объединение портов. В данном режиме можно получить значительное увеличение пропускной способности как входящего так и исходящего трафика, используя все объединенные интерфейсы. Требует поддержки режима от коммутатора, а так же (иногда) дополнительную настройку коммутатора.

mode=5 (balance-tlb)
Адаптивная балансировка нагрузки. При balance-tlb входящий трафик получается только активным интерфейсом, исходящий - распределяется в зависимости от текущей загрузки каждого интерфейса. Обеспечивается отказоустойчивость и распределение нагрузки исходящего трафика. Не требует специальной поддержки коммутатора.

mode=6 (balance-alb)
Адаптивная балансировка нагрузки (более совершенная). Обеспечивает балансировку нагрузки как исходящего (TLB, transmit load balancing), так и входящего трафика (для IPv4 через ARP). Не требует специальной поддержки коммутатором, но требует возможности изменять MAC-адрес устройства.

Сборка Razor-qt, как альтернативы KDE, под Debian GNU/Linux Wheezy

Скачиваем:

git clone git://github.com/Razor-qt/razor-qt.git
cd razor-qt/

или

wget http://razor-qt.org/downloads/razorqt-0.5.2.tar.bz2
tar xjf razorqt-0.5.2.tar.bz2
cd razorqt-0.5.2/

Устанавливаем пакеты:

sudo aptitude install cmake libqt4-dev libmagic-dev libxrender-dev libxcomposite-dev libxdamage-dev libqt4-dbus libqt4-webkit  libxcursor-dev zlib1g-dev libstatgrab-dev libqt4-xml libsensors4-dev liblightdm-qt-dev libqtwebkit4 libpolkit-qt-1-dev libpolkit-agent-1-dev libudev-dev libpulse-dev debian-edu-config

Собираем:

cd cmake/
cmake ../
cd ..
distr/deb/makeDeb.sh -r wheezy -d Debian .

Пакеты соберутся в домашней директории в каталоге ~/razorqt_0.5.2_deb.

cd ~/razorqt_0.5.2_deb
dpkg -i libqtxdg0_0.5.2-1_amd64.deb librazorqt0_0.5.2-1_amd64.deb razorqt-data_0.5.2-1_all.deb razorqt-appswitcher_0.5.2-1_amd64.deb razorqt-autosuspend_0.5.2-1_amd64.deb razorqt-config_0.5.2-1_amd64.deb razorqt-desktop_0.5.2-1_amd64.deb razorqt-globalkeyshortcuts_0.5.2-1_amd64.deb razorqt-notificationd_0.5.2-1_amd64.deb razorqt-panel_0.5.2-1_amd64.deb razorqt-power_0.5.2-1_amd64.deb razorqt-runner_0.5.2-1_amd64.deb razorqt-session_0.5.2-1_amd64.deb lightdm-razorqt-greeter_0.5.2-1_amd64.deb razorqt-policykit-agent_0.5.2-1_amd64.deb razorqt-openssh-askpass_0.5.2-1_amd64.deb razorqt_0.5.2-1_all.deb

Сайт проекта http://razor-qt.org/
How-to по сборке https://github.com/Razor-qt/razor-qt/wiki/How-to-build