6.26.1 - не удаляет ВМ
Поиск по тегам
6.26.1 - на одной панели уже 2 дня висит
6.26.1 - вообще перестала обновляться
6.26.1 - после обновления сломалась возможность создания VM
Не создается пользовать VMmanager 6
Вопрос
Не создается пользователь VMmanager, пишет ошибку
Ответ
ISPsystem обновили панель.
И теперь нельзя делать умные email которые работают «как алиас». Как у людей современных модных.
ISPsystem живет же прошлым как 15 лет назад.
И теперь нужно отдельные ящики создавать.
А вот google и yandex — живут в современном мире и умеют делать как нужно.
Обновление
Не создается пользователь VMmanager, пишет ошибку
Ответ
ISPsystem обновили панель.
И теперь нельзя делать умные email которые работают «как алиас». Как у людей современных модных.
ISPsystem живет же прошлым как 15 лет назад.
И теперь нужно отдельные ящики создавать.
А вот google и yandex — живут в современном мире и умеют делать как нужно.
Обновление
Первая авария на VMmanager 6 версии (всем пострадавшим 1 месяц начислено бесплатно)
Хоть они и заявляют о стабильности, но на 2021 год — пока что это не так.
За 2020 было проделано много работы, что-то стало лучше, что-то стало хуже.
Например хуже стало то, что при создании кластера нельзя теперь указать настройки для него, например выставить лимит на канал, в итоге все ВМ создаются без ограничений и потом приходится вручную уже всем настраивать после создания ВМ. А раньше эта функция бралась из создания кластера, просто когда его создашь там указывалось.
А лучше стало наверно то, что больше функционала, все таки Март 2020, Апрель 2020 и Ноябрь 2020 — это небо и земля.
Короче по каким-то причинам часть узлов стала писаться якобы проблемы на узле.
Но узлы работали и ВМ на них работали.
Хотя в панели показывался статус что ВМ отключена и не работает.
Ради теста я перезагрузил 1 узел, он перестал писаться с ошибками. Но зато ВМ-ки на нем перестали работать.
В итоге почти сутки ISPsystem пытались разобраться в проблеме.
И до сих пор пока что проблема не исправлена.
Пишут что утечка ОЗУ, хотя сама панель их показывает что 2 ГБ в запасе.
Вероятно эта проблема случилась после обновления
Версия 6.15.0 VMmanager KVM 6
На VMmanager 5 — были похожие проблемы ранее.
Так вот, короче я перезагрузил 1 узел — и он сдох.
И вот всем кто пострадал на этом узле — 1 месяц бесплатно :)
Вот этим чувакам.
И в публичные отчеты честности для истории.
Дата подачи заявки о проблеме панели.
Но восстановлен узел был только.
Почти 24 часа короче.
Такие вот дела. Извиняюсь хоть это и не косяк хостера.
За 2020 было проделано много работы, что-то стало лучше, что-то стало хуже.
Например хуже стало то, что при создании кластера нельзя теперь указать настройки для него, например выставить лимит на канал, в итоге все ВМ создаются без ограничений и потом приходится вручную уже всем настраивать после создания ВМ. А раньше эта функция бралась из создания кластера, просто когда его создашь там указывалось.
А лучше стало наверно то, что больше функционала, все таки Март 2020, Апрель 2020 и Ноябрь 2020 — это небо и земля.
Короче по каким-то причинам часть узлов стала писаться якобы проблемы на узле.
Но узлы работали и ВМ на них работали.
Хотя в панели показывался статус что ВМ отключена и не работает.
Ради теста я перезагрузил 1 узел, он перестал писаться с ошибками. Но зато ВМ-ки на нем перестали работать.
В итоге почти сутки ISPsystem пытались разобраться в проблеме.
И до сих пор пока что проблема не исправлена.
Пишут что утечка ОЗУ, хотя сама панель их показывает что 2 ГБ в запасе.
Вероятно эта проблема случилась после обновления
Версия 6.15.0 VMmanager KVM 6
На VMmanager 5 — были похожие проблемы ранее.
Так вот, короче я перезагрузил 1 узел — и он сдох.
И вот всем кто пострадал на этом узле — 1 месяц бесплатно :)
Вот этим чувакам.
И в публичные отчеты честности для истории.
Дата подачи заявки о проблеме панели.
2021-02-05 15:39:27
Но восстановлен узел был только.
2021-02-06 19:48:21
Почти 24 часа короче.
Такие вот дела. Извиняюсь хоть это и не косяк хостера.
VM-6 CentOS-7
Вопрос
Не обновляется панель на ОС CentOS-7
Решение
vm updateОбновление VMmanager KVM от [5.136.0] до 5.142.0
Короче, было замечено, что часть нод — не обновилось само.
И застряло на VMmanager KVM 5.136.0
Те, которые Дебиан — гладко обновились до 5.142.0
А вот те, которые как обычно Хваленная Расхваленная CentOS 7
Другие же хостеры как-то обходятся без ребута.
Начал уточнять у админа.
В итоге оказалось, что речь идет именно о серверах, где стоит сама VMmanager KVM — а у нас как вы знаете, т.к. я предусмотрительный человек — под панель выделены Атомы дешевые специально. (про Атомы тут и вот пример наглядно как это меня спасло)
Ребутнуть атом — не проблема.
Мне стало интересно, почему только 2 ГБ ?
Начали проверять разные серверы. Там где под панель был сервер с 16 озу i5-2400 допустим — там раздел tmpfs был 8 ГБ почему-то, а вот на Атоме — именно 2 ГБ.
Подумали сначала что это SWAP.
Но нет, swap если верить «информация о системе» из VMmanager у нас либо 4096, либо другие значения, но никак не 2 ГБ.
Например был сервер, где swap писало 32 ГБ
Но разметка там была
Так что этот вопрос мы так и не поняли, почему вдруг оно забилось, и почему именно на Атоме с 4 озу — такой размер. А на других серверах другой размер. Он как-то сам автоматически наверно делается, в зависимости от сервера? ОС наверно смотрит на мощу сервера и выделяет оптимальное что-то.
Если кто-то знает — в комменты.
update
решение
И застряло на VMmanager KVM 5.136.0
Те, которые Дебиан — гладко обновились до 5.142.0
А вот те, которые как обычно Хваленная Расхваленная CentOS 7
21:01 - Vova1234: Could not create lock at /var/run/yum.pid: [Errno 28] No space left on device
21:02 - Vova1234: места нет
21:02 - Vova1234: tmpfs 1.9G 1.9G 0 100% /run- Место какое-то кончилось.
- Начали копать о чем речь.
Другие же хостеры как-то обходятся без ребута.
Начал уточнять у админа.
В итоге оказалось, что речь идет именно о серверах, где стоит сама VMmanager KVM — а у нас как вы знаете, т.к. я предусмотрительный человек — под панель выделены Атомы дешевые специально. (про Атомы тут и вот пример наглядно как это меня спасло)
Ребутнуть атом — не проблема.
- Итого — после ребута временные файлы вычищались и все потом обновлялось само.
- И узлы которые прикреплены в Атоме уже, сами ноды — так же потом начинали обновляться до последней версии 5.142.0.
Мне стало интересно, почему только 2 ГБ ?
Начали проверять разные серверы. Там где под панель был сервер с 16 озу i5-2400 допустим — там раздел tmpfs был 8 ГБ почему-то, а вот на Атоме — именно 2 ГБ.
Подумали сначала что это SWAP.
Но нет, swap если верить «информация о системе» из VMmanager у нас либо 4096, либо другие значения, но никак не 2 ГБ.
Например был сервер, где swap писало 32 ГБ
Но разметка там была
Filesystem Size Used Avail Use% Mounted on
rootfs 1.8T 728G 999G 43% /
/dev/root 1.8T 728G 999G 43% /
devtmpfs 32G 0 32G 0% /dev
tmpfs 6.3G 444K 6.3G 1% /run
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 19G 0 19G 0% /dev/shm
root@gra:~#Так что этот вопрос мы так и не поняли, почему вдруг оно забилось, и почему именно на Атоме с 4 озу — такой размер. А на других серверах другой размер. Он как-то сам автоматически наверно делается, в зависимости от сервера? ОС наверно смотрит на мощу сервера и выделяет оптимальное что-то.
Если кто-то знает — в комменты.
22:35 — alice2k: 1,5 часа обновляли
22:35 — Vova1234: еще
22:35 — Vova1234: нет
22:35 — Vova1234: 2 осталось
22:35 — alice2k: ну эти уже мелочи
22:35 — alice2k: угу
22:35 — Vova1234: атомы долго обновляются
update
решение
mount -o remount,size=10G /runПросто в честные отчеты
Трудно сказать связано ли это с обновлениями или нет.
Но 30/11/2017
И вот 01/12/2017
Некоторые ноды на CentOS зависают.
Не важно CentOS-6 ли это или CentOS-7
Зависают.
Не перезагружаются. Создается авто-тикет сотруднику ДЦ, что перезагрузка не удалась.
И потом вручную техник похоже что-то чинит и ребутает уже.
Так что вот, еще одно честное — падение.
От 15 до 40 минут простоя.
Причины — не известны.
В логах смотрели.
Сначала показалось что каких-то пакетов не хватало, поэтому зависло.
Потом админ сказал что больше похоже на панику ядра.
Но 30/11/2017
И вот 01/12/2017
Некоторые ноды на CentOS зависают.
Не важно CentOS-6 ли это или CentOS-7
Зависают.
Не перезагружаются. Создается авто-тикет сотруднику ДЦ, что перезагрузка не удалась.
И потом вручную техник похоже что-то чинит и ребутает уже.
Так что вот, еще одно честное — падение.
От 15 до 40 минут простоя.
Причины — не известны.
В логах смотрели.
Сначала показалось что каких-то пакетов не хватало, поэтому зависло.
Потом админ сказал что больше похоже на панику ядра.
[обновление VMmanager KVM 5.124.0] [или все тоже 122 ?]
Очередной топик про неудавшиеся обновления VMmanager KVM
Итак.
Почему-то сервер с панелью VMmanager обновился до 5.124
А вот «узлы» не обновились. Примечательно то, что узел был более старый чем 122 версия. Так что возможно это все тот же косяк 122 обновления.
Написал админу, чтобы он вручную запустил.
И получили
После этого сервер не вышел из ребута.
Только 15 минут «он пытался ребутнутся»
Далее, снова начали копировать файлы виртуалок.
В этот раз оказалось больше. Полностью заполненный сервер.
Спустя 30 минут после кривого обновления VMmanager
Только приступили к копированию, потому что не все так просто.
Потому что в этот раз решили использовать локальный бекап дата-центра, где скорость выше. Чтобы не копировать файлы по интернету. А у дата-центров такие бекапы слишком тупы и доступ туда только с IP сервера. Поэтому админу потребовалось 15 минут чтобы поднять VPN там для начала и пошло копирование.
Как и предположил alice2k — скорость качалова — в 10 раз возросла сразу.
Заметьте — если бы я не продумал систему с «отдельным атомом для панели». В топике ссылка с комментарием «итоговый пост 2017»
То для восстановления слепков — нужно знать все эти параметры, включая тариф, включая название виртуалки.
И когда вручную будем восстанавливать — все должно быть идентичное.
Если бы я не сделал архитектуру с атомом — я бы не смог узнать эти параметры, что на скрине выше :)
Далее короче скопировали все дампы
Переустановили ОС на узле.
Снова добавили узел в атом с панелью VMmanager
Вручную восстановили пользователям их заказы.
Часа 2 дрочили с восстановлением.
В западло еще сервер тормозить стал, потому что там слишком много винды было. А винда как вы знаете устанавливается оч долго.
Короче админ уже уснул к тому времени.
А по факту в итоге целую ночь будет качаться эта винда. Так как особенность винды еще в том, что нужно с нуля установиться ей. А только потом восстановление с бекапа. С линуксом можно например запустить создание VPS и остановить тут же, потом заменить файлы на диске и включить VPS. А с виндой — остановка не работает и нужно дождаться по 40 минут пока это дерьмо установится.
Все таки винда на ноде — дело не благородное. И даже честные доли наверно перестают быть честными при таком загрузе.
Итого простой составил
Не одного косяка или падения за год как мы создаем VPS. Только если не обновление ISPsystem. Может и правда лучше не покупать обновлений и просто работает пусть до самого конца, пока не сгорит? А потом когда сгорит просто уже восстановиться на новом сервере, свежем.
Возможно стоит рассмотреть вариант без узлов и просто тупо оставлять ноды жить на автопилотах и пусть работают без обновлений.
Спасибо тебе ISPsystem за обновление, отлично наши бабки расходуются.
Итак.
Почему-то сервер с панелью VMmanager обновился до 5.124
А вот «узлы» не обновились. Примечательно то, что узел был более старый чем 122 версия. Так что возможно это все тот же косяк 122 обновления.
Написал админу, чтобы он вручную запустил.
И получили
[root@ns3061009 ~]# yum update
Loaded plugins: fastestmirror
Existing lock /var/run/yum.pid: another copy is running as pid 306.
Another app is currently holding the yum lock; waiting for it to exit...
The other application is: yum
Memory : 131 M RSS (1.5 GB VSZ)
Started: Wed Sep 27 20:40:10 2017 - 02:01 ago
State : Sleeping, pid: 306
После этого сервер не вышел из ребута.
Только 15 минут «он пытался ребутнутся»
Далее, снова начали копировать файлы виртуалок.
В этот раз оказалось больше. Полностью заполненный сервер.
Спустя 30 минут после кривого обновления VMmanager
Только приступили к копированию, потому что не все так просто.
Потому что в этот раз решили использовать локальный бекап дата-центра, где скорость выше. Чтобы не копировать файлы по интернету. А у дата-центров такие бекапы слишком тупы и доступ туда только с IP сервера. Поэтому админу потребовалось 15 минут чтобы поднять VPN там для начала и пошло копирование.
Как и предположил alice2k — скорость качалова — в 10 раз возросла сразу.
Заметьте — если бы я не продумал систему с «отдельным атомом для панели». В топике ссылка с комментарием «итоговый пост 2017»
То для восстановления слепков — нужно знать все эти параметры, включая тариф, включая название виртуалки.
И когда вручную будем восстанавливать — все должно быть идентичное.
Если бы я не сделал архитектуру с атомом — я бы не смог узнать эти параметры, что на скрине выше :)
Далее короче скопировали все дампы
Переустановили ОС на узле.
Снова добавили узел в атом с панелью VMmanager
Вручную восстановили пользователям их заказы.
Часа 2 дрочили с восстановлением.
В западло еще сервер тормозить стал, потому что там слишком много винды было. А винда как вы знаете устанавливается оч долго.
Короче админ уже уснул к тому времени.
А по факту в итоге целую ночь будет качаться эта винда. Так как особенность винды еще в том, что нужно с нуля установиться ей. А только потом восстановление с бекапа. С линуксом можно например запустить создание VPS и остановить тут же, потом заменить файлы на диске и включить VPS. А с виндой — остановка не работает и нужно дождаться по 40 минут пока это дерьмо установится.
Все таки винда на ноде — дело не благородное. И даже честные доли наверно перестают быть честными при таком загрузе.
Итого простой составил
- 1-45 ночи
- 12-00 — думаю завтра утром, потом подправлю
Не одного косяка или падения за год как мы создаем VPS. Только если не обновление ISPsystem. Может и правда лучше не покупать обновлений и просто работает пусть до самого конца, пока не сгорит? А потом когда сгорит просто уже восстановиться на новом сервере, свежем.
Возможно стоит рассмотреть вариант без узлов и просто тупо оставлять ноды жить на автопилотах и пусть работают без обновлений.
Спасибо тебе ISPsystem за обновление, отлично наши бабки расходуются.