Информация
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
Контакты
Оплата
Новости
Доставка
Загрузки
Форум
Настройка
    info@proxmox.su
    +7 (495) 320-70-49
    Заказать звонок
    Аспро: ЛайтШоп
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Аспро: ЛайтШоп
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Аспро: ЛайтШоп
    Телефоны
    +7 (495) 320-70-49
    Заказать звонок
    0
    0
    0
    Аспро: ЛайтШоп
    • +7 (495) 320-70-49
      • Назад
      • Телефоны
      • +7 (495) 320-70-49
      • Заказать звонок
    • info@proxmox.su
    • Москва, Бакунинская улица, 69с1
    • Пн-Пт: 09-00 до 18-00
      Сб-Вс: выходной
    • 0 Сравнение
    • 0 Избранное
    • 0 Корзина
    Главная
    Форум
    Proxmox Виртуальная Среда
    Proxmox 4.0 — Ранее запущенный LXC-контейнер не запускается

    Форумы: Proxmox Виртуальная Среда, Proxmox Backup Server, Proxmox Mail Gateway, Proxmox Datacenter Manager
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    Proxmox 4.0 — Ранее запущенный LXC-контейнер не запускается, Proxmox Виртуальная Среда
     
    JAZ013
    Guest
    #1
    0
    18.11.2015 23:14:00
    Столкнулся с проблемой у своих новеньких LXC контейнеров. При загрузке системы всё запускается нормально и работает отлично. Но когда я выключаю контейнер через веб-интерфейс, вне зависимости от того, меняю я что-то или нет, потом не могу его запустить обратно. В выводе задачи вижу:

    Code:  
    lxc-start: lxc_start.c: main: 344 The container failed to start.  
    lxc-start: lxc_start.c: main: 346 To get more details, run the container in foreground mode.  
    lxc-start: lxc_start.c: main: 348 Additional information can be obtained by setting the --logfile and --logpriority options.  
    TASK OK

    Ну, извините, но задача явно НЕ ОК.

    При попытке запустить контейнер в форграунд из ssh сессии получаю такой вывод:

    Code:  
    root@destiny:~# lxc-start --name 101 --foreground  
    RTNETLINK answers: No buffer space available  
    Dump terminated  
    Use of uninitialized value $tag in concatenation (.) or string at /usr/share/perl5/PVE/Network.pm line 176.  
    unable to add vlan  to interface veth101i0  
    lxc-start: conf.c: run_buffer: 342 Script exited with status 25  
    lxc-start: conf.c: lxc_create_network: 3047 failed to create netdev  
    lxc-start: start.c: lxc_spawn: 954 failed to create the network  
    lxc-start: start.c: __lxc_start: 1211 failed to spawn '101'  
    lxc-start: lxc_start.c: main: 344 The container failed to start.  
    lxc-start: lxc_start.c: main: 348 Additional information can be obtained by setting the --logfile and --logpriority options.

    Если перезагрузить хост, всё снова начинает работать отлично. Контейнеры при этом ничего особенного из себя не представляют — просто Debian с каким-то хранилищем и одним сетевым интерфейсом с IPv4, никаких VLAN или прочих сложностей.

    Есть мысли? Буду признателен за любую помощь.
     
     
     
    JAZ013
    Guest
    #2
    0
    01.03.2016 23:42:00
    Это начало доставлять мне всё больше проблем. Теперь я не могу запускать новые контейнеры. Раньше я думал, что проблема решилась обновлением, но оказалось, что перезагрузка просто отодвигала её на какое-то время. А сейчас я вообще не могу запустить контейнеры, которые не стартовали вместе с системой.

    Вывод команды pveversion -v:

    root@destiny:~# pveversion -v  
    proxmox-ve: 4.1-39 (запущено ядро: 4.2.8-1-pve)  
    pve-manager: 4.1-15 (запущенная версия: 4.1-15/8cd55b52)  
    pve-kernel-4.2.6-1-pve: 4.2.6-36  
    pve-kernel-4.2.8-1-pve: 4.2.8-39  
    pve-kernel-4.2.2-1-pve: 4.2.2-16  
    pve-kernel-4.2.3-2-pve: 4.2.3-22  
    lvm2: 2.02.116-pve2  
    corosync-pve: 2.3.5-2  
    libqb0: 1.0-1  
    pve-cluster: 4.0-33  
    qemu-server: 4.0-62  
    pve-firmware: 1.1-7  
    libpve-common-perl: 4.0-49  
    libpve-access-control: 4.0-11  
    libpve-storage-perl: 4.0-42  
    pve-libspice-server1: 0.12.5-2  
    vncterm: 1.2-1  
    pve-qemu-kvm: 2.5-8  
    pve-container: 1.0-46  
    pve-firewall: 2.0-18  
    pve-ha-manager: 1.0-23  
    ksm-control-daemon: 1.2-1  
    glusterfs-client: 3.5.2-2+deb8u1  
    lxc-pve: 1.1.5-7  
    lxcfs: 2.0.0-pve1  
    cgmanager: 0.39-pve1  
    criu: 1.6.0-1  
    zfsutils: 0.6.5-pve7~jessie
     
     
     
    JAZ013
    Guest
    #3
    0
    01.03.2016 23:47:00
    Кстати, я снова попробовал запустить это из командной строки и получил тот же результат. Тогда я удалил сетевое устройство через веб-интерфейс, и контейнер запустился нормально. Без сетевой карты, конечно, толку мало, но это явно указывает на проблему с сетью.
     
     
     
    dietmar
    Guest
    #4
    0
    02.03.2016 06:08:00
    Не мог бы ты заново выложить полученный вывод (думаю, номер строки изменился)? # lxc-start --name 101 --foreground
     
     
     
    JAZ013
    Guest
    #5
    0
    02.03.2016 06:10:00
    Вывод: Код: RTNETLINK отвечает: Нет доступного буфера памяти. Сброс завершён. Не удалось добавить стандартные VLAN-теги к интерфейсу veth400i0. lxc-start: conf.c: run_buffer: 342 Скрипт завершился с кодом 25. lxc-start: conf.c: lxc_create_network: 3084 не удалось создать сетевой интерфейс. lxc-start: start.c: lxc_spawn: 954 не удалось создать сеть. lxc-start: start.c: __lxc_start: 1211 не удалось запустить контейнер '400'. lxc-start: lxc_start.c: main: 344 Контейнер не запустился. lxc-start: lxc_start.c: main: 348 Дополнительную информацию можно получить, указав опции --logfile и --logpriority.
     
     
     
    wbumiller
    Guest
    #6
    0
    02.03.2016 09:08:00
    Команда `pct config 101` показывает что-нибудь необычное? Можешь выложить её вывод? ИЗМЕНЕНИЕ: Ладно, вторая ошибка стала меньше сбивать с толку, но всё равно странная... У тебя пакет iproute2 обновлён до последней версии?
     
     
     
    JAZ013
    Guest
    #7
    0
    02.03.2016 22:54:00
    Вот два примера:  
    Код: root@destiny:~# pct config 101  
    arch: amd64  
    cpulimit: 2  
    cpuunits: 1024  
    description: Ansible Configuration Management%0A  
    hostname: young  
    memory: 1024  
    net0: name=eth0,hwaddr=5E:91:7C:9D:C7:F7,bridge=vmbr0,ip=10.13.1.1/24,gw=10.13.1.254  
    onboot: 1  
    ostype: debian  
    rootfs: LocalContainers:subvol-101-disk-1,size=20G  
    startup: order=99  
    swap: 2048  

    root@destiny:~# pct config 400  
    arch: amd64  
    cpulimit: 1  
    cpuunits: 1024  
    hostname: test  
    memory: 512  
    net0: bridge=vmbr0,hwaddr=66:38:66:64:36:62,ip=dhcp,name=eth0,type=veth  
    ostype: debian  
    rootfs: LocalContainers:subvol-400-disk-1,size=8G  
    swap: 512  

    Все пакеты обновлены. Я только что понял, что это может быть связано с моей связкой Ethernet-интерфейсов. У меня есть двухпортовая сетевая карта Intel gigabit, оба порта которой объединены с помощью LACP. Я, наверное, попробую отключить связку и посмотрю, сохранится ли проблема, чтобы исключить её.
     
     
     
    LasseKongo
    Guest
    #8
    0
    16.04.2016 20:07:00
    Привет, есть ли уже какое-то решение этой проблемы? Я тоже с ней столкнулся, но запускаю не контейнеры, а обычные виртуальные машины. Пробовал с несколькими выключенными ВМ, и ни одна из них не запускается, если не убрать сетевой интерфейс.
     
     
     
    JAZ013
    Guest
    #9
    0
    11.05.2016 03:40:00
    Просто хотел добавить это. После обновления до Proxmox 4.2 вчера у меня, похоже, больше нет этой проблемы. Я почти уверен, что её вызывал связанный Ethernet-интерфейс. В Proxmox 4.2 появился ядро 4.4.8-1-pve, которое, по всей видимости, это исправило. Пока что не могу быть уверен на все 100%, но будем считать, что вероятность успеха 95%. Для стресс-теста я даже добавил 6 сетевых интерфейсов в контейнер, все с DHCP. Раньше это точно вызывало сбой, а контейнер запустился просто отлично. Также провёл все остальные тесты, которые обычно «убивали» контейнер — многократный запуск и остановка, интенсивный сетевой трафик и прочее. Ничто уже не может его сломать. Настоящее испытание — оставить его работать несколько дней или недель, ведь именно тогда проблема обычно начинает проявляться по-настоящему. Но пока... отличный результат!?
     
     
     
    JAZ013
    Guest
    #10
    0
    30.05.2016 06:29:00
    Всё по-прежнему отлично спустя больше двух недель.
     
     
     
    ufoshi
    Guest
    #11
    0
    24.08.2016 13:09:00
    Привет! У меня сейчас такая же проблема со всем кластером. У меня версия 4.1. Есть ли какое-то решение?
     
     
     
    JAZ013
    Guest
    #12
    0
    25.08.2016 04:08:00
    Да. Обновляйтесь до версии 4.2, как я написал выше.
     
     
     
    ufoshi
    Guest
    #13
    0
    25.08.2016 10:33:00
    Возможно, это решение для 4.1, потому что обновление — не лучший вариант для меня.
     
     
     
    JAZ013
    Guest
    #14
    0
    26.08.2016 01:32:00
    Это не такое уж и крупное обновление. Так что нельзя просто сделать apt-get dist-upgrade и перезагрузить систему??? Похоже, у тебя проблема не только в этом.
     
     
     
    ufoshi
    Guest
    #15
    0
    30.08.2016 10:39:00
    Это решение для меня: не обновлять, а откатить одну версию пакета: apt-get install pve-qemu-kvm=2.4-21. Вот тема: https://forum.proxmox.com/threads/backup-and-migration-imposible-proxmox-4.25819/
     
     
     
    Страницы: 1
    Читают тему
    +7 (495) 320-70-49
    info@proxmox.su

    Конфиденциальность Оферта
    © 2026 Proxmox.su
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры