> Что вам запрещает считать логически завершенным и самостоятельным - группу процессов, выполняющих
> определенные задачи?Например, то что в принципе они и их работа могут зависеть от ОС, либ в ней, конкретики ее настройки. А тут оно вместе с ОС и кочует - заведомо рабочее, без отвалов башки.
> И причем здесь вообще свойства "железной машины"? :D
При том что удобно админить логически законченную самодостаточную сущность - ОС и сервис(ы) в ней. Так что при перемещениях оно не поломается. VMы и продвинутые формы контейнеров как раз это и обеспечивают. Но с контейнерами уже ряд оговорок. Например, что если набор модулей разный, а проги зависели от неких модулей ядра? В VM данной проблемы не стоит как класса. А чем дальше от VM с OS и ближе к chroot, тем больше грабель такого плана. Которые надо учитывать и которые дополнительный риск.
> Абсолютно никто в реальном продакшене железки не эмулирует,
Так никому и не уперлось что-то "эмулировать". Уперлось абстрагировать и развязать сущности друг от друга, чтобы стало возможным простое перемещение.
> за редкими специализированными исключениями.
Скорее уж реальные PCI-девайсы пробрасывают, etc. По соображениям скорости работы всего этого. Именно софтварная эмуляция да и просто сколь-нибудь масштабная софтварная обработка - медленно все-таки.
> Кстати, запуск legacy-софта - как раз таки разумный пример использования
> виртуализации. Для пропиерастов, конечно.
Это разумный вариант, но любителей настолько хардкорно кактусом давиться в природе не очень много.
>> просто неоткуда.
> Ох уже эти "теоретики"...
"Теоретики", btw, виртуализацию и контейнеры уже годков наверное ~7 юзают в том или ином виде.
>> Нормальный и логичный подход.
> Чем "ненормален и нелогичен" - подход с разделением ресурсов обычными средствами ОС?
Тем что оно не будет самодостаточным - при мигрировании на другой сервер более вероятен отвал башки, в зависимости от конфигурации ОС и тамошнего юзермода. А вот это никому не надо. Ну то-есть, в принципе контейнеры - есть, используются, имеют право на жизнь. Но у мигрируемой целиком виртуалки в этом плане есть определенный плюс - она все свое притащит с собой. Меньше допущений о конфигурации хоста.
> Как вы сами упомянули - многозадачные ОС появились давным давно,
> ресурсы делить тоже не вчера научились. Может, кто-то просто не вкурсе?
Они научились, но несколько не в том виде котором было на самом деле надо. Т.е. полная глухая изоляция всех от всех - по дефолту, полисовка ресурсов - достаточно дуракоустойчивая, с учетом нужд хостеров и подобных, etc. Миграция - сразу всего окружения со всеми прибамбасами. Чтобы юзер например хостинга мог переехать на иную железку и у него ничего не отпало не дай боже. Иначе он обозлится и покажет фак такому хостеру.
> И правильно делали. Именно в этом направлении идет развитие того, что включают
> в Linux (см., к примеру в сторону CRIU). А OpenVZ - дорога в никуда.
OpenVZ во многом базируется на LXC. Который JFYI в майнлайн включен, только расширяет и дополняет его. Основным недостатком является по сути то что оно не в майнлайне. Основным достоинством за это являются приличные управляторы и набор фич удобный для хостеров. Кстати с не удивлюсь если они будут работать через CRIU как раз для живой миграции.
Но с юзермодом все несколько сложнее. А что если мы хотим мигрировать машину, а на том хосте - тадам! - нет нужного модуля ядра? От которого вот эта машина что-то хотела? В полновесной виртуализации такая проблема просто не стоит: ядро и модули тоже свои притащут. А от хоста требуется только совсем низкоуровневый арбитраж ресурсов. По каким-то таким причинам виртуализаторы расцветают бурным цветом. Ну то-есть на самом деле всем надо именно вот это. Они формируют спрос. Ну и предложение появляется.
> ???!
Да есть тут некоторые.
>> вот вы в этом случае таки будете мудохаться с заковыриванием бутлоадера на место.
> Не буду. Просто потому что сервер загрузится дальше. Не с этого диска - так с другого.
Опять какие-то рояли в кустах, да еще с целым оркестром допущений в комплекте. А у виртуалок один рояль только - снапшот должен быть. Если он есть - можно отмотать. А если снапшот на ФС - как минимум ОС должна быть жива настолько чтобы загрузиться и осилить его отмотать назад. У полного виртуализатора таких допущений нет - можно вообще все снести в ноль и потом вернуть в вид как было. Просто потому что снапшотинг целиком блочного девайса - более полная и низкоуровневая штука. И достаточно простая чтобы это отпедалил виртуализатор, без помощи операционки в гуесте.
> Понимаете, да? Задачу можно решить разными способами.
Да, а еще я понимаю что есть допустим хостер. Он хочет клиента перекинуть на соседнюю железку, т.к. с старой например проблемы намечаются. Дрюкаться с выяснением какой там у задач клмента был файл исполняемого, где конфиги, что там ему надо и прочая - совершенно левый гемор, который никому нафиг не упал. Ни хостерам, ни клиентам. Да и в ынтырпрайзе с кучей машин и сервисов - тоже. Правда просто? Ну вот опенвза это в первом приближении может.
>> Вы не поняли. Штуки типа puppet не заменяют а дополняют.
> Не заменяют и не дополняют - просто это пример разумного управления конфигурациями.
Администрежка виртуалок через подобные средства совершенно ничему не противоречит.
> А не бардака с "скопировать и запустить".
Ну да, лично вы у нас тут знаете только один правильный вариант как надо и как лучше, во всех 100% случаев. А всех несогласных с вами наверное надо бы расстрелять. Если вы такой деревянный и не поняли - обычно никто не копирует виртуалки самолично, ручками. И никакого особого бардака не возникает. В ынтырпрайзятине обычно это выглядит так: виртуализатору сообщают "мы тут хотим машину такую-то". Он сам ее лепит. Все, конец истории. Опенвза сие тоже до некоторой степени умеет.
>> Но на самолете - явно проще и быстрее. Вот то что предлагаете вы - чесать пешком.
> Отнюдь. Просто подобное решение нельзя получить привычным многим локалхост-админам
> копипастом из какого-нибудь гoвноблога.
Понимаете ли, ни ынтырпрайзников ни хостеров не прельщает дрюкаться с фигурным выпиливанием лобзиком. У них вообще-то конвейер. И они не могут позволить себе роскошь фигурно лобзиком два дня пилять. Надо чтобы захотели -> бабах -> готово. А вот свой апломб неплохо бы строить иногда. А то тоже мне, пальцы веером, кожа шифером. А сам поди админ какого-нибудь зачуханного локалхоста или спасибо если пары серверов Рога & Копыта, инк.
> Иными словами - здесь нет универсальных решений.
А вот хостеры и энтерпрайзы хотят более-менее generic управление такими вещами и готовы за это платить звонкой монетой. Теперь я думаю вы начнете догадываться почему мир выглядит таким какой он есть, а не таким каким бы лично вам хотелось его видеть.
> Их нет и в вашем случае: в зависимости от характера сервиса(ов) виртуалки,
> размера данных, нагрузки - вас поджидают разного рода засады...
Понимаете, указанные требования в общем то предъявляю не лично я а вообще индустрия в целом. Хостеры, ынтырпрайзы. И софт резонно движется в ту сторону, ибо спрос рождает предложение. И реалии таковы что например хостеру надо возможность сдвинуть клиента целиком, со всем хламом, без отвалов башки на иную железку, например. Да и ынтырпрайзы что-то такое в конечном итоге хотят. Вот потому и процветают упомянутые дизайны виртуализаторов и контейнеров. Это так сложно осознать?
> Удачи - у вас еще столько впереди!...
Угу, поучите меня виртуализаторы использовать. В ынтырпрайз из-за парты? Ну так, судя по количеству апломба и распальцов с вашей стороны.
>> например с полным снапшотом блочного девайса, включая служебные области.
> Вы про MBR? :)
Про все. MBR, bootloader, kernel и критичное для взлета ОС окружение. В случае полного виртуализатора он вообще никаких допущений не делает и откатывает снапшоты сам, не прибегая к услугам guest OS которая может быть вытерта хоть вообще в ноль.
> Выше было поставлено под вопрос - насколько это может оказаться полезным.
Выше кто-то дешевенько отмазался и фигурно повилял задом на неудобную тему, предположив не то что рояль, а целый оркестр в кустах.
>> Образом RAM VM и прочая.
> Это верно, конечно. Но конкретно в вашем примере (быстро откатить здорово
> поломанное) - ничего такого особо и не нужно.
Зато это более точное восстановление в прошлое состояние. Ну или точный трансфер состояния VM на другую железяку, если это же самое применяется при миграции.
> С умом - вполне можно.
Дык. Это работает. И достаточно хорошо. А вот апломб немного строить надо, да.
>> Абстрагировав вычислительные ресурсы от претендентов на таковые.
> Moar абстрахций! А многозадачность, процессы, потоки - все это зачем по-вашему?
Так исторически сложилось. Но упомянутым выше субъектам данные концепции в сыром виде неудобны для взаимодействия (чего ради хостер должен париться вопросом какие у меня процессы или где и какие файлы им нужны, например?). Удобнее чтобы юнитом взаимодействия было виртуальное окружение со всеми потрохами. Ну, VE опенвзы или VM виртуализатра. Правда сюрприз? :)
> Прямые руки и знания - вот что в реальности гарантируют декларированное вами.
Немеряный апломб на форуме - еще не гарантия пряморукости индивида.
