Bozaro

На странице http://wiki.openvz.org/Download/template/precreated есть шаблон для Gentoo.

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

После изучения страницы http://wiki.openvz.org/Gentoo_template_creation удалось сформулировать принцип приведения контейнера в рабочее состояние.

Восстановление запуска SSH

Для начала, надо восстановить запуск демона ssh. В противном случае, сделать что-либо с виртуальной машиной затруднительно.

Если у вас есть возможность выполнить какой-либо скрипт внутри контейнера (например, через vzctl enter), то данный шаг можно пропустить.

Для этого нужно каким-либо образом закоментировать в файле /sbin/rc строку (у меня это была строка 249), добавив в начало символ решетки (#):

# try mount -n ${mntcmd:--t sysfs sysfs /sys -o noexec,nosuid,nodev}

После этого нужно перезапустить контейнер. (continue reading…)

На странице http://wiki.openvz.org/Download/template/precreated есть шаблон для Gentoo.

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

Пошаговая инструкция для сборки контейнера есть на: http://wiki.openvz.org/Gentoo_template_creation.

После прочтения этого руководства я написал скрипт, который позволяет собрать шаблон из архивов stage-3 и portage: openvz.zip

Скрипт должен запускаться под рутом. Сборка может производиться из любой Linux-системы (не обязательно из Gentoo).

Proxmox VE – гипервизор для OpenVZ и KVM на базе Debian с адекватным графическим интерфейсом.

Ранее я уже успел познакомиться с OpenVZ и KVM, но моя кустарная установка не имела дружественных средств управления виртуальными машинами.

Собирать конструктор не очень-то хотелось, посему решил попробовать что-нибудь из коробки. По описаниям Proxmox меня устраивал, но все оказалось не так просто, как мне того хотелось. (continue reading…)

С недавнего времени я активно использую OpenVZ, но вот понадобилось поставить на виртуальную машину M$ Windows и взор обратился к KVM (KVM и OpenVZ не являются взаимоисключающими и могут работать одновременно).

KVM использует аппаратную виртуализацию, что накладывает сильные ограничения на аппаратную составляющую, но, теоретически, дает минимальную усадку по производительности. (continue reading…)

В догонку к посту Установка OpenVZ на Ubuntu Linux решил описать результаты копаний по поводу настройки сети в виртуальной машине OpenVZ.

Итого в vzctl можно добавить сетевой интерфейс следующими способами:

1. vzctl set 101 –ipadd 192.168.0.1 –save
   Данный способ добавляет виртуальной машине интерфейс точка-тока с хост-машиной. В общем целом для простых случаев этого достаточно, но данный способ, к примеру, не позволяет работать с broadcast-ами (он не подходит, если на виртуальную машину нужно установить Samba или DHCP-cервер).
2. vzctl set 101 –netdev_add eth0 –save
   Тут все тоже достаточно просто. Указанный сетевой интерфейс переносится в виртуальную машину. То есть он будет доступен только в указанной виртуальной машине (в хост-машине или нескольких виртуальных машинах его использовать нельзя).
   Так же данный способ не работает если попытаться перебросить в виртуальную машину VLAN-интерфейс.
3. vzctl set 101 –netif_add eth0 –save
   vzctl set 101 –netif_add eth0,00:18:51:d8:04:98,veth101.0,00:18:51:0f:a6:ab
   Самое интересное – данный способ создает пару интерфейсов (один в виртуальной машине – eth0, и один в хост-машине – veth101.0), но аргумент для указания моста в версии 3.0.22 еще отсутствует.

(continue reading…)

Решил озадачиться виртуализацией под Linux. Основная задача – разнести различные функции на различные виртуальные сервера на домашней машине (резервное копирование, мониторинг, DHCP, DNS, SubVersion и т.д.). Нужно это для следующих целей:

1. Чтобы можно было обновлять/восстанавливать/переустанавливать все это по отдельности;
2. Чтобы упростить борьбу с Firewall-ом, так как часть сервисов должна смотреть в Internet, а часть сугубо локальная;
3. Для проведения экспериментов лучше виртуальной машины придумать что-то сложно.

Выбор остановился на OpenVZ по следующим причинам:

1. OpenVZ почти не дает усадки по производительности;
2. OpenVZ не требует процессора с поддержкой виртуализации.

Минусы у OpenVZ:

1. Под OpenVZ можно запустить только Linux, причем специально подготовленный;
2. В Ubuntu от OpenVZ отказываются в пользу KVM.

(continue reading…)