Установка Proxmox VE на Debian 7 (Wheezy), а так же рабочие момены

Debian 7На официальном сайте Proxmox VE есть официальное же руководство по установке Proxmox VE на уже работающий Debian. Все инструкции в интернете не что иное, как отсебячий перевод, без комментариев и разбора спорных моментов. В данной статье я привожу опять же перевод, но с некоторыми комментариями и объяснениями не однозначных моментов.

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

1. Возможность сделать LVM.

2. Специфическая разбивка дисков (не берем во внимание ситуации, когда используется аппаратный RAID с отсутствующими в сборке драйверами, или когда надо сделать программный RAID).

Начнем со второй причины, а именно с разбивки дисков.

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

Но если использовать имеющуюся машину только как сервер виртуализации, надо ли это? Proxmox VE генерирует не так много логов, система в дистрибутиве идет минимальная, а большой /home  вполне пригодится для хранения шаблонов и исошников.

Отсюда мой вывод, специфической разбивкой дисков можно пренебречь и использовать предложенную в дистрибутиве Proxmox VE.

Теперь первая и самая главная причина, это LVM. Мало кто задумывается для чего нужен LVM в системах виртуализации, многие заканчивают думать на такой мысли: «LVM позволяет делать снапшоты, и это круто, я смогу бэкапить машины не прерывая их работы. Или делать снапшоты (снимки), а после изменений возвращаться к ним, как делаю это в VirtualBox или VMware Workstation«.

Но тут ждет разочарование, во первых, снапшоты (тут надо уточнить, под снапшотом тут понимается бэкап машины без прерывания ее работы) на LVM сильно тормозят виртуальную машину и всю дисковую систему сервера, а во вторых, в Proxmox VE на LVM доступен только RAW формат дисков, а он не поддерживает снапшоты в классическом понимание (как снимки в VirtualBox или VMware Workstation), остаются только снапшоты средствами самого LVM, но это опять же дикие тормоза ведь когда есть LVM снапшот, то при записи данных на LV экстент сначала переписывается на снапшотный том и только потом на него записываются новые данные. То есть, запись на том приводит к двум дополнительным операциям: чтению оригинального дома + записи на снапшот. Эти лишние операции и съедают скорость. И чем больше снапшотов, тем медленнее работает дисковая систем. К тому же попытки сделать такой снапшот через консоль (в обход веб морды) почему то в 90% случаев гробят машину.

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

Дело в том, что при создание жесткого диска как объекта (файла) в файловой системе сервера, этот жесткий диск подвержен всем влияниям (достоинствам и недостаткам) той файловой системы на которой находится. Так же этот объект пострадает в случае повреждения родительской файловой системы.

Что же касается LVM, то при его использование жесткий диск виртуальной машины по сути является разделом, никак не относящимся к родительской системе и ее файловой системе в частности, от этого и увеличение производительности за счет сокращения уровней абстракции (нет наслоения файловых систем одной на другу, если так можно выразится), к RAW дискам находящимся на LVM нет необходимости применять кэширование, что благотворно влияет на надежности системы.

Про кэширование хотелось бы упомянуть более подробно. Кэширование, это такая штука, которая применяется и на уровне хост системы (родительской) к контейнеру жесткого диска виртуальной машины, как обычному фалу (настраивается в вэб морде), и на уровне виртуальной машины (ОС самой машины). Отсюда вытекает проблема надежности «конструкции», так как дисковый кэш это передержка данных в оперативной памяти, и каждая система отвечает за этот процесс сам (хост и гостевая), в случае падения гостевой системы, данные находящиеся в оперативной памяти хост системы с очень большой вероятностью не верно запишутся в образ жесткого диска, чем похерят его и соответственно виртуальную машину (классно так, на ровном месте из за бзода виртуальной машины потерять ее). Это происходит из за того, что хост система не знает о кэширование гостевой системы, гостевая система применяя кэш периодически сбрасывает данные на свой диск, но при падение, это процесс не завершается, а хост система не может его завершить, так как она не в курсе чего и куда, она видит завершение процесса доступа к файлу и тупо очищает блоки памяти.

Более четко не могу сформулировать, тут лучше было бы нарисовать этот процесс, но мне лень.

А теперь непосредственно установка Proxmox VE на новенький Debian 7 (Wheezy).

Первым делом правим файл /etc/hosts так, чтобы имя сервера (которое было указано при установке) разрешалось не 127.0.1.1, а в тот ip который присвоен интерфейсу через который будем управлять Proxmox VE, без этого Proxmox VE не установится.

127.0.0.1 localhost
192.168.1.1 sr2.itroad.ru sr2

Далее добавляем в список репиозиториев репозиторй Proxmox VE

deb http://mirror.yandex.ru/debian/ stable main non-free
deb-src http://mirror.yandex.ru/debian/ stable main non-free

deb http://security.debian.org/ stable/updates main non-free
deb-src http://security.debian.org/ stable/updates main non-free

deb http://mirror.yandex.ru/debian stable-updates main non-free
deb-src http://mirror.yandex.ru/debian stable-updates main non-free

# Репозиторий Proxmox VE
deb http://download.proxmox.com/debian wheezy pve-no-subscription

Добавляем ключ репозитория и обновляемся

wget -O- "http://download.proxmox.com/debian/key.asc" | apt-key add -
aptitude update
aptitude upgrade

Смотрим какое pve ядро есть на данный момент и ставим его вместе с pve-firmware (пропиетарные дровишки для разного оборудования).

aptitude search pve-kernel
aptitude install pve-firmware pve-kernel-2.6.32-20-pve

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

После этого перезагружаемся и убеждаемся, что стартуем с новым ядром pve

uname -r

Получаем положительный ответ
2.6.32-20-pve

Если ядро осталось прежним, можно выбрать один из двух вариантов.

1. Как рекомендует инструкция, просто удалить ядро Debian, тогда ядро Proxmox будет загружаться автоматом.
2. Изменить порядок загрузки, оставив ядро Debian.

Я из соображений нежности предпочитаю второй вариант. Для изменения порядка загрузки делаем следующее:

1. Смотрим какие есть ядра к загрузке:

grep menuentry /boot/grub/grub.cfg

и понимаем какое по порядку ядро pve с учетом того, что нумерация идет с ноля, а не единицы.

У меня это выглядит так:

menuentry ‘Debian GNU/Linux, с Linux 3.2.0-4-amd64′
menuentry ‘Debian GNU/Linux, с Linux 3.2.0-4-amd64 (режим восстановления)’
menuentry ‘Debian GNU/Linux, с Linux 2.6.32-26-pve’
menuentry ‘Debian GNU/Linux, с Linux 2.6.32-26-pve (режим восстановления)’

Т.е. у меня нужное ядро с учетом отсчета от ноля будет 2.

Зная номер ядра, правим меню загрузки:

nano /etc/default/grub

Меняем параметр GRUB_DEFAULT= ставя нужную цифру, в моем случае 2.

И обновляем меню загрузки:

update-grub

После этого будет загружаться нужное ядро и старое ядро будет в наличие, на всякий случай.

Теперь ставим пакет Proxmox VE предварительно посмотрев его последнюю версию

aptitude search proxmox-ve
aptitude install proxmox-ve-2.6.32

Веб-интерфейс раньше работал через Apache, сейчас имеется встроенный web сервер, из за чего теперь при установке перестал создаваться конфигурационный файл виртуального сайта Apache. В связи с чем, если у вас уже стоит Apache для каких то нужд, веб морда Proxmox VE работать не будет (по крайней мере редирект с ip на нужный порт и https), поэтому для удобства лучше создать конфиг руками.

Создаем конфиг:

touch pve-redirect.conf /etc/apache2/sites-enabled

И добавляем в него это:

<VirtualHost *:80>
    RewriteEngine on
    RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
    RewriteRule .* - [F]
    RewriteRule ^/(.*) https://%{HTTP_HOST}:8006/$1 [L,R]
</VirtualHost>

<VirtualHost *:443>
    SSLEngine on
    SSLProtocol all -SSLv2
    SSLCertificateFile /etc/pve/local/pve-ssl.pem
    SSLCertificateKeyFile /etc/pve/local/pve-ssl.key

    RewriteEngine on
    RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
    RewriteRule .* - [F]
    RewriteRule ^/(.*) https://%{HTTP_HOST}:8006/$1 [L,R]
</VirtualHost>

В официальном руководстве предлагают поставить дополнительные компоненты такой вот строчкой:
apt-get install ntp ssh lvm2 postfix ksm-control-daemon vzprocps open-iscsi bootlogd

Но с этой строчкой я не согласен, а почему, расскажу ниже.

Если у вас нет кластера из нескольких машин, вам не нужен NTP.

SSH и так должен быть, не через физ же интерфейс мы все это ставили (хотя кто как, найдутся и такие извращенцы).

lvm2 или вообще не нужен, если вы решили делать все без LVM или он уже должен стоять.

А вот ksm-control-daemon очень нужная вещь, это пакет позволяет виртуальным машинам использующим одинаковые данные в памяти, не дублировать их, а использовать одни блоки на всех. Это существенно экономит память и добавляет немножко быстродействия.

Если вы не собираетесь использовать сервер с гипервизором под что то еще, то postfix явно лишний, для целей рассылки почты о событиях системы лучше подойдет легковесный MTA sSMTP который у меня и установлен.

Пакет vzprocps лично мне не нужен, этот пакет предоставляет ps и top утилиты которые можно использовать для просмотра процессов в гостевой системе из хост системы. Работают они только с OpenVZ машинам (что естественно означает только Linux системы). Рассчитаны они в первую очередь на хостинг-провайдеров у которых есть необходимость посмотреть что же за процесс у клиента грузит машину и затем написать в личный кабинет сообщение типа: «php скрипты вашего сайта не оптимизированы и потребляют слишком много ресурсов, предоставление вам услуг временно приостановлено». Хотя можно придумать для них более приземленное применение. Как пример это ситуация полного исчерпание ресурсов машины до такой степени, что даже vzctl enter 101 не работает а посмотреть процесс-злоумышленник надо в целях предотвращения подобного в будущем.

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

По итогу, моя строка «доустановки» выглядит так:

aptitude install ksm-control-daemon bootlogd

После всех выше описанных действий можно еще раз перезагрузиться и попробовать зайти в веб-интерфейс по адресу https://192.168.1.1:8006, или какой там ip вы указали в файле /etc/hosts.

На всякий случай хочу дать ссылку на скачку iso образа с драйверами под Windows системы для виртуальных устройств virtio, которые дают некоторый прирост в скорости по сравнению со стандартными устройствами.

Ко всему прочему, я очень рекомендую установить на сервер связку указанную в этой статье и получать все сообщения о странностях на сервере.

 

Дополнение от 4.10.2013

У разработчиков Proxmox VE произошли некоторые изменения в подходе к продукту, теперь есть платная и бесплатная версия. Подробности тут.

 

Дополнение от 2.10.2014

В последнее время начал активно использовать VZ контейнеры и столкнулся со следующей проблемой. По умолчанию, контейнеры работают из /var/lib/vz а у меня он находится не на быстром рейде.

Пришлось решать вопрос быстродействия.

Для этого на быстром рейде, который отдан весь под LVM раздел выделил кусочек размером в 100Gb, смонтировал его в /mnt, остановил машины, остановил VZ демон  service vz stop перенес содержимое /var/lib/vz на смонтированный раздел и сделал с перенесенных папок сим линки обратно в /var/lib/vz, снова запустил демона.

Все заработало, машины стали работать гораздо быстрее, но начались новые траблы.

При бэкапе машин на nfs хранилище, да и вообще за пределы /var/lib/vz начались дикие тормоза, как позже выяснилось, машины вообще отказывались бэкапиться в режиме снапшота.

INFO: mode failure — unable to detect lvm volume group
INFO: trying ‘suspend’ mode instead
INFO: backup mode: suspend

После множества экспериментов оказалось что дело в симлинках, они не подходят и надо этот кусочек в 100 гигов монтировать прямо в /var/lib/vz.

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

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

Оказалось, что мои перемещения вообще не при чем, оказалось, что разработчики изменили планировщик ввода-вывода — ссылка

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

Смотрите так же:

Установка Proxmox VE на Debian 7 (Wheezy), а так же рабочие момены: 54 комментария

  1. Подскажите у меня после ребута сервера все виртуальные машины не стартуют через автозапуск, приходиться вручну их включать
    в описании задачи Srart all VMs and Containers — TASK ERROR: cluster not ready — no quorum?
    не знаю где смотреть, подскажите пожалуйста
    спасибо

    1. Если сервер один, или был в кластере, который потом был разобран, можно попробовать pvecm expected 1

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

  2. Какие-то новые нюансы в связи с выходом версии 3.3. будут присутствовать при установке?

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

      По установке, надо еще модули ставить отдельно для iscsi, цепха и некоторых других плюшек, но это не обязательно.

      1. ого,чудненько, особенно что «наконец ушли от vnc на основе джавы, теперь это на html5», а с 3.2 нормально обновится?

          1. а как обновляли?,у меня через вкладку «updates» пишет что то про подписку:
            You do not have a valid subscription for this server. Please visit http://www.proxmox.com to get a list of available options.,
            репы из этой статьи

  3. Привет. не могу соединится с виртуалками kvm по протоколу spice, Remote-viewer сначала пытается соединится потом пишет «Unable to connect to the graphic server» что может быть? proxmox 3.2

    1. Надо в оборудование вирт машины выбрать соответствующую видео карту, поставить драйвер на нее и тогда все будет хорошо. Будет работать и только с картой, но тормозно.

      1. так и выбрал, http://joxi.ru/aV6-U4wyTJClZFEdDtc
        по идее вообще должно работать сразу после включения виртуалки, может сто то не доставил на хост из последнего в инструкции? например тут все работает http://www.proxmox.com/ru/training/video-tutorials/item/install-windows-7-with-spice

        1. Если выбрана нужная видюха, и на комп с которого подключаешься поставлен Remote viewer (A SPICE/VNC client) то все должно работать.

          А файл подключения то при нажатие на кнопку спайса скачивается? Ну или хотя бы начинает скачиваться?

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

        2. Не прочитал ваш коммент выше про установленный вьювер. Единственное что приходит мне в голову в таком случае, это то, что может на самом гипервизоре файрвол стоит?

  4. Приветствую),поставил дебиан 7.5 ставлю последнее на данный момент ядро 3.10.0-3-pve ,не грузится, вообще ни какое из 3 версии, работает только 2.6 pve но оно старое совсем и не хочется его использовать, у кого работают последние ядра pve?

    1. У меня все сервера которые я делал в продакшене стоят теперь, особо не поэкспериментируешь, так что я новое ядро не пробовал, хотя читаю постоянно листы изменений по проксмоксу, но чего то интересного в нем не видел. Зачем на новое ядро то переходить?

      1. Все завелось,глюков пока не наблюдаю
        Зачем на новое ядро то переходить?
        Open VZ использует ядро хоста

          1. я строю систему документооборота на alfresco хочу все это дело завести на ubuntu 14.04 в open VZ, некоторые модули алфрески не работают со старыми ядрами

              1. вот пришлось)
                а подскажите если знаете:
                столкнулся с такой проблемой, а как дать инет промоксу через шлюз который поднят в нем http://joxi.ru/ckW1U_3JTJCNPtYoJiM

                1. Прописать маршрут через ip rout через нужное устройство и шлюз. У проксмокса по умолчанию так же vmbr стоит шлюзом, только 0. Что вообще ip rout показывает?

                    1. Ну верно все показывает, но я уже позже отписался, что так работать не будет, надо пробовать через интерфейс самой машины.

                2. Хотя нет, не так. Получается что инет выходит только с сет карты вирт машины, если там сетевуха как оборудование стоит, то это должно быть tap101i0 устройство.

                  А вообще какое то странное решение )) у меня даже в мысля никогда не было засунуть шлюз в виртуалку.

                  1. это плохо да?,появился более менее мощный сервер, было принято решение все сервера перенести в виртуальную среду, в том числе и шлюз, шлюз нормально раздает инет конторе, хосту инет нужен для обнов

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

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

                      Мне аж самому интересно, получится ли так, или нет.

                    2. )))так и есть, сегодня прописал в веб морде proxmox во вкладке dns ip прозрачного прокси который прописан шлюзом на eth1 и заработал инет)

  5. Здравствуйте.
    Подскажите, а как подцепить sSMTP вместо POSTFIX?
    У меня выдает ошибку: TASK ERROR: command ‘/etc/init.d/postfix start’ failed: open3: exec of /etc/init.d/postfix start failed at /usr/share/perl5/PVE/Tools.pm line 326

    1. Выдает ошибку просто потому, что если proxmox ставился на Debian, то postfix банально не установлен, да и не нужен он там для такой задачи, как отправка логов на почту.

      Воспользуйтесь первой частью это статьи https://www.itroad.ru/poluchaem-logi-linux-servera-po-pochte хотя и второй частью воспользоваться было бы не лишним.

      smtpd идеальное решение, если нужно только получать логи, а logcheck будет вам слать интересные места логов.

  6. Доброго времени суток!
    Делал по Вашему мануалу, но возникла проблема. В веб-консоле не могу поменять настройки интерфейсов и бриджей. Ни создать, ни отредактировать не получается. После того как что-то изменяю в окне бриджа или сетевой и нажимаю ОК появляется окно с ошибкой:
    Parameter verification failed. (400)
    comments: property is missing and it is not optional
    Два дня сижу над этой ошибкой и не знаю как ее решить. Гуглил , но именно в таком виде ошибка упоминается только пару раз, и решения там и близко нет.

    proxmox-ve-2.6.32: 3.1-121 (running kernel: 3.10.0-1-pve)
    pve-manager: 3.1-42 (running version: 3.1-42/d385f0d9)
    pve-kernel-2.6.32-27-pve: 2.6.32-121
    pve-kernel-3.10.0-1-pve: 3.10.0-5
    lvm2: 2.02.98-pve4
    clvm: 2.02.98-pve4
    corosync-pve: 1.4.5-1
    openais-pve: 1.1.4-3
    libqb0: 0.11.1-2
    redhat-cluster-pve: 3.2.0-2
    resource-agents-pve: 3.9.2-4
    fence-agents-pve: 4.0.5-1
    pve-cluster: 3.0-12
    qemu-server: 3.1-15
    pve-firmware: 1.1-1
    libpve-common-perl: 3.0-13
    libpve-access-control: 3.0-11
    libpve-storage-perl: 3.0-19
    pve-libspice-server1: 0.12.4-3
    vncterm: 1.1-6 vzctl: 4.0-1pve4
    vzprocps: 2.0.11-2
    vzquota: 3.1-2
    pve-qemu-kvm: 1.7-4
    ksm-control-daemon: 1.1-1
    glusterfs-client: 3.4.2-1

    Помогите пожалуйста.

    1. По умолчанию создается устройство vmbr0, оно уже есть, его надо только отредактировать. Если что то насоздавали, надо удалить. Что именно вы пишите в настройках vmbr0? Сколько сетевых карт на сервере? Физический доступ к серверу имеется? А то ведь есть такая примета, что игры с сетью или файрволом на удаленной машине, это к дороге )))

      1. После установки-первый вход в веб-консоль,вкладка Network имеет такой вид:
        eth0 Active Yes Autostart Yes Ip Address 192.168.0.27 Subnet mask 255.255.255.0 Gateway 192.168.0.10
        eth1 Active No Autostart No Ip Address — Subnet mask — Gateway —
        vmbr0 Active No Autostart No Ip Address — Subnet mask — Gateway —
        Пытаюсь отредактировать vmbr0, ввожу:
        Address 192.168.0.27 Subnet mask 255.255.255.0 Gateway 192.168.0.10
        Ставлю чeкбокс Autostart Bridge ports: eth0
        Жму ОК и вышеописанная ошибка. Пробовал другой Ip, пробовал очищать значения адресов в eth0, пробовал создавать новый бридж с eth1, пробовал активировать eth1. Всегда одна и та же ошибка. Получается есть вот эти «дефолтно-созданные» конфиги и отредактировать их невозможно. Можно только удалять сетевые и бриджи полностью.
        Доступ к серверу есть, так как это всё проделываю в вмваре, тестирую перед внедрением.
        В /etc/network/interfaces никакого упоминания о vmbr0.
        Ребут сервера не помогает.

        Единственные отличия между Вашим мануалом и вики proxmox, в том что я не использовал lvm при создании разделов, и ставил последние версии pve-kernel.

        1. Надо за один раз убрать у eth0 и всех других eth все параметры, убрать галку автостарта, и не нажимая применить, вписать адрес который был у eth0 в vmbr0, поставить галку о мосте с eth0, а уже потом жать применить.

          Если это не поможет, то надо руками править конфиги, но когда и если все заработает, надо повторить действия через веб морду, ибо она переписывает конфиг в соответствие с тем, что там вписано. Я на этом прокололся раз. Настроил все руками, даже не трогал веб морду, а через пол года работы морда каким то образом взяла и переписала все конфиги на то что в ней было вбито, а вбито ничего не было, при этом легла сетка.

          Вот как должно быть:

          # network interface settings
          auto lo
          iface lo inet loopback

          iface eth0 inet manual

          iface eth3 inet manual

          iface eth2 inet manual

          iface eth1 inet manual

          auto vmbr0
          iface vmbr0 inet static
          address 192.168.0.27
          netmask 255.255.252.0
          gateway 192.168.0.10
          bridge_ports eth0
          bridge_stp off
          bridge_fd 0

          1. Попробовал разные вариации. Через веб ни одна опция не меняется. Вручную изменил /etc/network/interfaces на Ваш вариант при этом меню стало:
            eth0 Active No Autostart No Ip Address — Subnet mask — Gateway —
            eth1 Active No Autostart No Ip Address — Subnet mask — Gateway —
            vmbr0 Active Yes Autostart No Ip Address — Subnet mask — Gateway —
            Изменить всё равно ничего не даёт. Пойду на форум проксмокса, может там чего подскажут.
            Спасибо!

            1. В общем как то все не то, и как то все не так.

              vmbr0 это винтуальный интерфейс системы, он не имеет прямого отношения к прокмокс, он не может не работать, это просто невозможно.

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

              Надо убедится что изменения сработали, в консоли через ifconfig надо постмотреть что с интерфейсами. У eth0 не должно быть никаких настроек. Должен появится интерфейс vmbr0 с настройками как были у eth0, помимо этих двух интерфейсов ничего больше быть не должно, только если локальная петля lo.

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

              Если виртуалки нормально работают через этот ручной бридж, надо понять почему не конфигурируется через веб морду.

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

              1. Всё таки это был какой-то баг. Админы починили pve-manager, обновился и всё заработало.

  7. А в моем случае придется ехать в ДЦ, так как с «новым» ядром машинка не поднялась после рестарта. Придется отказаться от этой идеи :(

    1. Ехать никуда не надо, надо просто попросить персонал ДЦ выбрать в списке и загрузить ваше старое ядро, оно никуда не делось. Подобные услуги обычно входят в стоимость размещения.

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

      1. Я кажется понял причину. Дело в том что до того как наткнулся на вашу статью, я кучу статей перечитал об установке OpenVZ на debian. И попонятным причинам довести до конца не удалось. В какой то момент ядро обновилось до 3 версии и я это упустил. Нужно вренутся на 2-ю и повторить!

        1. Ничего не мешает загрузится в ваше ядро.

          Версия ядра не могла повлечь за собой такой эффект, если у вас еще что то не накручено, у вас вообще какой дебиан? Обновленный? RAID есть? Ядро руками трогали, меняли в нем что то? init после этого обновляли?

        2. Оказалось завис на инициализации Adaptec.

          Спасибо большое за статью. Все получилось гораздо проще чем даже я ожидал.

          1. По поводу загрузки, есть еще один момент, о котором мне писали на почту. Бывает, что после инсталляции и перезагрузки, новое ядро не загружается, а загружается старое, не pve. Не знаю из за чего так происходит, но происходит это через раз.
            Есть 2 варианта как можно исправить это. Первый, это удалить свое старое ядро, тогда оставшееся pve загрузится по умолчанию, но это плохой вариант.
            Второй вариант, это изменение порядка загрузки в grub.

            1. Смотрим какие есть ядра к загрузке: grep menuentry /boot/grub/grub.cfg и понимаем какое по порядку ядро pve с учетом того, что нумерация идет с ноля, а не единицы.

            У меня это выглядит так:
            menuentry ‘Debian GNU/Linux, с Linux 3.2.0-4-amd64’
            menuentry ‘Debian GNU/Linux, с Linux 3.2.0-4-amd64 (режим восстановления)’
            menuentry ‘Debian GNU/Linux, с Linux 2.6.32-26-pve’
            menuentry ‘Debian GNU/Linux, с Linux 2.6.32-26-pve (режим восстановления)’

            Т.е. у меня нужное ядро с учетом отсчета от ноля будет 2.

            Зная номер ядра, правим меню загрузки:

            nano cat /etc/default/grub

            Меняем параметр ‘GRUB_DEFAULT=2’ ставя нужную цифру, в моем случае 2.

            И обновляем меню загрузки: update-grub

            После этого будет загружаться нужное ядро и старое ядро будет в наличие, на всякий случай.

            P.S. Все выше написанное я внесу в статью, чуть позже.

  8. 3.0 Proxmox не использовал пока, а вот 2 версии ставил и использовал, снэпшот LVM согласен, притормаживает гостевую систему, но на vz контейнерах это не очень заметно. А в целом Proxmox очень хорошая система управления VM, удобная стабильная и простая, я только ее и использую

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.