OpenVZ в Proxmox, заметки на полях

  • Tutorial

Возможно данная заметка не тянет на полноценную статью, но я постарался собрать здесь все нестандартные моменты, с которыми сталкивался при работе с контейнерами OpenVZ и гипервизором Proxmox, дать готовые рецепты с примерами, возможно кому-то это сэкономит время на поиск вариантов решения. Текста будет мало, примеров много, котиков картинок не будет.
  • Краткое содержание для экономии времени
  • 1. Проброс различных возможностей и устройств из гипервизора в контейнер OpenVZ
  • 1.1. Проброс fuse
  • 1.2. Проброс NFS
  • 1.3. Проброс USB-устройств
  • 1.4. Проброс звуковой карты (как встроенной так и usb)
  • 1.5. Проброс X'ов
  • 1.6. Проброс раздела диска
  • 1.7. Включение tun/tap
  • 2. Фаирвол
  • 3. Разные мелочи
  • UPD-1: Проброс vlan


И так поехали:

1. Проброс различных возможностей и устройств из гипервизора в контейнер OpenVZ


1.1.Проброс fuse

На гипервизоре выполнить:
Остановить контейнер OpenVZ
vzctl stop  [VEID]

выполнить
vzctl set  [VEID] --devices c:10:229:rw --save
vzctl exec  [VEID] mknod /dev/fuse c 10 229

Запустить контейнер
vzctl start  [VEID]

, где [VEID] номер контейнера, после чего монтирование в контейнере работает.

1.2. Проброс NFS

На гипервизоре:
Устанавливаем nfs сервер
aptitude install nfs-kernel-server

правим конфиг nfs
nano /etc/exports

например экспортируем /var/lib/vz для 10.1.1.2
/var/lib/vz 10.1.1.2(rw,sync,fsid=root,no_root_squash,crossmnt,no_subtree_check)

перезапускаем nfs сервер
/etc/init.d/nfs-kernel-server restart

Добавляем поддержку nfs в контейнер
vzctl set  [VEID] --features "nfs:on" --save  

Внутри контейнера:
aptitude install nfs-common

пример монтирования
mount -t nfs 10.1.1.1:/var/lib/vz/ /vz 

1.3. Проброс USB-устройств

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

В общем случае:
vzctl set VEID --devices b|c:major:minor|all:[r|w|rw|none]

где b — блочное устройство, c — символьное. major:minor необходимо посмотреть в /dev/bus/usb для конкретного устройства.
Проброс по имени
vzctl set  [VEID] --devnodes ttyUSB0:rw --save

Проброс по коду
vzctl set  [VEID] --devices c:189:all:rw --save

Либо правкой конфига:
nano /etc/pve/openvz/[VEID].conf
DEVNODES="ttyUSB1:rw "
DEVNODES="c:189:all:rw "

Для проброса USB-устройства в запущенный контейнер необходимо:
Смонтировать из хост-системы в контейнер
mount -o bind /dev/<DEVNAME> $VE_ROOT/dev/<DEVNAME> 

1.4. Проброс звуковой карты (как встроенной так и usb)

Во многом похоже на проброс обычного usb устройства, но с некоторыми отличиями.
На гипервизоре:
Ставим модули ядра для работы со звуком
modprobe snd_dummy
echo "snd_dummy" >> /etc/modules

Если USB звуковая, то еще
modprobe snd_usb_audio 
echo "snd_usb_audio" >> /etc/modules

Убедимся что модули подключились
lsmod | grep snd

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

Добавляем в конфиг виртуалки
vzctl set  [VEID] --devices c:116:all:rw --devices c:4:all:rw --save 

Если это не первое пробрасываемое устройство, то команда затрет предыдущие, тогда
правим фаил
/etc/pve/openvz/[VEID].conf 

добавляем в него строку
DEVICES="c:116:all:rw c:4:all:rw " 

Выводим список всех snd устройств
ls -la /dev/snd

crw-rw---T  1 root audio 116, 6 Jan 25 19:19 controlC0
crw-rw---T  1 root audio 116, 9 Jan 27 09:52 controlC1
crw-rw---T  1 root audio 116, 5 Jan 25 19:19 pcmC0D0c
crw-rw---T  1 root audio 116, 4 Jan 25 19:20 pcmC0D0p
crw-rw---T  1 root audio 116, 8 Jan 27 09:52 pcmC1D0c
crw-rw---T  1 root audio 116, 7 Jan 27 09:52 pcmC1D0p
crw-rw---T  1 root audio 116, 3 Jan 25 17:47 seq
crw-rw---T  1 root audio 116, 2 Jan 25 17:47 timer  

Заходим в контейнер
vzctl enter  [VEID]

Выполянем
rm -r /dev/snd

mkdir /dev/snd
mknod /dev/snd/controlC0 c 116 6
mknod /dev/snd/controlC1 c 116 9
mknod /dev/snd/pcmC0D0c c 116 5
mknod /dev/snd/pcmC0D0p c 116 4
mknod /dev/snd/pcmC1D0c c 116 8
mknod /dev/snd/pcmC1D0p c 116 7
mknod /dev/snd/seq c 116 3
mknod /dev/snd/timer c 116 2
chmod 660 /dev/snd/*
chown :audio /dev/snd/*

(Обращаем внимание что номера устройств и имена должны совпадать с таковыми на гипервизоре)

Ставим alsa
aptitude install alsa alsa-lib alsa-base alsa-util libdssialsacompat0 

Теперь нужных пользователей контейнера добавляем в группу audio
adduser skype audio

1.5. Проброс X'ов

Заходим в контейнер через vzctl (не SSH)
делаем симлинк
rm /dev/tty0
ln -s /dev/tty1 /dev/tty0 

Удаляем если установлен nscd
aptitude remove nscd 

Ставим нужные пакеты
aptitude -R install xorg xserver-xorg-video-dummy xserver-xorg-input-kbd xserver-xorg-input-mouse alsa-base linux-sound-base libaudiofile0 dbus udev

Приводим /etc/X11/xorg.conf к виду
Section "InputDevice"
        Identifier      "Dummy Input"
        Driver          "void"
EndSection

Section "Device"
        Identifier      "Dummy Video"
        Driver          "dummy"
EndSection

Section "Monitor"
        Identifier      "Configured Monitor"
EndSection

Section "Screen"
        Identifier      "Default Screen"
        Monitor        "Configured Monitor"
        Device          "Dummy Video"
EndSection

Section "ServerLayout"
        Identifier      "Default Layout"
        Screen          "Default Screen"
        InputDevice    "Dummy Input"
EndSection


Стартуем Хы
/usr/bin/X :<DISPLAY#>

где
 указывает дисплей, который будет использоваться (без скобок). Теперь приложения, требующие X-ы смогут работать на любом из этих дисплеев.

Например, для запуска Skype (для Skypiax) на определенном дисплее и под UID "Skype":
su skype -c "echo secret:password | DISPLAY=:1 /usr/bin/skype --pipelogin 2>>skype_errors.log &»


1.6. Проброс раздела диска

Принцип аналогичен предыдущим, но сделаем это по имени, например пробросим sda4
vzctl set  [VEID] --devnodes sda4:rw --save

1.7. Включение tun/tap

Если мы хотим использовать vpn внутри контейнера, то без этого не обойтись.

Проверяем подгружен ли модуль
lsmod | grep tun

Если нет подгружаем
modprobe tun
echo "tun" >> /etc/modules

vzctl stop [VEID]
vzctl set [VEID] --devices c:10:200:rw --save
vzctl set [VEID] --capability net_admin:on --save
vzctl start [VEID]

С пробросами закончили, остальное делается примерно так-же.

Фаирвол


В стандартном варианте фаирвол для контейнеров очень урезан по функционалу, попробуем это исправить.
nano /etc/vz/vz.conf

Комментируем текущую строку IPTABLES и вместо нее добавляем
IPTABLES="ipt_owner ipt_REDIRECT ipt_recent ip_tables iptable_filter iptable_mangle ipt_limit ipt_multiport ipt_tos ipt_TOS ipt_REJECT ipt_TCPMSS ipt_tcpmss ipt_ttl ipt_LOG ipt_length ip_conntrack ip_conntrack_ftp ipt_state iptable_nat ip_nat_ftp"

сохраняемся и перезапускаем VZ
/etc/init.d/vz restart

После этого внутри контейнеров мы сможем нормально настроить фаирвол.

Добавляем модули, касающиеся фаирвола, при загрузке ядра на гипервизоре (лишний шаг, но на всякий случай)
nano /etc/modules

ipt_MASQUERADE
ipt_helper
ipt_REDIRECT
ipt_state
ipt_TCPMSS
ipt_LOG
ipt_TOS
iptable_nat
ipt_length
ipt_tcpmss
iptable_mangle
ipt_limit
ipt_tos
iptable_filter
ipt_ttl
ipt_REJECT
loop

Фаирвол на самом гипервизоре
Пример готового фаирвола для гипервизора под спойлером
#!/bin/sh
### BEGIN INIT INFO
# Provides: iptables.sh
# Required-Start: $all
# Required-Stop: $all
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: My firewall
# Description: Rico-X FIREWALL
### END INIT INFO
# /etc/init.d/iptables

IPT=/sbin/iptables

case "$1" in
start)
echo "Starting iptables"

sysctl -w net.ipv4.tcp_synack_retries=1
sysctl -w net.ipv4.tcp_max_syn_backlog=4096
sysctl -w net.ipv4.tcp_fin_timeout=10
sysctl -w net.ipv4.tcp_syncookies=1
sysctl -w net.ipv4.tcp_keepalive_intvl=10
sysctl -w net.ipv4.tcp_keepalive_probes=5
sysctl -w net.ipv4.tcp_keepalive_time=60
sysctl -w net.ipv4.conf.default.rp_filter=1
#sysctl -w net.ipv4.ip_forward=0

# Запрещаем подключение к серверу
$IPT -P INPUT DROP
$IPT -P FORWARD ACCEPT
$IPT -P OUTPUT ACCEPT

# Позволяем входящие и исходящие соединения, инициированные уже установленными соединениями
$IPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

# Открываем свободный доступ для lo интерфейса
$IPT -A INPUT -i lo -j ACCEPT

# Открываем свободный доступ для внутренней сети
$IPT -A INPUT -i eth1 -j ACCEPT
$IPT -A INPUT -i vmbr1 -j ACCEPT
# Открываем ресурсы необходимые для работы кластера
$IPT -A INPUT -m addrtype --dst-type MULTICAST -j ACCEPT
$IPT -A INPUT -p udp -m state --state NEW -m multiport --dports 5404,5405 -j ACCEPT

# Блокируем все попытки входящих TCP-соединений не SYN-пакетами
$IPT -I INPUT -m conntrack --ctstate NEW -p tcp ! --syn -j DROP

# Открываем доступ к необходимым сервисам
$IPT -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT ## SSH
$IPT -A INPUT -p tcp -m tcp --dport 5900:5999 -j ACCEPT ## VNC
$IPT -A INPUT -p tcp -m tcp --dport 8006 -j ACCEPT ## Proxmox panel

# Вводим ограничения для новых подключений по SSH (не больше 4 в минуту)
$IPT -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP

# Запрещаем запрос имен netbios
$IPT -A INPUT -p tcp --dport 137:139 -j DROP
$IPT -A INPUT -p udp --dport 137:139 -j DROP

# Разрешаем определенные ICMP пакеты
$IPT -A INPUT -p ICMP --icmp-type 8 -j ACCEPT
$IPT -A INPUT -p ICMP --icmp-type 11 -j ACCEPT

# Отклоняем все с ошибками
$IPT -A INPUT -m state --state INVALID -j DROP

# Разрешаем прохождение DHCP запросов через iptables.
$IPT -A INPUT -p udp -m udp --dport 68 --sport 67 -j ACCEPT

# Блокируем порт-сканнеры
$IPT -A INPUT -m state --state NEW -p tcp --tcp-flags ALL ALL -j DROP
$IPT -A INPUT -m state --state NEW -p tcp --tcp-flags ALL NONE -j DROP

# Антиспуффинг
$IPT -A INPUT -p tcp --tcp-flags ALL FIN,URG,PSH -j DROP
$IPT -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
$IPT -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
$IPT -N SYN_FLOOD
$IPT -A INPUT -p tcp --syn -j SYN_FLOOD
$IPT -A SYN_FLOOD -m limit --limit 2/s --limit-burst 6 -j RETURN
$IPT -A SYN_FLOOD -j DROP

;;
stop)
echo "Stopping iptables"

$IPT -F
$IPT -X

$IPT -P INPUT ACCEPT
$IPT -P OUTPUT ACCEPT
$IPT -P FORWARD ACCEPT
;;
*)
echo "Usage: /etc/init.d/iptables {start|stop}"
exit 1
;;
esac

exit 0

3. Разные мелочи


Правильный часовой пояс в контейнерах
mv /etc/localtime  /etc/localtime_org && ln -s /usr/share/zoneinfo/"Europe/Simferopol" /etc/localtime && date

Убираем бесполезное сообщение при входе в гипервизор через web-интерфейс.
В файле /usr/share/pve-manager/ext4/pvemanagerlib.js находим строку
if (data.status !== 'Active') {

и заменяем на
if (data.status == 'Active') {

Иногда с квотами возникает неприятность Proxmox: ‘exit code 60′ – corrupt quota file и виртуалка не стартует,
просто перезапустим квоты.
vzquota off  [VEID]
vzquota : (error) Quota is not running for id  [VEID]
vzquota : (warning) Repairing quota: it was incorrectly marked as running for id  [VEID]
vzquota on  [VEID]

Если нарушен кворум (cluster not ready - no quorum), а работать с остатками кластера нужно,
устанавливаем размер кворума, равным размеру текущих живых нод
pvecm e (количество живых нод) 

Команды управления OpenVZ
Старт [VEID] ОС
vzctl start  [VEID]

Подключаемся гостевой ОС
vzctl enter  [VEID]

Остановка
vzctl stop  [VEID]

Рестарт
vzctl restart  [VEID]

Удаление
vzctl destroy  [VEID]

Посмотреть статус
vzlist -a 


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

UPD-1: Проброс vlan

Проброс виланов в контейнер делается в 2 этапа. Покажу на примере виланов 151,152,666
На гипервизоре:
В /etc/network/interfaces
добавляем
auto vlan151
iface vlan151 inet manual
	vlan_raw_device eth0

auto vlan152
iface vlan152 inet manual
        vlan_raw_device eth0

auto vlan666
iface vlan666 inet manual
        vlan_raw_device eth0

auto vmbr151
iface vmbr151 inet static
	address  0.0.0.0
	netmask  255.255.255.255
	bridge_ports vlan151
	bridge_stp off
	bridge_fd 0

auto vmbr152
iface vmbr152 inet static
        address  0.0.0.0
        netmask  255.255.255.255
        bridge_ports vlan152
        bridge_stp off
        bridge_fd 0


auto vmbr666
iface vmbr666 inet static
        address  0.0.0.0
        netmask  255.255.255.255
        bridge_ports vlan666
        bridge_stp off
        bridge_fd 0

Устанавливаем поддержку виланов
apt-get install vlan

Затем применяем их
ifup vlan151
ifup vlan152
ifup vlan666

Проверяем что интерфейсы поднялись через ifconfig

Затем в вебморде выбираем нужный контейнер, идем на закладку сеть(network), добавляем сетевое оборудование, примерно как на скриене

в качестве бриджа выбираем интерфейс с нужным виланом.


В контейнере:
добавляем
Просто настройки на интерфейсе, которые должны быть на вилане, пример для контейнера на debian
В /etc/network/interfaces.tail
auto eth1
iface eth1 inet static
	address 10.7.10.5
	netmask 255.255.255.0

Затем
cat /etc/network/interfaces.tail >> /etc/network/interfaces

Файл *.tail нужен для того, чтоб если мы изменим настройки сети в контейнере через web интерфейс, сохранить настройки виланов внутри контейнера.


Есть и другой вариант проброса виланов, но я использую такой, так-как при нем можно использовать удобно один и тот-же вилан в нескольких виртуалках, что часто нужно.
Поделиться публикацией
Комментарии 31
    0
    Отличная статья, как раз на днях понадобилось пробрасывать usb-токен в контейнер.
    Помимо описанного варианта поднятия иксов для скайпа есть вариант использования xvfb, он особых махинаций не требует.
      +1
      Скайп просто пример, мне нужно было поднять VNC внутри контейнера с иксами.
      0
      Господа, сливающие карму, аргументируйте пожалуйста.
        0
        Не всем быть достойными донами, отвечающими за свои действия, менталитет такой, исподтишка, все-равно никто не увидит, что на улице, что на дороге, что в общественных местах, что в интернете. Увы.
        +2
        А я тут как раз сегодня резервное копирование поднастраивал. Могу поделиться несколькими ньюансами.

        1. Если у вас контейнер на локальном LVM, то режим бэкапа снимком (mode snapshot) не будет работать если хранилище бэкапов находится на том же разделе LVM, а бэкап автоматически будет производиться в режиме suspend, что выведет контейнер в оффлайн на некоторое время. Последнее может легко пройти незамеченным для администратора, но не для аптайма с точки зрения внешних наблюдателей. Проверьте себя:
        grep -ir "trying 'suspend' mode instead" /var/log/vzdump/


        2. В интерфейсе proxmox опущено несколько очень полезных опций бэкапа утилиты vzdump, но их можно дописать вручную в /etc/cron.d/vzdump, причем у меня они даже сохраняются после изменения задачи через вебморду (хотя лучше всё равно проверять):
        --exclude-path "/var/www/temp-or-big-files/"

        --script /root/bin/send-backups-to-remote-host.sh


        3. send-backups-to-remote-host.sh
        #!/bin/bash
        RSYNC_TARGET="limited-user@example.com:/backups/incoming/"
        
        if [ "$1" == "backup-end" ]; then
          /usr/bin/rsync --bwlimit 5000 -a $TARFILE $RSYNC_TARGET
        fi

        Полный список доступных событий и переменных можно посмотреть в файле /usr/share/doc/pve-manager/examples/vzdump-hook-script.pl.

        4. Закрытие security issue связанного с п.3 (немного оффтоп).
        Т.к. бэкапы на удаленную машину производятся автоматически, на сервере proxmox остается ssh-ключ. Значит, с помощью него злоумышленник, получивший доступ к серверу, может попытаться испортить бэкапы на удаленной машине. Чтобы не допустить этого, можно использовать замечательный демон incron, использующий механизм ядра inotify, а значит — почти бесплатный и запускающий нужное нам действие ровно в тот миг, когда нам нужно:
        sudo apt-get install incron

        Incron перенял многое у cron:
        sudo incrontab -e

        Теперь пропишем в открывшийся файл запуск скрипта (/sbin/protect_backups.sh) с передачей в качестве параметра полного пути к файлу ($@$#) при событии закрытия файла на запись (IN_CLOSE_WRITE) для пути /backups/incoming/.
        /backups/incoming/ IN_CLOSE_WRITE /sbin/protect_backups.sh $@$#

        В скрипте /sbin/protect_backups.sh мы забираем у юзера, закачивающего бэкапы, возможность их изменять после окончания закачки:
        #!/bin/sh
        /bin/chmod 660 $1
        /bin/chown regular-user:regular-user $1

        Не забываем делать скрипты исполняемыми:
        sudo chmod a+x /sbin/protect_backups.sh

        Теперь сервер с proxmox по cron'у ночью запускает резервирование контейнера, в ходе которого архив автоматически доставляется на удаленную машину. После окончания доставки, удаленная машина защищает бэкап от возможных инсинуаций. В итоге получилась безопасная, легкая, понятная и ненавязчивая система резервного копирования контейнеров без применения каких-либо спец.средств (считаю, что incron должен быть в стандартной поставке дистрибутивов linux).
          0
          Отличное дополнение, если о первом пункте знал и просто делаю перекрестный бэкап + бэкап на общедоступный сторадж, то о безопасности бэкапов на удаленном хосте даже не задумался. Утащил к себе в заметки.
            0
            Кстати, сегодня поутру выяснилось, что рецепт с incron выше нерабочий, т.к. rsync сначала закачивает архив во временный файл, а потом переименовывает в оригинальное название, а до incron'а доходит событие со старым названием файла. Чтобы rsync работал в этом смысле как cp или scp, нужно запускать его с опцией --inplace. Чуть менее хорошее, но тоже рабочее решение — мониторить incron'ом событие IN_MOVED_TO.

            Отлаживать inotify можно так:
            sudo inotifywait -m /backups/incoming/
            
            0
            В интерфейсе proxmox опущено несколько очень полезных опций бэкапа утилиты vzdump

            Кстати о какой версии речь? А то я вот что то в третьей потерял вообще возможность добавить задачу автоматического бэкапа.
            Не вижу ее в упор. Не прикрутили чтоль. В 1.9 была.
              +1
              Версия Proxmox — последняя, 3.1. В меню-дереве слева — «Datacenter», справа таб «Backup».
            0
            Как починить загрузку бекапов? Опять таки последняя версия ProxMox. Без кластера, локальное хранилище. Бэкапы для хранилища разрешил, закачать через веб-морду не дает. Точнее закачивать поначалу закачивает, ждешь себе, а в конце сообщает — извини бэкапы не разрешены для этого хранилища. Хотя они разрешены. Гипревизор перезапускал. В итоге добавил к файлам расширение iso и закачал как образы, потом ручками мувал на узле.
            Скачать бэкапы, кстати тоже низзя. И апач выпиляли. Пытался подкладывать их в директорию с картинками интерфейса — фиг все равно не дает скачать. Плюнул поставил vsftpd. Забодал меня этот 3-ий проксмокс. Такое впечатление, что это специально для платной поддержки сделано.

            Второй у меня на одном объекте уходит время от времени(раз в квартал где то) в прострацию. К сожалению добраться туда и выяснить причину не могу. Там жмут на кнопку ресет и все подымается.
            Самый стабильный пока 1.9.

            Проброс nfs на каком контейнере? Для 1.9 и ubuntu10.04 нифига у меня это не работало. nfs-common не ставился в контейнер. Что то там вешалось мертво. Выходил из положения через маунт nfs в гипервизор, а в контейнер пробрасывал через bind. Но при таком способе при бэкапе контейнера все разваливается. Надо снова биндить.
              0
              По поводу 3.1 и бэкапов. Я один раз попробовал закачать браузером — PVE тоже выдал какую-то ошибку, но я, честно говоря, вообще не расстроился, т.к. думаю что доверять браузеру такие вещи нельзя. Тем более, что нет докачки при обрыве.

              То, что теперь обходятся без Apache наверное скорее плюс. При желании его же можно поставить также как и vsftpd. Правда, я бы не ставил ни того, ни другого, т.к. это значит передавать нешифрованые бэкапы по нешифрованому каналу. Если не заморачиваться с HTTPS или FTPS, конечно. По-моему, SFTP через SSH намного безопаснее, проще, удобнее и быстрее.
                0
                Писал для версии 3.1 (актуальная на сегодня).
                По бэкапам, первое разрешаем для локального хранилища вообще работать с бэкапами:
                Датацентр -> Хранилище -> выбрать локальное -> отметить в списке бэкапы.

                Затем переходим в само хранилище и можем закачать бэкап через web интерфейс.

                Хотя лично я практически все делаю через ssh, в том числе переброс бэкапов.

                В 1.9. очень уж древнее ядро и например завести gsm модемы (huawei e173) в качестве шлюза внутри контейнера OpenVZ нормально не выйдет, получим кучу проблем с передачей голоса, так что нужно свежее ядро.

                nfs пробрасывал в контейнеры Debian 6,7 CentOs 5,6 проблем не возникало. Я использую nfs для хранения больших неизменяемых файлов либо большого количества файлов вне контейнера, чтоб они не попадали в периодический бэкап контейнера, например, записи разговоров телефонии, записи камер видеонаблюдения и т.п. Убунту у себя в инфраструктуре не использую, с чем связаны проблемы не скажу, но может ее стоит обновить до актуальной LTS.
                  0
                  вот именно показанное на картинках не работает.
                  я тоже делал перепроброс бэкапов по ssh, только под виндой утилитой psftp очень медленно получается.
                  может psftp виновата а не ssh.
                    0
                    А какой размер бэкапов, по симптомам похоже что фаил выходит за какие-то лимиты разрешенные на веб сервере. Из винды можно закидывать через FileZilla по sftp выходит достаточно быстро и ничего ставить не нужно дополнительно на сервере.
                      0
                      тогда бы и исошники не заливались. а они заливаются. размеры 500-600Мб.
                0
                Надо сделать маршрутизатор VLAN'ов в виртуалке.
                Т.е. реализовать схему router-on-a-stick.
                Как пучок VLAN'ов пробросить в контейнер или виртуалку?

                  +1
                  Проброс виланов в контейнер делается в 2 этапа. Покажу на примере виланов 151,152,666
                  На гипервизоре:
                  В /etc/network/interfaces
                  добавляем
                  auto vlan151
                  iface vlan151 inet manual
                  	vlan_raw_device eth0
                  
                  auto vlan152
                  iface vlan152 inet manual
                          vlan_raw_device eth0
                  
                  auto vlan666
                  iface vlan666 inet manual
                          vlan_raw_device eth0
                  
                  auto vmbr151
                  iface vmbr151 inet static
                  	address  0.0.0.0
                  	netmask  255.255.255.255
                  	bridge_ports vlan151
                  	bridge_stp off
                  	bridge_fd 0
                  
                  auto vmbr152
                  iface vmbr152 inet static
                          address  0.0.0.0
                          netmask  255.255.255.255
                          bridge_ports vlan152
                          bridge_stp off
                          bridge_fd 0
                  
                  
                  auto vmbr666
                  iface vmbr666 inet static
                          address  0.0.0.0
                          netmask  255.255.255.255
                          bridge_ports vlan666
                          bridge_stp off
                          bridge_fd 0
                  

                  Устанавливаем поддержку виланов
                  apt-get install vlan
                  

                  Затем применяем их
                  ifup vlan151
                  ifup vlan152
                  ifup vlan666
                  

                  Проверяем что интерфейсы поднялись через ifconfig

                  Затем в вебморде выбираем нужный контейнер, идем на закладку сеть(network), добавляем сетевое оборудование, примерно как на скриене

                  в качестве бриджа выбираем интерфейс с нужным виланом.


                  В контейнере:
                  добавляем
                  Просто настройки на интерфейсе, которые должны быть на вилане, пример для контейнера на debian
                  В /etc/network/interfaces.tail
                  auto eth1
                  iface eth1 inet static
                  	address 10.7.10.5
                  	netmask 255.255.255.0
                  

                  Затем
                  cat /etc/network/interfaces.tail >> /etc/network/interfaces
                  

                  Файл *.tail нужен для того, чтоб если мы изменим настройки сети в контейнере через web интерфейс, сохранить настройки виланов внутри контейнера.


                  Есть и другой вариант проброса виланов, но я использую такой, так-как при нем можно использовать удобно один и тот-же вилан в нескольких виртуалках, что часто нужно.
                  0
                  Может быть кто знает почему не срабатывает автоматический бекап контейнеров, в которых есть примонтированные ресурсы NFS. Ошибка такая:
                  Backup of VM 118 failed — command 'vzctl --skiplock chkpnt 118 --suspend' failed: exit code 16
                  Другие контейнеры бекапятся.
                    0
                    Покажите полный вариант ошибки из лога, скорее всего что-то не размонтируется, но по этой строке не угадать. Старые версии ругались на cpt лечилось командой modprobe vzcpt и добавлением модуля в загрузку, но если версия свежая нужен полный лог.
                      0
                      Оказалось в логах nginx тупит:

                      Jan 25 01:33:34 INFO: suspend vm
                      Jan 25 01:33:34 INFO: Setting up checkpoint…
                      Jan 25 01:33:34 INFO: suspend…
                      Jan 25 01:33:37 INFO: Can not suspend container: Resource temporarily unavailable
                      Jan 25 01:33:37 INFO: Error: task 724055,29828(nginx) is traced. Checkpointing is impossible.
                      Jan 25 01:33:37 INFO: Error: suspend is impossible now.
                      Jan 25 01:33:37 INFO: Error: task 724055,29828(nginx) is traced. Checkpointing is impossible.
                      Jan 25 01:33:37 INFO: Error: suspend is impossible now.
                      Jan 25 01:33:37 INFO: Error: task 724055,29828(nginx) is traced. Checkpointing is impossible.
                      Jan 25 01:33:37 INFO: Error: suspend is impossible now.
                      Jan 25 01:33:37 INFO: Checkpointing failed
                      Jan 25 01:33:42 ERROR: Backup of VM 104 failed — command 'vzctl --skiplock chkpnt 104 --suspend' failed: exit code 16
                        0
                        Ну теперь думаю и помощь не нужна, сами подправите nginx
                          0
                          дело в том что я очень понимаю какая с ним может быть проблема и как его подправить, если вам известны такого рода ошибки, пожалуйста подскажите
                            0
                            В самом контейнере nginx завершается нормально? В его логах при завершении ошибок никаких нет? Скорее всего если он завершается дольше определенного времени, то истекает время таймаута на завершение виртуалки и бэкап не запускается. Если nginx ссылается на файлы, которые находятся на nfs, возможно nfs завершается раньше и это мешает нормально завершиться nginx-у. Попробуйте выключить контейнер вручную и посмотрите как долго она завершается и какие ошибки при этом идут.
                              0
                              Да, nginx без проблем останавливается. Но я не пойму вот чего, ведь в процессе бекапа не происходит полного выключения контейнера, а только приостановка, и в этом случае система не получает сигнала к выключению и не гасит работающие процессы. Как следствие и nginx выключаться не должен. Или я чего то не понимаю?
                                0
                                Зависит от режима бэкапа, как писали выше
                                1. Если у вас контейнер на локальном LVM, то режим бэкапа снимком (mode snapshot) не будет работать если хранилище бэкапов находится на том же разделе LVM, а бэкап автоматически будет производиться в режиме suspend, что выведет контейнер в оффлайн на некоторое время.

                                Попробуйте остановить nginx и провести бэкап вручную, ошибки быть недолжно. Хотя долго можно гадать что происходит, надо подробно смотреть логи контейнера.
                          0
                          А покажите содержимое dmesg в момент этой ошибки? Это либо баг OpenVZ либо фича OpenVZ :)
                      0
                      Здравствуйте товарищи. Если уж такая тема то хотел спросить никто не знает как поменять пароль скриптом из консоли
                      сама команда вот такая
                      pveum passwd user@pve
                      Но можно всё поменять только в ручную. Вот такое не проходит
                      <code>echo -e "new_password\nnew_password" | pveum passwd user@pve
                        0
                        Не пробовал, но man подсказывает
                        pveum passwd <userid> -password <string> [OPTIONS] 
                        
                          0
                          Да это видел. Увы но в ответе только
                          400 wrong number of arguments
                          Как решить так и не нашёл.
                            0
                            Не подскажу, у меня завязка на LDAP, встроенными юзерами не пользуюсь, как предположение возможно --password и/или пароль в кавычках.
                              0
                              Увы но всё перепробовал. Ldap интересно, но будет нужен клиент.

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

                      Самое читаемое