Представлен релиз гипервизора Cloud Hypervisor 48.0, созданного на основе компонентов проекта Rust-VMM, развиваемого при участии Intel, Alibaba, Amazon, Google и Red Hat. Rust-VMM написан на языке Rust и позволяет создавать специфичные для определённых задач гипервизоры. Cloud Hypervisor является одним из таких гипервизоров, который предоставляет высокоуровневый монитор виртуальных машин (VMM), работающий поверх KVM и оптимизированный для решения задач, свойственных для облачных систем. Код проекта доступен под лицензиями Apache 2.0 и BSD...Подробнее: https://www.opennet.me/opennews/art.shtml?num=63881
почти уже революция, вот-вот программистов выкинут на морозхочется запрыгнуть на мопед и петь песни
> Cloud Hypervisor is an open source Virtual Machine Monitorвот-вот почти написали "гипервизор", но оказался монитор.
*"переписали", оно на раст
Работать, технарь! Солнце ещё высоко!
Вот это правильно: отказ от эмуляции, низкое потребление памяти, отзывчивость... О чем можно мечтать и все благодаря самому правильному языку. В копилку однозначно.
ничего что это прослойка к прокладке для запуска kvm ?
Ничего что это совсем не про это? Это замена device model qemu, эмулятор отдельных устройств вроде дисков/сетевых интерфейсов/прочего, для чего вместе с kvm и нужно обычно использовать qemu
ничего что "это" называет себя "vmm"? И что-то там еще блеет про отсутствие виртуализации устройств. Т.е. и тут за него все сделает - kvm. (ну или hyperv) Полноценным vmm при этом разумеется тоже не является.
Хрустики такие врунишки...
> И что-то там еще блеет про отсутствие виртуализации устройств. Т.е. и тут за него все сделает - kvm. (ну или hyperv)не, ну тут перебор. У них "ставка делается на паравиртуализацию", kvm таким не занимается
в случае kvm видимо vhost там будет или что. В общем, очередная прослойка.
> Т.е. и тут за него все сделает - kvm. (ну или hyperv)С каких пор virtio находится в ядре? Это всегда была юзерспейс часть, qemu. А тут - Rust-VMM, qemu отсутствует.
VMM/hypervisor называется и ядерная часть, и юзерспейс, потому что они не работают по отдельности, за любым io виртуальная машина передаёт управление kvm/xen/hyperv, а они при необходимости передают управление юзерспейс драйверу что уже общается с физическим диском например - qemu/rust-vmm/crosvm
Ну вот смотри, ядреные виртио дрова допустим лежат вот тут:
/usr/src/linux # cat ./.config |grep VIRTIO
# CONFIG_BT_VIRTIO is not set
CONFIG_NET_9P_VIRTIO=y
CONFIG_VIRTIO_BLK=y
CONFIG_SCSI_VIRTIO=y
CONFIG_VIRTIO_NET=y
CONFIG_VIRTIO_CONSOLE=y
# CONFIG_HW_RANDOM_VIRTIO is not set
# CONFIG_I2C_VIRTIO is not set
# CONFIG_GPIO_VIRTIO is not set
# CONFIG_DRM_VIRTIO_GPU is not set
# CONFIG_SND_VIRTIO is not set
CONFIG_VIRTIO_ANCHOR=y
CONFIG_VIRTIO=y
CONFIG_VIRTIO_PCI_LIB=y
CONFIG_VIRTIO_PCI_LIB_LEGACY=y
CONFIG_VIRTIO_MENU=y
CONFIG_VIRTIO_PCI=y
CONFIG_VIRTIO_PCI_ADMIN_LEGACY=y
CONFIG_VIRTIO_PCI_LEGACY=y
# CONFIG_VIRTIO_BALLOON is not set
CONFIG_VIRTIO_INPUT=y
CONFIG_VIRTIO_MMIO=m
CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES=y
# CONFIG_VIRTIO_DEBUG is not set
# CONFIG_VIRTIO_RTC is not set
# CONFIG_RPMSG_VIRTIO is not set
CONFIG_CRYPTO_DEV_VIRTIO=m
А где по твоему лежит
>юзерспейс драйвер, что уже общается с физическим дискомИ кто этому узерспейс драйверу навыдавал прав для обращения к физическим дискам?
> Ну вот смотри, ядреные виртио дрова допустим лежат вот тут:Это не та часть дров, это для того чтобы твоё ядро могло работать в виртуалке с virtio драйверами, а не для того чтобы твоё ядро могло эмулировать физические устройства. Можешь их убрать, и гостевые системы будут работать как и раньше.
> И кто этому узерспейс драйверу навыдавал прав для обращения к физическим дискам?
Ты выдал, однако я возможно тут не очень понятно выразился, потому что обычно используют не физические диски, а qcow2 дисковые образы например
> Ты выдал, однако я возможно тут не очень понятно выразился, потому что
> обычно используют не физические диски, а qcow2 дисковые образы напримерГостевая система <-> виртуальный диск <-> ядерный virtio-blk драйвер <-> kvm гипервизор <-> ядро хоста <-> юзерспейс хоста <-> qemuвский/rust-vmm virtio-blk драйвер <-> disk.qcow2 файл
это клиент. Эти драйвера работают внутри паравиртуалки.
Со стороны гипервизора - то что подкладывает под этот "scsi" файлик вместо диска и перекладывает пакетики из виртуальной сетевухи в настоящую - все гораздо запутанней, там есть и ядерная и userland части.Вряд ли опеннетовский кексперт сможет показать тебе на примерах хрустокода откуда готовилось нападение.
>> Т.е. и тут за него все сделает - kvm. (ну или hyperv)
> С каких пор virtio находится в ядре? Это всегда была юзерспейс часть,
> qemu. А тут - Rust-VMM, qemu отсутствует.Есть VMM 1-го и 2-го типа, вот QEMU - 2-го
> Есть VMM 1-го и 2-го типа, вот QEMU - 2-гоДа тут формулировки просто дырявые, QEMU одновременно и первый и второй тип, потому что kvm/xen (гипервизоры первого типа) без QEMU не работают, QEMU в этой связке является частью гипервизора первого типа, но также QEMU умеет работать самостоятельно в роли эмулятора, в этом случае он гипервизор второго типа. Эти формулировки имели больше смысла в 70х годах, когда гипервизоры были монолитные, и когда это разделение собственно и было придумано.
Согласно этим формулировкам даже для KVM есть споры по его типу, потому что в отличии от Xen/HyperV, KVM работает поверх Linux ядра, в то время как в Xen/HyperV у тебя ядро системы запущено уже внутри гипервизора.У Xen нормально это сформулировано, та часть которая эмулирует устройства (не клиент этого эмулятора в лице virtio драйверов гостевой системы, а именно то что запускается на хост системе/в stubdomain) там зовётся device model. При этом Qemu в роли device model всегда используется тот что описывает i386 железо, даже если Xen у тебя запущен на aarch64 сервере.
Qemu - одновременно и гипервизор для виртуализации, и device model + лаунчер kvm/xen для паравиртуализации
Rust-VMM - device model, cloud hypervisor - лаунчер виртуалок под kvm/xen/hyperv/другие бекенды, вместе они заменяют Qemu в лице гипервизора первого типа... Если не учитывать что cloud-hypervisor ещё и qemu запускать умеет, что даёт ему возможность работать как второй тип)
> потому что kvm/xen (гипервизоры первого типа) без QEMU не работаютда ну?!
А это вот - не в курсе что такое? https://github.com/apritzel/kvmtool ?
Лет ему - примерно как самому kvm (логично, надо ж было как-то отлаживать ядро, а не разбираться в еще и куемной блоатвари)
Обратить внимание - размер всей конструкции совершенно крошечный. Что в общем логичненько, когда ты ничего эмулироватьи не собирался. И внятно отражает "сложность" хрустикового мегапрожекта примерно того же самого уровня.
https://git.kernel.org/pub/scm/linux/kernel/git/will/kvmtool.../Причем все модели девайсов - в каталогaх virtio и hw, они реально простые. Зачем растишки это стали переделывать - непонятно от слова совсем.
Еще вот эта поделка, и тоже на растишке, как и сабж https://github.com/firecracker-microvm/firecracker
так это ж те же самые (среди участников - амазон, снова)вероятно, код из закорючек (причем - незамысловатенький) проще каждый раз заново переписывать, чем исправлять.
> Зачем растишки это стали переделывать - непонятно от слова совсем.Реализацию того же virtio-blk/virtio-queue сравни, в kvmtool она слишком простая, и оно не может например ожидать чтения сразу большого числа блоков, у неё нет очередей полноценных
А потому производительность (пропускная способность) у неё значительно ниже, чем у той реализации что есть в rust-vmm, оно банально ждёт ответ от хостсистемы на каждый запрос, вместо того чтобы слать их несколько одновременно.
Более того, многие компоненты rust-vmm верифицированы на прохождение спецификаций (Symbolic model checking, пакет kani генерирует из Rust кода задания для SMT решателей, получаем подвид формальной верификации), в то время как для kvmtool даже тестов и fuzzing полноценного нет, такое в прод пускать страшновато.
При желании, к kvmtool можно прикрутить io_uring. И это будет куда эффективнее всех нагромождений растишки.
> При желании, к kvmtool можно прикрутить io_uring. И это будет куда эффективнее
> всех нагромождений растишки.Ну вот когда прикрутят - тогда и поговорим
Сейчас же оно просто хуже реализовано.
> а не разбираться в еще и куемной блоатвариПока вспомнил. Неразрешимая задача (https://en.wikipedia.org/wiki/Undecidable_problem)
https://github.com/libvirt/libvirt/commit/7e667664d28f90bf69...
> А это вот - не в курсе что такое? https://github.com/apritzel/kvmtool ?Оно точно так же как и qemu реализует device model и лаунчер, оно всё ещё не делает KVM полностью самостоятельным гипервизором, он всё ещё требует qemu/rust-vmm/kvmtool в юзерспейсе.
> И внятно отражает "сложность" хрустикового мегапрожекта примерно того же самого уровня.
В отличии от kvmtool, rust-vmm (как и qemu) умеет значительно больше бекендов (xen, hyperv, и ещё несколько штук), значительно больше устройств, значительно больше ОС (за счёт поддержки других бекендов и устройств), является модульным, что позволяет его использовать в других программах как библиотеку, и вообще все устройства в нём реализованы с рассчётом на значительно большую нагрузку, в kvmtool даже очередей для блочных устройств нормальных нет
>kvm/xen (гипервизоры первого типа) без QEMU не работают,Работают они с другими VMM (как минимум, KVM) - на QEMU свет клином не сошелся. Кроме того, QEMU поддерживает (ну, в некотором роде) WHP- как и VmWare Workstation и VBox. Это при наличии собственного VMM.
QEMU всегда работает в юзерспейсе поверх хостовой ОС - а потому он - 2-го типа.
> Работают они с другими VMM (как минимум, KVM) - на QEMU свет
> клином не сошелся. Кроме того, QEMU поддерживает (ну, в некотором роде)Я понимаю, имел в виду что они не полностью самостоятельные, нужен qemu/rust-vmm/kvmtool/другое
> QEMU всегда работает в юзерспейсе поверх хостовой ОС - а потому он
> - 2-го типа.Как эмулятор - да. Однако qemu это не только эмулятор и гипервизор, но ещё и device model, где он работает как компонент type-1 гипервизора (xen/kvm)
>Это замена device model qemu, эмулятор отдельных устройствFlashback из фильма матрица, когда Нео вытаскивают из капсулы "с полки". Не забывайте в какой субстанции находятся твои ОС.
> все благодаря самому правильному языкуВы сударь или тролль или просто не очень далёкий человек...
А как проверять будут?
Неужели нейронку попросят)?Вообще метания туда-сюда забавны.
>устройства fw_cfg (Firmware Configuration), позволяющего передавать из хост-окружения в гостевую систему данные и настройки, такие как конфигурация загрузки виртуальной машины, информация о раскладке памяти в системе и таблицы ACPI.В UEFI и так все это есть.
"Cloud Hypervisor is an open source Virtual Machine Monitor (VMM) that runs on top of the KVM hypervisor and the Microsoft Hypervisor (MSHV)."Растишки даже с тем, что это они такое пытаются накорябать, разобраться не могут. То ли гипервизор, то ли VMM.
Вы не понимаете, автопилот это не автопилот.
> Растишки даже с тем, что это они такое пытаются накорябать, разобраться не
> могут. То ли гипервизор, то ли VMM.могут, но тогда не получится гордо заявлять что на хрусте нахрустели что-то значимое.
Поскольку по факту тут ни того ни другого. Прослоечка к продкладочкам.
Не пойму только, чем им не угодил ЫЫ - до полного bullshit bingo оставалось ведь совсем чуточку.
Видимо, пирожник никогда не ест своих пирожков.
А как проект развиваться будет, если код от ИИ использовать нельзя? В соседней новости выяснилось, что на Rust только так пишут.
Это многоходовка. Завтра МежБизМаш начнёт продавать своего ассистента, который обучен только на кошерном коде. Ну MS начнёт.... или внезапно галочку "обучено на кошерном коде" начнут продавать все, кто перечислен в соответствующей строчке changelog :)
А кто у них рав, точно ли признанный иерусалимскими правильными пацанами?
> А кто у них рав, точно ли признанный иерусалимскими правильными пацанами?Там не теологи, там религиоведы... наука. Загуглите "Эдвин Блэк IBM".
Всё кошерно!
Как будто кто-то их будет спрашивать можно им засылать написанный с помощью AI код или нет. Зато теперь любая накоммитившая обиженка может сказать что весь свой код нагенерила, и удачи им выпиливать из истории коммиты, на которых уже куча других изменений базируется.
Не может. Потому за намеренный саботаж можно получить предписание суда компенсировать убытки. И по таким делам приставы могут и дом отобрать, и любимого хомяка. А то и вовсе можно сесть, если ущерба насчитают достаточно. А его насчитают: десять сеньоров с зарплатой $220/год разгребали бардак шесть месяцев, потрудитесь внести. В общем, не советую.
Всё классно в проекте, Rust, лицензии на выбор, Apache 2.0 и BSD!
Но запрещать код сгенерированный AI, это убьёт проект!
Только отсталые станут запрещать ИИ. Как будто снова в пещере оказался.
> Запрет AI также обусловлен желанием снизить нагрузку на сопровождающих,А сопровождающие не в курсе, что ИИ можно использовать и для разбора кода тоже? Опять каких-то дидов ретроградов понабрали.
> избавив их от разбора неосмысленных исправлений, созданных с использованием AI.
Непонятно, чем осмысленные и неосмысленные изменения ИИ принципиально отличаются от человеческих.
На деле понятно, что ИИ всё равно будет, просто про это не будут говорить.
Википедию лицензионная чистота сгенерированного текста устраивает, а их нет?> Запрет AI также обусловлен желанием снизить нагрузку на сопровождающих, избавив их от разбора неосмысленных исправлений, созданных с использованием AI
Теперь нагрузка будет в попытках отличить сгенерированный код от человеческого, особенно, когда контрибьюторы догадаются использовать промпт «пиши чуть неаккуратно, как писал бы живой человек».
Луддиты забавные
Всего лишь повторяется история с художниками. Те тоже пытались организовать ИИ-контент отдельно,но платформы на котором это все размещалось их послали.Программист - хобби и лишь некоторые будут этим зарабатывать.
> Луддиты забавныеПочему ты сидишь здесь, а не с ллмкой обсуждаешь эти новости?
>сокращение возможных векторов для атак
>ставка делается на паравиртуализацию
>позволяющего передавать из хост-окружения в гостевую систему данные и настройки
>для организации совместного доступа нескольких гостевых систем к общей области памяти/0
Инструкция, как сделать дырявый софт на расте
Ну да, важно же от кого а не какой код
Судя по уровню твоего понимания новости, ЛЛМ действительно кодит сильно лучше тебя.
LLM вообще-то кодит получше 99% джунлв. По факту - все зависит от того насколько ты умеешь правильно декомпозировпть и формулировать задачи...
А по факту - LLM позволяет практически полностью избавится от тупыx кодеров, которые научились гoвнoкoдить за полгода и хотят за это 200-300к руб. в месяц, на руки.