Опубликован релиз Proxmox Virtual Environment 8.0, специализированного Linux-дистрибутива на базе Debian GNU/Linux, нацеленного на развертывание и обслуживание виртуальных серверов с использованием LXC и KVM, и способного выступить в роли замены таких продуктов, как VMware vSphere, Microsoft Hyper-V и Citrix Hypervisor. Размер установочного iso-образа 1.1 ГБ...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=59334
Отличные новости!
раз в 3 года проходить обновление гипервизера так себе идея
А как часто нужно?
Не флейма ради, но интересен best practice
бест - это чтоб оно тихо сдохло от старости вместе с виртуалками внутри, давно забытыми зачем они были и для чего.Остальное, к сожалению - один сплошной бесконечный геморрой.
И вот вроде бы даже ведро обновлять милостиво разрешено кпатчами (ну, понятно, не де6иллианоидам, но в принципе-то) - а все равно регулярно происходит какая-нибудь хрень.
хнык... мы только что закончили полугодичный траходром с обновлениями чортовой вмвари... правильно - чтобы снова его начать потому что полно уже накопилось проблем а то и вообще явных уязвимостей.(и это, как обычно, в режиме то не трогай в дневное время, это не трогай вообще, а вон о том даже думать забудь)
Обновляю ноду за нодой. ВМ перед этим: 1) незначительные выключаю 2) важные перегоняю в онлайн без даунтайма.
Нет никаких проблем незаметно обновлять кластер.
Да... вот это проделали работы... самое важное это украинский мовь?
повестка такая.
ее сейчас всюду суют
Ещё тёмная тема :)
Справдливости ради, эта бесполезная доработка не упоминается ни в пресс-релизе, ни в анонсе на форуме. Найти ее можно только в глубине их роадмапов на вики. Выпячивают это только на опеннете.
Когда появится failover migration с сохранением состояния как это сделано в серьёзных решениях типа hyper-v ?
То есть при вырубинии ноды по питанию все ВМки с нее переедут на другую с сохранением состояния?
Не верю.
В кластере Hyper-V на обычном оборудовании виртуальные машины бывшие не в shutdown ( при настройках по умолчанию) станут загружаться с нуля.Т.е. будет перехагркзка.
Но есть оборудование с зеркалированием состояния CPU.
( У VMWare ESX есть такой же режим без спец. оборудования. )
Там куча ограничений и очень мало кому оно надо.Кому надо, тот покупает это за деньги.
Проксмокс он не про деньги.
> Проксмокс он не про деньги.а пацаны-то и не знали...
Догоняйте лидеров. По деньгам - догоните, решим
> В кластере Hyper-V на обычном оборудовании виртуальные машины бывшие не в
> shutdown ( при настройках по умолчанию) станут загружаться с нуля.
> Т.е. будет перехагркзка.
> Но есть оборудование с зеркалированием состояния CPU.
> ( У VMWare ESX есть такой же режим без спец. оборудования.тоже нет. вмварьский HA (не путать с live migration для которого обе стороны должны быть live) - это тоже перезагрузка ресетом с точки зрения vm.
https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsp...
наслаждайся.
А ее FT (отдельная от HA история за отдельные деньги) - это уже не "переедут". Это у тебя ДВЕ копии вм ПОСТОЯННО на двух разных хостах крутятся, жрут ресурсы как две равные вм и так далее. Т.е. оно уже изначально перееханое и дублирует каждое изменение памяти (с соответствующей нагрузочкой на сеть да и на сам хост тоже)
В общем для очень одаренных васянов схема, ниасиливших нормально FT силами приложения.
Ту таки да!
Но у нас enter price же - поэтому + SRM.
Это на in-prem, в облках - своя атмосфЭра(С) ...
Уличили: писал по памяти, терминологию "от VMWare" запомнить не соизволил.Содержимое наших мессаджей от этого поменялось мало -)
P.S. Кластеры или т.п. от Microsoft, Oracle, Starwind HA - освоил -)
> Содержимое наших мессаджей от этого поменялось мало -)Читать как: и в вашем, и моём сообщении написано одно и тоже, но чуть по-разному
в Hyper-v это реализовано так - вм крутится одновременно на всех годах (ресурсы естественно отобраны заранее) и синхронизируется в рилтайме. если дёрнуть основную году по питанию то юзеры даже не заметят что что-то произошло (будет микро лаг) и все открытые программы , даже положение курсора на винтовых машинах будет сохранено. quemu так не умеет.
Вот именно так - в VMWare ESX.
Надеюсь они починили убивание виртуалок оом-киллером.
Как они это сделают? Телепортацией оперативной памяти из другой вселенной. Короче оом на месте не переживай.
> Как они это сделают? Телепортацией оперативной памяти из другой вселенной. Короче оом
> на месте не переживай.Да я не за себя.
У меня XenServer 😏
Эээ... а что, оно не умеет вместо прибивания ВМки остановить её, выгрузить из ОЗУ, перегнать на хост со свободной памятью, там развернуть и запустить?
"и пусть весь мир подождет!"
Который внутри? Он ничего не заметит.
> Который внутри? Он ничего не заметит.ну да. У него ж ни таймеров, ни открытых соединений, обычный майнер в вакууме, постоит и дальше поедет считать ненужные цифирки.
Извини, твой локалхост опять выдает тебя с головой.
А на практике я не могу двигать виртуалки внутри вмварьского кластера. Не потому, конечно, что что-то там "выгрузится" Б-же упаси, оно ТАК не делает, но пару пингов - при неудачном раскладе вполне теряет. А это развалы всяких модных современных кластеров со сплитбрейнами или потерей мастера, повисшие сессии к несовременным (с переоткрытием из-за таймаутов и лавинообразным ростом нагрузки как следствие) и так далее.
И эта! За пивком! Сбегать за пивком!
Ну или хотя бы отправить заказ пивка курьеру. Хоть так, черт их держи!
Не, если не успеет подpoчить мне между делом, то на это я не согласен!
Это буржуйский софт, он за пивом не бегает, он кофе варит.
> Эээ... а что, оно не умеет вместо прибивания ВМки остановить её, выгрузить
> из ОЗУ, перегнать на хост со свободной памятью, там развернуть и
> запустить?Зачем останавливать.
Оно умеет живую миграцию, даже вместе с дисками если они не на шаред сторадже, но в случае оом приходит быстрый и беспощадный оом-киллер.
> Надеюсь они починили убивание виртуалок оом-киллером.надеюсь теперь он убивает еще и сторадж.
(в общем-то - типичная история васянских ceph)
>> Надеюсь они починили убивание виртуалок оом-киллером.
> надеюсь теперь он убивает еще и сторадж.О! А этот кейс я не тестил.
> (в общем-то - типичная история васянских ceph)
У них какой-то кастомный цеф?
>> (в общем-то - типичная история васянских ceph)
> У них какой-то кастомный цеф?у них он самонастраивающийся по каким-то их странным лекалам - весьма далеким от рекомендуемых самим ceph.
Но прибить mds оом-киллером - совершенно норм и для самодельных кластеров в принципе. Главная же прелесть - что никто на свете не знает как такую ситуацию детектировать и чинить.
Про странные лекала и рекомендации самого ceph это конечно сильно.
Только и в той и другой команде разработчиков участвуют одни и те же люди.
а эти люди - они сейчас с вами в одной комнате?Потому что то что получалось при установке по проксиным инструкциям - было ну такое себе... то есть это даже устаревшими версиями тех инструкций не объяснить.
(
Х. с ESX , на врямя ...
)Я не понял: OOM нельзя отключить штатно отключить?
В Докере он свой?
Короче: мне надо отключить оба.
Если нельзя штатно, то в исходных кодах ядра легко найти, что закоментировать?
Спасибо!
Отправишь киллера на пенсию, система будет падать в паник. Все же сейчас пишут приложения как ? "А захвачу-ка я себе памяти сразу 16Тб, ядро разберётся". Тут киллер работает "санитаром леса".P.S. Как же он меня бесит этот oom-killer. Он ука всегда убивает самые важные приложения ... Веб сервер, ну или базу данных ... Сам себя бы прибил :-(
> Отправишь киллера на пенсию, система будет падать в паник.А SWAP ?
Или если он включен, то и OOM killer не срабатывает?
Так как отключить?
Будет ли запрашивать 16 терабайт проверю на практике> самые нужные
Вот именно: вредная идея в принципе этот самый killer
> Вот именно: вредная идея в принципе этот самый killerА это не идея. Это просто пережиток UNIX-ахитектуры, её самая мрачная часть: системный вызов fork
Даже не буду вдаваться в детали, для чего это было изначально, но сейчас это одна из замен IPC в сочетании с UNIX pipes. Материнский процесс порождает дочерние ради вопросов многозадачности и обмена данными. Проблема в том, что вся память материнского процесса копируется в дочерние. И там по идее применяется COW для оперативки, чтобы не занимать слишком много места. Предварительно объявляется pipe для обмена данными.
То есть если материнский процесс запустился и запросил 16Гб оперативной памяти, то _потенциально_ по столько же захватят детки. В этой ситуации, когда весь юзерспейс так работает нет никакой возможности предсказать сколько реально приложению нужно оперативной памяти. Вот ядро и не пытается. Ядро всегда утвердительно отвечает на запросы выдачи RAM, а когда вся память кончится то OOM Killer без спросу прибьёт тот процесс, который плохо лежит.
Вы не единственный человек, который посчитал, что это плохая практика. Например, разработчики операционной системы VMS посчитали, что fork не безопасен (бездумное копирование данных, потенциально с ошибками) и порождает проблемы. Поэтому было принято решение:
1. Не делать системный вызов fork
2. Отказать приложению, если оперативной памяти вместе с виртуальной не достаточно. Приложение получит исключение (обработает или покрашится), а вновь запускаемые приложения вообще не возможно запустить в состоянии OOM.
3. Для решения задач IPC предложить IPC
4. Для решения задач многопоточности предложить API для потоков/тредов, а не плодить клоны процессов
5. Для запуска дочерних процессов предложить отдельное API, которое их запускает, а не копирует с родителя.Ну то есть pthreads-то есть, но он появился сильно позже (90-е) чем fork (70-е), и вы можете писать приложение не форкаясь, но вот только если вы посмотрите на UNIX-юзерспейс, вы осознаете, что Init, включая его молодежные и популярные версии на самом деле считают все процессы в ОС форком первого процесса, процесса init. Значит чтобы это победить нужно еще и предоставить некоторую объектную модель работы с процессами, которая живет отдельно, а не иерархично копируется.
В итоге у противников архитектуры, которая предполагает наличие fork получилось так, что создание процесса стало трудоёмкой по времени задачей, а наличие богатого IPC стало обязательным в юзерспейсе. Зато потоки наоборот стали простыми и дешевыми. Но да, операционная система построенная на этих принципах не имеет OOM и не нуждается в нем.
Сама по себе оригинальная VMS мертва, но её архитектуру наследуют VMS-подобные, если можно так сказать, ОС, одной из которых является Windows NT (не та которые 9к). При разработке WSL1 Windows обзавелся очередной реализацией fork в рамках обновленных компонентов POSIX-совместимости. Они даже писали публикации с просьбами избавиться от него в UNIX-like, потому что он привносит больше проблем, чем что-то там решает. Вроде этой: https://www.microsoft.com/en-us/research/uploads/prod/2019/0...
А потом плюнули и пихнули WSL2 в виртуалку. Пусть сами играют в свои fork-exec, OOM Killer и прочие пережитки прошлого, под управлением гипервизора с лимитом на ресурсы RAM.
OpenVMS я и сам недавно здесь ( или рядом) упоминал.Но меня заподозрили в использование перфокарт -)
(
Хотя: да, не мною пробитые, штук пятьдесят у меня где-то лежат.На них план лекций, кстати, удобно писать. ( видел в деле)
)
> Но да, операционная система построенная на этих принципах не имеет OOM
> и не нуждается в нем.
> Сама по себе оригинальная VMS мертва, но её архитектуру наследуют VMS-подобные, если
> можно так сказать, ОС, одной из которых является Windows NTНу... OpenVMS вполне себе жива.
А в Винде легко можно получить ООМ.
> Винде легко можно получить ООМШтатно - наверное.
Я просто спец. комбайн Automate применял.Но это не "дико непосредственный" OOM killer , а сверх. "навороченное" и надёжное ПО.
С _предсказуемо_ надёжным результатом.
>> Вот именно: вредная идея в принципе этот самый killer
> А это не идея. Это просто пережиток UNIX-ахитектуры, её самая мрачная часть: системный вызов forkВнимание вопрос ! А почему у самого близкого к UNIX-архитектуре FreeBSD этой гадости нет ?
>>> Вот именно: вредная идея в принципе этот самый killer
>> А это не идея. Это просто пережиток UNIX-ахитектуры, её самая мрачная часть: системный вызов fork
> Внимание вопрос ! А почему у самого близкого к UNIX-архитектуре FreeBSD этой
> гадости нет ?Чего нет?
https://man.freebsd.org/fork
https://klarasystems.com/articles/exploring-swap-on-freebsd/
Нормально так ... я про oom-killer, он про fork.
Понятно что fork дублирует полностью процесс, так не надо сначала памяти хапать, а потом форкаться.
> Нормально так ... я про oom-killer, он про fork.Вторая ссылка это статья описывающая работу swap в FreeBSD, там же написано про oom-killer и как от него защититься. (гораздо проще чем это сделано в Linux).
> А SWAP ?
> Или если он включен, то и OOM killer не срабатывает?Срабатывает, но позже, когда своп кончится.
> Так как отключить?
Зачем? С ним веселее =)
> Вот именно: вредная идея в принципе этот самый killer
В принципе нет, для десктопа вещь полезная.
> С ним ( OOM Killer) веселее =)Только, если не-desktop, то как в анекдоте:
-- А есть ли у вас что-нибудь повеселее?
-- Недавно завезли весёленький ситчик. Обхохочетесь
(
Пойду сдаваться ИИ -) Может, он знает -)
)
>> С ним ( OOM Killer) веселее =)
> Только, если не-desktop, то как в анекдоте:
> -- А есть ли у вас что-нибудь повеселее?
> -- Недавно завезли весёленький ситчик. Обхохочетесь
> (
> Пойду сдаваться ИИ -) Может, он знает -)
> )Хотя... он и на сервере полезен, для того чтобы зайти на него по ssh и посмотреть почему оом-киллер приходил. =)
Раз так 200 или триста...
> Раз так 200 или триста...А без оом-киллера при оом у тебя сервер встанет раком так что ты даже в консоль не зайдёшь - придётся reset нажимать.
> без оом-киллера при оом у тебя сервер встанет раком так что ты даже в консоль не зайдёшь - придётся reset нажиматьОхотно верю...
Это "звёзд. " т.е. зв. коллапс какой-то... Ж-(
> А SWAP ?А вы почитайте
https://access.redhat.com/solutions/103833SWAP в Linux - это чудовище. Его реализация даже в современном ядре такова, что затюнить его под свою задачу - вопрос в большей степени астрологический, нежели технический. И виноват во всем именно страничный кэш.
Если вы укажете слишком высокую цифру у вас в swap будут попадать активные буферы процессов, а если слишком маленькие, то почти ничего.Проблема в том, что формула совершенно идиотская, потому что не учитывает то, что реально происходит в юзерспейсе, какие там процессы и прочее. Это магическое число.
Отдельно нужно сказать про страничный кэш, который оно будет активно отбирать. Вы же знаете да, что ядро Linux имеет поддержку единственной верной файловой системы ext4, а остальные там сильно сбоку. Например, если RHEL предоставляет по умолчанию XFS, поэтому делает форк ядра в том числе, чтобы страничный кэш учитывал специфику XFS. А если у вас ZFS, то у вас вообще будет существовать как бы 2 разных страничных кэша. А теперь попробуйте угадать резервирование (в гуманитарном смысле) RAM под этот зоопарк на сервере виртуализации. Если у вас 1ТБ RAM или что-то близкое к этому, то заложить минимум 80 ГБ было бы не плохо, но нужно понимать сколько локального диска. С учетом того как там всё форкается налево и направо было бы неплохо угадать и этот потенциальный перерасход.
> Так как отключить?
Проставить значение vm.oom-kill = 0 в sysctl или поиграться с vm.overcommit_memory
Но если вы так сделаете, то у в условии нехватки памяти будет падать не одна виртуалка, а целый хост (привет VMware, она так любит делать). В реальности вам нужно производить скоринг процессов, чтобы контролировать, что вам будут ронять с большей вероятностью, а что с меньшей. Но сделать так чтобы не падало ничего не выйдет.Поймите, Linux постоянно производит оверкоммитмент ресурсов RAM, хотите вы этого или нет. Максимум что вы можете сделать:
1. Создать шаблоны ресурсов виртуальных машин
2. Размещать виртуальные машины одного типа на одной группе серверов, второго типа на второй, итд. Ради предсказуемости нагрузки и объемов.
3. Рассчитывать ресурсы железа так, чтобы не срабатывал OOM Killer.
4. Выделить приоритеты в /proc для важных процессовЕсли вы хотите автоматизацию таких вещей избавьтесь от Linux, ну или хотя бы избавьтесь от KVM, перейдите на Xen (Citrix Hypervisor), где ваши виртуальные машины не считаются за обычные процессы ОС, хотя и там вам от него не избавиться. И опять, даже в случае с Xen всё в конечном итоге зависит от сборки дистрибутива/юзерспейса и как там присваиваются приоритеты и распределяются ресурсы.
Если же вы хотите, чтобы у вас виртуалки свапились, а не падали, когда вы перерасходуете RAM, то вам нужен Hyper-V. Но не могу понять зачем это может потребоваться. Засвапилась у вас виртуалка или упала - всё одно. Оно больше не работает нормально.
Спасибо за информацию!
Буду ставить экспрерименты.К сожалению, гипервизор я не контролирую. Хотя, пардон: есть выбор их двух вариантов...
Буду думать...
P.S.
> Если же вы хотите, чтобы у вас виртуалки свапились, а не падали, когда вы перерасходуете RAM, то вам нужен Hyper-V.
Да - подтверждаю.
Единственное - свопинг будет внутри VM. За одним редким исключением.Hyper-V - это, кстати, решение.
И решение на раньше продавали.> Но не могу понять зачем это может потребоваться. Засвапилась у вас виртуалка или упала - всё одно. Оно больше не работает нормально.
Не факт: иногда в своп навсегда уходит всякое непонятно что.
А реально нужные страницы - остаются в RAM.
Но, в общем случае, да Вы правы.
Впрочем, в случае динамической (?) памяти, есть шансы, что она перераспределиться среди высокоприоритетных VM засчёт низкоприлритетных.
P.S.А собственно OOM killer хочу "на пробу" отключить "внутри VM".
Ибо вижу сработки, как раз, там.
score для киллера можно настраивать и передавать в параметрах любому приложению при запуске
>Для двухфакторной аутентификации блокировка включается на час, а для TOTP - бессрочно.А какая разница?
OTP это просто одноразовый пароль. А второй фактор это про факт владения устройством ( брелоком, мобилой), которое генерит токен. Т.е. вводится логин, пароль, пин от токена и значение токена, пин на тот случай если брелок вы потеряли, а логин и пароль приклеены стикером на мониторе.
А разве OTP является одной из разновидностей двухфакторной аутентификации?
>> Предоставлена возможность прозрачного обновления Proxmox VE 7.4 до выпуска 8.0.Экхем... А в более ранних версиях неужто с 000 переставлять? :)
>>> Предоставлена возможность прозрачного обновления Proxmox VE 7.4 до выпуска 8.0.
> Экхем... А в более ранних версиях неужто с 000 переставлять? :)Ну видимо было менее прозрачным, а сейчас более :)
> Ну видимо было менее прозрачным, а сейчас более :)...я всё понял, спасибо :).
Интересно как проходит миграция Цефа
как п-ц.В смысле, иногда мигрировавшее восстановлению не подлежит. (так и запишем - умигрировало нахрен)
Специально для них они сделали репозитарии цеф.
Доступный... Тадам! Доступный по подписке!
С подсказками, казино, стриптизом и девочками.
там какая-то бнопня в новости - промтом переводили, что-ли? В непонятном отдельном репозитарии ровно та же версия что и в самом дистрибутиве.По крайней мере если верить переводу. Проверять разумеется не буду.
Основная проблема не в репо, проблема будет в интеграции всего этого в автоустановку/апгрейдилку проксы. Не уверен что они реально могут и хотят поддерживать две несовместимые версии да еще и обеспечивая путь апгрейда отличный от "грохните нахрен весь кластер и создайте заново".
Учитывая что и раньше-то у них получалось так себе...
Чтением док прокса и деланьем как там написано.Там просто. Очень.
> Чтением док прокса и деланьем как там написано.
> Там просто. Очень.А вон там пох говорит что совсем не просто.
Кому верить?
>> Чтением док прокса и деланьем как там написано.
>> Там просто. Очень.
> А вон там пох говорит что совсем не просто.не, сделать "кактамнаписано" - совсем просто (не читал, но осуждаю - потому что еще лет пять назад читал). Совсем непросто потом восстановить данные или уже даже хрен с ними - хотя бы как-то запустить кластер обратно когда что-то пойдет не так, если у тебя чисто случайно не нашлось в шкафу запасного.
Гугли ceph war story (где-то в недрах реддита) - оно на самом деле не про ceph, он не виноват. Оно про дикое сочетание совсем странных настроек и специфических глюков, помноженное на полную неуправляемость этого монстра в случаях когда что-то идет не так.
Есть, кто Proxmox до сих пор юзает? Мне кажется, сейчас Докер гораздо удобней стал, чем Proxmox. А для более требовательных - k8s.
google:// какая разница между контейнером и виртуальной машиной
щас найдет какой-нибудь бредовый выcep чатгопоты на эту тему и так ничему полезному и не научится. Впрочем,это, конечно же, хорошо.
Софта, для которого этп разница существенна всё меньше и меньше. До нуля не скукожится, конечно, контейнеры надо в чём-то запускать, но тренд именно в ту сторону.
Вендокапец всё ближе и ближе !
вот бы 1с с экселем в докере запустить...
> вот бы 1с с экселем в докере запустить...Немного подожди, майки как раз работают над этим.
> Добавлена возможность блокировки учётной записи после слишком большого числа неверных попыток прохождения двухфакторной аутентификации или ввода некорректных одноразовых паролей (TOTP). Блокировка производится для защиты в ситуациях, когда атакующие смогли узнать пароль пользователя и пытаются методом перебора подобрать проверочный код на второй стадии аутентификации. Для двухфакторной аутентификации блокировка включается на час, а для TOTP - бессрочно. Для разблокировки можно использовать код восстановления доступа или отправить запрос администратору.лол, меня бы сегодня заблокировало - случайно скопировал не ту "длинную рандомную строку", а именно пароль юзера вместо приватного ключа TOTP, и раз десять вводил пароль и не понимал, почему не пускает, даже сверял время на сервере и на локалхосте, пока не заметил, что в редакторе выделена не та строка.
оказывается, в приватных ключах TOTP нет никаких чексумм, а это просто рандомная строка, поэтому oathtool сгенерирует вам шесть цифр из вообще чего угодно.а в целом TOTP - шикарная функция, всеми конечностями за.
Кто уже обновился с 7.4 до 8.0 вопросе замене свойства конфигурации в /etc/lvm/lvm.conf да/нет что ответили?
"Если вас спросят об изменениях в /etc/lvm/lvm.conf, подумайте, внесли ли вы какие-либо пользовательские изменения в этот файл. Если нет, нажмите Y, затем ENTER."https://www.derekseaman.com/2023/06/how-to-proxmox-7-4-to-8-...
Нет, я туда руками не лазил, но то что он хочет заменить все строчки на # это нормально?
Не могу ничего посоветовать. Сделайте бэкап виртуалок в режиме Stop, а потом спокойно экспериментируйте. В крайнем случае установите проксмокс с нуля, там дел то на 10 минут.
Хорошо так и сделаю. Спасибо за ответ.
"И пусть весь мир подождёт"