Разработчики проекта Gentoo объявили о формировании официальных загрузочных образов в формате QCOW2, позволяющих получить полностью работающее системное окружение, готовое к запуску в виртуальных машинах. Образы обновляются раз в неделю, что позволяет использовать их для оценки текущего состояния дистрибутива. Ранее проектом распространялись только установочные образы и Live-сборка для загрузки с USB-устройств...Подробнее: https://www.opennet.me/opennews/art.shtml?num=62766
всё это может означать только одно. Но что ?
У них нет более насущных проблем, чтоб руки занять? (Сомнительно)
Ну вот, пришёл Вовочка и всё х обложил :)
Там просто до власти добрались люди (и, конекретно, один поляк), которые хернёй занимаеются, хотя полезное тоже делали. Генту всё больше в сторону бинарных сборок смотрит и всё сильнее теряет себя.
Funtoo не взлетел с контейнеризацией, может здесь прокатит.
Funtoo вообще не взлетел, а теперь совсем на землю упал.
Он там у власти уже много лет, есичо.
И как успехи "есичо"(С)?
Довел ли он Gentoo до самых высоких высот или уронил ниже 1% от 1% от 1% ?
Что вырастить ботнет станет намного проще
> Первый вариант предназначен для быстрого ознакомления и тестирования дистрибутива на локальной системе,А что kvm уже разучился грузиться с iso?
А что, ты не понимаешь разницу между загрузкой с iso и полноценной системой на диске в qcow2?
Никто не знает почему они так долго не делали облачный образ?
Это не облачный, облачный как правило контейнер.
нет такого.Под облачным обычно подразумевают образ для EC2-инстанса, в простонародье - для виртуалки / VM. Serverless контейнерами в облаках пользуется малая часть пользователей это экзотика с которой никто не хочет связываться кроме каких-нибудь full-stack разработчиков, которым нужно на коленке кровь из носа поднять в облаке их шедевр. А для контейнеров, разумнее managed K8s (Kubernetes) поднять или Docker Compose на VM-ках, в итоге дешевле выйдет, чем использовать serverless конейнеры.
* EC2 инстанс - терминология чисто AWS-овская, в других облаках VM-ки по-другому называют, конечно же, все страются своё название придумать для обычной VM. Более того, само понятие VM в облаках не подразумевает исключительно виртуталки, это может быть и bare metal инстанс в облаке (зависит от конфигурации), просто все по привычке называют их VM-ками.
PS: образ QCOW2 можно конвертнуть в образ для облачной VM, но ИМХО, проще собрать свой, например, через Packer. Даже образ Gentoo легко собирается.
Такими ответами ты скорее отпугнёшь людей от знаний.Облачный образ означает доработки обычного образа напильником для запуска в облачных оркестраторах (OpenStack, OpenNebula и другие). Из наиболее частых доработок: сервис cloud-init, ядро заменено на урезанное без драйверов и диск размечен одним последним разделом, чтобы легко расширялся скриптами.
> Такими ответами ты скорее отпугнёшь людей от знаний.Я ответил лишь с целью развеить мифы про облачные контейнеры у некоторых, а тебя не туда понесло.
> OpenStack, OpenNebula
Это self-hosted облака, не совсем корректное сравнение. Когда говорят про облака в первую очередь подразумевают облака на платформе у вендоров (облачных провайдеров), таких как: ЯО, AWS, Azure, Huawei Cloud, Cloud.ru (бывший SberCloud, они, кстати, технологии Huawei Cloud используют с примесью OpenStack), Digital Ocean, Google Cloud, Baidu Cloud и др.
> Облачный образ означает доработки обычного образа напильником для запуска в облачных оркестраторах (OpenStack, OpenNebula и другие).
Облачный образ в первую очередь означает AMI-шку.
*AMI - тоже терминология чисто AWS-овская, это образ для VM в простанародье, не только Linux, но и Windows и других UNIX-like систем.Возьмём, к примеру, VK Cloud (он же бывший MCS (Mail.ru Cloud Solutions)), они используют OpenStack во всю. Ну давай допили напильником образ для их обачной платформы. Они настолько урезали функционал выбора образов для их OpenStack, что свой ты туда не загрузишь. А вот в AWS ты собирешь AMI-шку какую угодно. Так, что это всегда зависит от конкретного облачного провайдера.
> Из наиболее частых доработок: сервис cloud-init, ядро заменено на урезанное без драйверов и диск размечен одним последним разделом, чтобы легко расширялся скриптами.звучит, как мартышкин труд, но в self-hosted облаках возможно, чем-то это оправдывают
Обычно, если нам нужно при разворачивании VM инстанса выполнить скрипт, он просто прописывается user-data в tf ресурсе (пример для VK Cloud):
```hcl
resource "vkcs_compute_instance" "compute" {
...
user_data = ivkcs_agent_init.init.agent[<HOST_NUMBER>]
}
```
Дальше триггерится он через сloud-init или чем-то другим, инженера волновать не должно. Это не играет роли.
> Облачный образ в первую очередь означает AMI-шку.Технически нет. Исторически - возможно. Кстати, сами же провайдеры облаков предоставляют образы для скачивания. Их можно изучить внутри и понять, чем они отличаются.
Юзаю qemu уже 7 лет, а применение формату qcow пока не нашел.
Шутишь наверное. Этот формат поддерживает снапшоты.
он про то что даже lvm снапшоты поддерживает + еще много всего ...
а без него lvm снапшоты нельзя делать? )
А как вы делаете savevm, консистентный снапшоту lvm? (-;
> Шутишь наверное. Этот формат поддерживает снапшоты.и кому вот хоть какая-нибудь польза от тех снапшотов, которые поддерживает _формат_ (в отличие от тех которые поддерживает система виртуализации, но тем, в общем, все равно, какой формат у самих файликов - если ты не на голой куеме конечно ездишь)
Снапшоты qcow2 сохраняют состояние ОЗУ. Можно сохранить и развернуть виртуалку в запущенном состоянии.
ни разу. состояние озу сохраняет тебе среда виртуализации.
Снапшоты qcow2 сохраняют - qcow2. Кстати, лоча при этом файлик. Единственная их ценность - что получившийся файл (один файл!) вместе со всеми снапшотами внутри можно передать кому-то еще, гарантированно ничего не просыпав при этом на пол. "но зачем?!"А все остальное за тебя делает виртуализационный бутерброд поверх (что уж у тебя там - virsh или что более продвинутое). А ему в общем все равно, и совершенно необязательно именно в этом формате.
> ни разу. состояние озу сохраняет тебе среда виртуализации.Харошь дезинформировать. Использую голый qemu без вечно отстающих по фичам и неудобных в использовании прослоек, savevm сохраняет мне дамп памяти и устройств именно в qcow2.
(Лучше расскажи о том, что лично видел, а не на картинках в интернете: что сейчас кроме вечно поломанного демосовского фидогейта есть для чтения эх?)
что, прямо в образ диска гадит дампом памяти и хрен его знает чем еще?
А если дисков два - в какой она нагадит?И что при этом qemu-img info про такой диск скажет?
> Использую голый qemu без вечно отстающих по фичам и неудобных в использовании прослоек
у тех хотя бы - документация есть. А где твой savevm документирован? Впрочем, видимо там же где вся консоль куемы - нигде.
Но в целом отличный повод этой несуразицей не пользоваться, если кому других мало.
> что сейчас кроме вечно поломанного демосовского фидогейта есть для чтения эх?
ничего. Какие тебе еще эхи, сдохло там все давно. ddt-то работает. Сети толком нет уже.
> что, прямо в образ диска гадит дампом памяти и хрен его знает чем еще?Ага, прикинь!
> И что при этом qemu-img info про такой диск скажет?
$ qemu-img info --output=json main.qcow2
{
"snapshots": [
{
"vm-clock-nsec": 851999657,
"name": "20230910-1409",
"date-sec": 1694344148,
"date-nsec": 583578000,
"vm-clock-sec": 1677646,
"id": "1",
"vm-state-size": 1989370961
},
...vm-state-size видишь? Вот это оно и есть. Плюс-минус совпадает с размером памяти после команды balloon у каждого снимка.
> А где твой savevm документирован? Впрочем, видимо там же где вся консоль куемы - нигде.
Я, конечно, понимаю, что выдача гугляндексов давно скатилась, но даже сейчас легко можно найти это самое «нигде»: https://qemu-project.gitlab.io/qemu/system/monitor.html
> А если дисков два - в какой она нагадит?
Ты не поверишь, но это тоже написано во всё той же документации:
> Normally this device is the first virtual hard drive.
Поиск ссылки на это предложение оставляю в качестве упражнения читателю.
> Какие тебе еще эхи, сдохло там все давно
Что не мешало мне читать свежие страдания про перенесённый из ZoL код, а сейчас через этот ddt только полтора сообщения и прорывается, а остальных не видно.
> а сейчас через этот ddt только полтора сообщения и прорывается, а
> остальных не видно....и это именно ответы на ответы, а начала не видать.
>> а сейчас через этот ddt только полтора сообщения и прорывается, а
>> остальных не видно.
> ...и это именно ответы на ответы, а начала не видать.ну так это типичное фидо. Вопрос сдох вместе с хабом через который его отправляли в сторону ddt.
Где-то одностороняя проводимость, а где-то уже просто нет линка, ибо не с кем.
> Я, конечно, понимаю, что выдача гугляндексов давно скатиласьесли документацию надо искать гугляндексом - это значит что ее - нет. Есть заметки на манжетах.
Но в целом этот п-ц как раз говорит о том что не надо этим пользоваться. Додуматься в диск сохранять несвязанные с ним данные вм - это надо было быть очень альтернативно-одаренными.> Что не мешало мне читать свежие страдания про перенесённый из ZoL код,
лет десять назад? Ну так тогда остатки еще работали. Проблема не в ddt. Сети нет. Она никому не нужна. Что ты там надеешься найти - остатки mo.talk 1997го года? "Одни ушли на войну, другие сбежали от нее".
> если документацию надо искать гугляндексом - это значит что ее - нет.Что значит «надо»? Тебе никто не мешает читать /usr/share/doc/qemu*/system/monitor.html вслух с выражением, там всё то же самое.
Или когда твои современники бегают по форумам да ютубам с воплем «сейчас документация не та, что раньше, а вот во времена коммодоре-64 огого!», они, что, имеют в виду не полноту документации, а фетиш на подшитые физические бумажки, что ли?
>> Что не мешало мне читать свежие страдания про перенесённый из ZoL код,
> лет десять назад?Ну почему же, про сборку, поломанную из-за cpu mitigations, тред был в ковидные ещё времена.
> Тебе никто не мешает читать /usr/share/doc/qemu*/system/monitor.html вслух с выражением,
> там всё то же самое.ну я глянул - нет там нихрена. В том что есть нет деталей, только сама команда. (отдельно прекрасно что ты ее не найдешь если не знаешь где искать заранее - снапшоты описаны в qemu-img и это не те снапшоты, и в параметрах запуска (да йопаралон - ОПЯТЬ не те - причем - другие!)
Наверное, как обычно, обновили хтмлку позавчера, надо было поставить еще недорелиженную пре-альфа версию а не это вот немодное.Как вы этим пользуетесь без какого-нибудь либвирта хотя бы - не знаю.
>> лет десять назад?
> Ну почему же, про сборку, поломанную из-за cpu mitigations, тред был в ковидные ещё
> времена.с тех пор удаленку отменили и рабов выгнали на работу. Поэтому остатки и так давно разваливашейся сети стали беспризорными и через некоторое время совсем померли. "есть кто живой? - ой ... ой ... ой".
Удивительно еще, что сам ddt удалось восстановить.
Там все было плохо еще в том 19м - меня как-то занесло почитать их технические эхи, там адъ и п-цъ уже тогда был (то есть собственно он всегда был, но в 99м это не выглядело настолько убого).
> Как вы этим пользуетесь без какого-нибудь либвирта хотя бы - не знаю.После либвирта снапшоты qemu кажутся мелочью.
send-key xxx KEY_LEFTALT KEY_SYSRQ KEY_F — ну очень просто, удобно и запоминаемо. Автодополнения, конечно же, нет (привет как минимум любителям Стабильных и Надёжных редхатообразных, как в современном virsh — не знаю).
destroy прибивает запущенное вместо того, чтобы удалять всё. Каждый раз, пытаясь жёстко погасить машину, проходишь мимо этой опции в документации, думая, что этодругое, и долго пытаешься понять, где же этот чёртов force-вариант shutdown.
Машины эти поделки любят создавать то с прибитым vnc-портом, то с автоматическим, после чего в следующий ребут половина виртуалок не поднимается с internal error: Failed to reserve port 5904.
Кстати, про vnc, virt-manager об удалённые хостовозки то даёт посмотреть в экран виртуалке, то обламывается на ровном месте, хотя ничего при этом не меняется. Приходится из ps подсматривать номера и пробрасывать по ssh порты для vncviewer.
Едва появляется необходимость сделать что-то минимально нетривиальное, как мы тут же проваливаемся в бездну xml-портянок, в которых Рабинович напевает всё те же флаги qemu. Документацию при этом проще читать от последнего, а не от либвирта, а потом угадывать, что же могли странно переименовать. Проще оказывается выкинуть такого посредника.
«Как вы этим пользуетесь - не знаю»
А что там внутри образов, чисто 3rd stage с cloud-init?
Кто-нибудь понимает, зачем?
я тоже не понимаю, как это под вендой запустить-то?(возможно они имели в виду что теперь со своей вендочки они сразу мышекликом разворачивают свое перекомпиляние всего навсегда где-то в оооооблачке, не нагружая свой проц ничем кроме прона, но им, видимо, забыли рассказать, что в оооблачках нужны другие форматы образов)
Ты уже или из Венды валазь, или иди на профильные форумы.
Образы с классической Gentoo, т.е. с OpenRC ?
На страничке загрузок нашёл только no-multilib | systemd образ.
> на системах с EFI (BIOS не поддерживается).- И ты тоже, Брут!..
(c)
>> на системах с EFI (BIOS не поддерживается).
> - И ты тоже, Брут!..хм, а у кого паспорт правильного цвета - гляньте, может в azure уже целиком отменили compatible тип вмок, и вся крысиная возня этим и вызвана?
Проблема тут в том что железо уже перестают с BIOS'осом производить и поэтому от производителей софта мало что зависит приходится переходить на UEFI.
> Проблема тут в том что железо уже перестают с BIOS'осом производить и
> поэтому от производителей софта мало что зависит приходится переходить на UEFI.Казалось бы - причем бы тут железо когда речь об образе диска в формате, пригодном только для виртуалок (причем строго одного, наиболее сомнительно встречающегося в дикой природе типа)
Может я что-то пропустил. Когда это гентрушники начали отходить от компиляний? Слышал большие пакеты они уже не компиляют.
Всё компилируется. Но, если захочется, сможете дополнительно подключить бинарный репозиторий.
> Может я что-то пропустил. Когда это гентрушники начали отходить от компиляний? Слышал
> большие пакеты они уже не компиляют.Ты почаще причаливал бы к звездным базам чтоль…