Комментарии 39
Вы упоминаете про «SMP» и «NUMA». Вообще, весь список какой-то странный, весь набит разнородными терминами.
Термин «SMP» должен упоминаться вместе с «AsMP» (асимметричная многопроцессороность) и «MPP» (массово-параллельная процессорность). Эти три варианта описывают взаимодействие процессоров. При этом организация памяти у них м.б. любой из нижеперечисленных.
Термин «SMP» должен упоминаться вместе с «UMA» (однородный доступ к памяти) и «NonMA» (полное отсутствие прямого доступа к памяти другоих процессоров); до кучи хорошо бы упомянуть «RDMA» (доступ к чужой памяти есть, не не прямой, а только копированием через DMA-контроллер). Это — три или четыре варианта организации памяти, но это не всё.
Помимо общего доступа к памяти, есть ещё синхронизация кэшей — которая может были или не быть. Точнее, есть три варианта:
Вообще, надо помнить, что у процессоров всегда есть своя собственная внутренняя память, недоступная никому больше. Как минимум, это регистры — которые по своей сути тоже память, но быстрая и с особыми режимами доступа. Поэтому утверждать, что „SMP — это обязательно UMA“ нельзя, ибо видов памяти в современных компьютеров много (порядка чуть ли не дюжины), и они работают в разных режимах (UMA, NUMA или NonMA).
С паравиртуализацией вообще получается очень интересно. Персональные компьютеры — это чуть ли не самое уродливое порождение эволюционного процесса, когда IT-бизнесмены старательно мешали провести полный рефакторинг. Сама преемственность от 16-битных систем реального режима с накоплением (и необходимостью поддержки) всех неудачных решений, сделанных чуть ли не за полвека стремительной эволюции — породила чудовищного кадавра (в качестве примера неудачного решения я могу назвать сегментную адресацию).
Но сейчас я хочу поговорить не об архитектуре процессора, а о программной архитектуре — которую, как ни странно, навязывает аппаратура.
Для начала — задача для IT-студентов:
Так вот, ублюдочность архитектуры перснального компьютера — в т.ч. в том, что все операционки (кроме DOS и других операционок той поры) вынуждены тащить с собой все драйверы устройств, с которыми собираются работать. Это потому, что они предполагают работу на „голом железе“. А „голое железо“ — это стандарт именно персональных компьютеров.
А вот если бы компьютер снабжался операционкой, зашитой в ПЗУ — его эволюция шла бы совершенно другими путями. Отличий было бы множество — начиная с того, что производители операционок не стали бы следовать рекомендации Билла Гейтса „надо как можно скорее выкинуть на рынок недоделанное говно и захватить рынок, убив конкурентов, которые долго и тщательно делают качественный продукт“. Хотя бы потому, что операционку в ПЗУ заменить сложно, ежедневно выпускать по дюжине обновлений (в т.ч. критические обновления безопасности) тут не получится.
Кроме того, получили бы распространение бездисковые машины. Потому что не было бы необходимости ставить локальный жёсткий диск для загрузки операционки. И администрирование компьютерного парка в корпорациях стало бы намного легче.
А ещё — при наличии операционки в ПЗУ, виртуализация появилась бы намного раньше. Просто потому, что при желании запустить на этом компьютере альтернативную операционку — её портировали бы не для рабты на голом железе, а с использованием уже имеющейся в ПЗУ операционке. При таком развитии компьютеров — никакой классической неполной виртуализации не могло возникнуть в принципе, ибо не было бы операционок, нуждающихся в ней. Была бы полная виртуализация для операционок с других платформ (если там была уродливая архитектура); и паравиртуализация.
Термин «SMP» должен упоминаться вместе с «AsMP» (асимметричная многопроцессороность) и «MPP» (массово-параллельная процессорность). Эти три варианта описывают взаимодействие процессоров. При этом организация памяти у них м.б. любой из нижеперечисленных.
Термин «SMP» должен упоминаться вместе с «UMA» (однородный доступ к памяти) и «NonMA» (полное отсутствие прямого доступа к памяти другоих процессоров); до кучи хорошо бы упомянуть «RDMA» (доступ к чужой памяти есть, не не прямой, а только копированием через DMA-контроллер). Это — три или четыре варианта организации памяти, но это не всё.
Помимо общего доступа к памяти, есть ещё синхронизация кэшей — которая может были или не быть. Точнее, есть три варианта:
- Просто общий кэш. Для многочиповой системы общий кэш м.б. только внешним — а внутренний м.б. только раздельным.
- Раздельный кэш с автоматический синхронизацией (также может поддерживать считывание данных из чужого кэша — тогда говорят «кэш сделан проо архитектуре „NUMA“). Дико просаживает производительность на операциях записи.
- Раздельный кэш без синхронизации. Вынуждает использовать общую память в режиме, близком к NonMA — обмен данными через общую память сложный и дорогой.
Вообще, надо помнить, что у процессоров всегда есть своя собственная внутренняя память, недоступная никому больше. Как минимум, это регистры — которые по своей сути тоже память, но быстрая и с особыми режимами доступа. Поэтому утверждать, что „SMP — это обязательно UMA“ нельзя, ибо видов памяти в современных компьютеров много (порядка чуть ли не дюжины), и они работают в разных режимах (UMA, NUMA или NonMA).
С паравиртуализацией вообще получается очень интересно. Персональные компьютеры — это чуть ли не самое уродливое порождение эволюционного процесса, когда IT-бизнесмены старательно мешали провести полный рефакторинг. Сама преемственность от 16-битных систем реального режима с накоплением (и необходимостью поддержки) всех неудачных решений, сделанных чуть ли не за полвека стремительной эволюции — породила чудовищного кадавра (в качестве примера неудачного решения я могу назвать сегментную адресацию).
Но сейчас я хочу поговорить не об архитектуре процессора, а о программной архитектуре — которую, как ни странно, навязывает аппаратура.
Для начала — задача для IT-студентов:
- Чтобы загрузить что-то с диска — надо обратиться к контроллеру диска. Контроллеры диска бывают очень разные — например. SCSI-контроллеры имеют совершенно разный ABI.
- Чтобы выполнить запрос — драйвер (неважно какого устройства) д.б. загружен в память и инициализирован, причём ещё до первого к нему обращения.
- Пока компьютер выключен — все драйверы (в т.ч. драйвер дискового контроллера) лежат на диске (в отдельном файле, как в Windows; или вкомпилированы все вместе в один файл вместе с ядром, как в Unix). (Этот пункт выделен, ибо он понадобится нам ниже.)
Так вот, ублюдочность архитектуры перснального компьютера — в т.ч. в том, что все операционки (кроме DOS и других операционок той поры) вынуждены тащить с собой все драйверы устройств, с которыми собираются работать. Это потому, что они предполагают работу на „голом железе“. А „голое железо“ — это стандарт именно персональных компьютеров.
А вот если бы компьютер снабжался операционкой, зашитой в ПЗУ — его эволюция шла бы совершенно другими путями. Отличий было бы множество — начиная с того, что производители операционок не стали бы следовать рекомендации Билла Гейтса „надо как можно скорее выкинуть на рынок недоделанное говно и захватить рынок, убив конкурентов, которые долго и тщательно делают качественный продукт“. Хотя бы потому, что операционку в ПЗУ заменить сложно, ежедневно выпускать по дюжине обновлений (в т.ч. критические обновления безопасности) тут не получится.
Кроме того, получили бы распространение бездисковые машины. Потому что не было бы необходимости ставить локальный жёсткий диск для загрузки операционки. И администрирование компьютерного парка в корпорациях стало бы намного легче.
А ещё — при наличии операционки в ПЗУ, виртуализация появилась бы намного раньше. Просто потому, что при желании запустить на этом компьютере альтернативную операционку — её портировали бы не для рабты на голом железе, а с использованием уже имеющейся в ПЗУ операционке. При таком развитии компьютеров — никакой классической неполной виртуализации не могло возникнуть в принципе, ибо не было бы операционок, нуждающихся в ней. Была бы полная виртуализация для операционок с других платформ (если там была уродливая архитектура); и паравиртуализация.
Насчёт ОС в ПЗУ — в итоге к этому и пришли (UEFI).
Спасибо, SMP / UMA поправил.
>А вот если бы компьютер снабжался операционкой, зашитой в ПЗУ
… то его убила бы та архитектура где такой геморрой пользователю не подсовывали бы.
… то его убила бы та архитектура где такой геморрой пользователю не подсовывали бы.
Gumanoid, CrzyDocTI:
UEFI — это ни разу не операционка. Если бы она была операционкой — то под неё пписались бы программы, и люди работали бы в ней без дополнительной (загружаемой) операционки.
Можно проверить, является ли UEFI операционкой с современными требованиями:
hjornson:
У меня ощущение, что Вы вообще никогда не работали с компьютером. По кр.мере — не администрировали ни класс из нескольких компьютеров, ни даже свой собственный компьютер. Потому что если бы не так — то Вы бы знали, что самый страшный геморрой был при разрушении операционки (когда надо загружаться с внешнего носителя) и заражение операционки вирусом (где-то я читал, что вирусы с функцией заражения загрузки составляли 30% от числа вирусов и давали 90% случаев заражения компьютеров). Операционка в ПЗУ — избавлена от обеих проблем.
А какой именно геморрой может создать операционка, записанная в ПЗУ — Вы скромно умолчали.
Вообще, даво уже пора понимать, что успех той или иной системе на рнке (не только компьютерном, а практически везде) определяется не техническими характеристиками товара, а маркетингом. Исключения бывают, но очень редко — например, при создании карманных компьютеров, для которых *86 не годился вообще.
UEFI — это ни разу не операционка. Если бы она была операционкой — то под неё пписались бы программы, и люди работали бы в ней без дополнительной (загружаемой) операционки.
Можно проверить, является ли UEFI операционкой с современными требованиями:
- Какие файловые системы поддерживает UEFI? Т.е. с каких файловых систем можно запускать внешние программы?
- Какой режим процессора поддерживает UEFI — реальный 8086, защищённы 286, защищённы 386, защищённы AMD-64?
- Как в UEFI с многозадачностью?
- Какие сетевые протоколы поддерживает UEFI? В частности, как там с настройкой IP-маршрутизации? С каких сетевых файловых систем можно запускать внешние программы?
hjornson:
У меня ощущение, что Вы вообще никогда не работали с компьютером. По кр.мере — не администрировали ни класс из нескольких компьютеров, ни даже свой собственный компьютер. Потому что если бы не так — то Вы бы знали, что самый страшный геморрой был при разрушении операционки (когда надо загружаться с внешнего носителя) и заражение операционки вирусом (где-то я читал, что вирусы с функцией заражения загрузки составляли 30% от числа вирусов и давали 90% случаев заражения компьютеров). Операционка в ПЗУ — избавлена от обеих проблем.
А какой именно геморрой может создать операционка, записанная в ПЗУ — Вы скромно умолчали.
Вообще, даво уже пора понимать, что успех той или иной системе на рнке (не только компьютерном, а практически везде) определяется не техническими характеристиками товара, а маркетингом. Исключения бывают, но очень редко — например, при создании карманных компьютеров, для которых *86 не годился вообще.
Какие файловые системы поддерживает UEFI? Т.е. с каких файловых систем можно запускать внешние программы?Зависит от вендора, но все поддерживают FAT32 и многие — NTFS.
Какой режим процессора поддерживает UEFI — реальный 8086, защищённы 286, защищённы 386, защищённы AMD-64?Либо защищённый 386, либо защищённый AMD-64. На большинстве новых систем — защищённый AMD-64.
Как в UEFI с многозадачностью?Одно приложение общается с пользователем, но может быть сколько угодно фоновых. Один-в-один как в Android или iOS.
Какие сетевые протоколы поддерживает UEFI?TCP/IP, как и везде.
В частности, как там с настройкой IP-маршрутизации?Так же, как и в Android/iOS, если коротко.
С каких сетевых файловых систем можно запускать внешние программы?С тех, которые предусмотрел вендор. Обычно это PXE.
Как легко увидеть — никаких технических поводов не считать EFI операционкой нет. Вот совсем нет. Политические, социальные — да, возможно. Технически — это операционка. И довольно-таки сложная.
А какой именно геморрой может создать операционка, записанная в ПЗУ — Вы скромно умолчали.Ну какой, какой. Обычный. Достаточно тупо удалить все переменные EFI — и всё, приехали. Очередно «кирпич». Так не должно бы быть, в теории. Но так есть. У дикого количества вендоров.
Добавлю про многозадачность еще: давно уже есть возможность использовать простаивающие при обычном запуске прошивки ядра для параллельного выполнения задач (к примеру, на Маках таким образом работает Internet Recovery, т.е. загрузка и проверка хешей кусков образа по 10Мб сделана параллельно и задействует все доступные ядра ЦП) через EfiMpServiceProtocol. В UEFI 2.7 похожий протокол добавили в PEI.
Ну и в качестве вишенки на торт: современные реализации EFI используют IOMMU, виртуальную память и разделение на ring-0 и ring-3 для изоляции опасных с точки зрения внешних атак драйверов, OptionROM'ов и приложений (слайды с презентации с BH).
Я сам не стал бы называть EFI полноценной ОС общего назначения (потому что чтобы стать таковой ей нужен EFI Shell), но не называть ее ОС совсем уже давно не получается даже с натяжкой. Я по прежнему считаю, что прошивка должна быть «создана, чтобы умирать», и потому большая часть нынешней спецификации UEFI в ней совершенно лишняя, и может быть без особых проблем заменена на Линукс или другую полноценную ОС, но у индустрии давно уже свое мнение на этот счет, не совпадающее с моим.
Ну и в качестве вишенки на торт: современные реализации EFI используют IOMMU, виртуальную память и разделение на ring-0 и ring-3 для изоляции опасных с точки зрения внешних атак драйверов, OptionROM'ов и приложений (слайды с презентации с BH).
Я сам не стал бы называть EFI полноценной ОС общего назначения (потому что чтобы стать таковой ей нужен EFI Shell), но не называть ее ОС совсем уже давно не получается даже с натяжкой. Я по прежнему считаю, что прошивка должна быть «создана, чтобы умирать», и потому большая часть нынешней спецификации UEFI в ней совершенно лишняя, и может быть без особых проблем заменена на Линукс или другую полноценную ОС, но у индустрии давно уже свое мнение на этот счет, не совпадающее с моим.
У индустрии нет единого мнения. EFI продавливает Intel, потому что это позволяет ему вкорячивать в EFI свои, делающие неизвестно что, блобы, которые, типа ох-как-нужны для его процессоров.
На не телефонах или там стиральных машиных, как вы знаете, ничего этого нет.
Google пытается с этим бороться, но в мире, где Intel доминирует — сделать это очень сложно.
Веселее всего ситуация с ARM'ом на серверах: с одной стороны вендоры пытаются продавливать EFI, так как к нему привыкли, с другой — производителям ARM'овском железа всё это нафиг не нужно.
В общем весёлые времена. Как обычно, да.
На не телефонах или там стиральных машиных, как вы знаете, ничего этого нет.
Google пытается с этим бороться, но в мире, где Intel доминирует — сделать это очень сложно.
Веселее всего ситуация с ARM'ом на серверах: с одной стороны вендоры пытаются продавливать EFI, так как к нему привыкли, с другой — производителям ARM'овском железа всё это нафиг не нужно.
В общем весёлые времена. Как обычно, да.
Странно, что унификация доступа к памяти совсем никак не описана. Никак не описаны himem.sys emm386.exe и qemm386. Совсем не затронута компания QuartDesq и один из первых успешных гипервизоров для DOS.
Без темы многозадачности и параллельного выполнения странно начинать тему виртуализации.
Без темы многозадачности и параллельного выполнения странно начинать тему виртуализации.
Совсем не затронута компания QuartDesq и один из первых успешных гипервизоров для DOS.Поиск в Гугле находит это слово в интеренете ровно один раз — в вашем комменатрии. Вы из параллельной вселенной? Что за «гипервизор для DOS»?
himem.sys — это, всё-таки, о другом совсем… может быть EMS? Digital Research (в нашей вселенной) реализовывала многозадачную систему на базе CP/M, где память виртуализовывалась на базе EMS… это близко к описанным вначале FS -> LBA -> CHS… но нельзя охватить необъятного — это уже будет не статья, а книга на полтысячи страниц, если попытаться охватить все подобные примеры. Это же просто вводная была, я так понимаю охватить вот совсем всё-всё задача не ставилась…
С вашего поволения, немного развею туман веков над этим вопросом.
Компания называлась Quarterdeck (полностью — Quarterdeck Office Systems), выпущенный ей продукт для виртуализации DOS (в котором можно было запускать несколько DOS VM в режиме виртуализации реального режима — V86) — DESQView.
Спецификация EMS к виртуальнм машинам прямого отношения не имела: она описывала, как можно отображать в доступное адресное пространство объем памяти, больший, чем пресловутые 640К(в реальности — 1М, т.к. оставшиеся 384К были зарезервированы под адресное пространство для ПЗУ и памяти, используемой переферийными устройствами) — через специально отводимое перемещаемое по этой большей памяти «окно». Такие решения по расширеню адресуемой памяти в истории развития вычислительной техники возникали неоднократно (кто был первый — даже не знаю). К примеру, когда развитие ОС для x86 уперлось в ограничение 32бит адреса, то в Windows Server появилось аналогичная по своей сути спецификация доступа к памяти свыше 4ГБ — AWS.
В случае EMS изначально предполагалось, что управление отображением будет реализовано специальной аппаратурой (размещенной вместе с дополнительной памятью на плате расширения или выполненной внутри чипсета). Однако уже упомянутая Quaterdeck научилась использовать вместо этой аппаратуры появившийся в 80386 режим виртуализации V86. Для этого она выпустила драйвер QEMM-386. Который тоже отчасти был чем-то вроде «одноместного гипервизора»: DOS после инициализации этого драйвера работала не в реальном, а в V86 режиме процессора, но — с прямым отображением почти всей памяти (виртуальные адреса были равны реальным) — кроме области окна, в которую этот драйвер отображал в соотвествии со спецификацией EMS имеющуюся в системе оперативную память, находящуюся над границей 640К.
PS А ещё, кстати, гипервизором для DOS была и Windows(в расширенном режиме) — в ней DOS-окна запускались как раз в режиме V86.
Компания называлась Quarterdeck (полностью — Quarterdeck Office Systems), выпущенный ей продукт для виртуализации DOS (в котором можно было запускать несколько DOS VM в режиме виртуализации реального режима — V86) — DESQView.
Спецификация EMS к виртуальнм машинам прямого отношения не имела: она описывала, как можно отображать в доступное адресное пространство объем памяти, больший, чем пресловутые 640К(в реальности — 1М, т.к. оставшиеся 384К были зарезервированы под адресное пространство для ПЗУ и памяти, используемой переферийными устройствами) — через специально отводимое перемещаемое по этой большей памяти «окно». Такие решения по расширеню адресуемой памяти в истории развития вычислительной техники возникали неоднократно (кто был первый — даже не знаю). К примеру, когда развитие ОС для x86 уперлось в ограничение 32бит адреса, то в Windows Server появилось аналогичная по своей сути спецификация доступа к памяти свыше 4ГБ — AWS.
В случае EMS изначально предполагалось, что управление отображением будет реализовано специальной аппаратурой (размещенной вместе с дополнительной памятью на плате расширения или выполненной внутри чипсета). Однако уже упомянутая Quaterdeck научилась использовать вместо этой аппаратуры появившийся в 80386 режим виртуализации V86. Для этого она выпустила драйвер QEMM-386. Который тоже отчасти был чем-то вроде «одноместного гипервизора»: DOS после инициализации этого драйвера работала не в реальном, а в V86 режиме процессора, но — с прямым отображением почти всей памяти (виртуальные адреса были равны реальным) — кроме области окна, в которую этот драйвер отображал в соотвествии со спецификацией EMS имеющуюся в системе оперативную память, находящуюся над границей 640К.
PS А ещё, кстати, гипервизором для DOS была и Windows(в расширенном режиме) — в ней DOS-окна запускались как раз в режиме V86.
продукт для виртуализации DOS (в котором можно было запускать несколько DOS VM в режиме виртуализации реального режима — V86) — DESQView.Там нет «нескольких VM». Да, там происходит некоторая виртуализация DOS, но это не OS/2 и даже не Windows.
DESQView может работать на 80286 и даже 8086! Какие, к бесу, виртуальные машины???
Спецификация EMS к виртуальнм машинам прямого отношения не имела:Имела-имела. Именно поверх EMS DESQview и виртуализировал DOS. А уже VM8086 использовался, чтобы реализовать EMS поверх расширенной памяти.
Однако уже упомянутая Quaterdeck научилась использовать вместо этой аппаратуры появившийся в 80386 режим виртуализации V86Про CEMM от Compaq, вы, я так полагаю, не в курсе? Она поставлялась с первым IBM PC-совместимым компьютером на базе 80386.
PS А ещё, кстати, гипервизором для DOS была и Windows(в расширенном режиме) — в ней DOS-окна запускались как раз в режиме V86.Тут уже начинается мухлёж с терминологией. Вот OS/2 — та, да, таки умела запустить любую версию DOS в окошке. Это можно назвать гипервизором. А вот DESQview и Windows… Тут всё сложнее. Фактически они делали с помощью EMS «клоны» одной и той версии DOS из которой они сами и запускались. И даже Windows 3.x, научившись использовать VM8086 напрямую… Всё равно делала лишь клоны (откуда и проблемы совместимости с DR-DOS). А вот Windows-95 — там уже был гипервизор… Но если система подхватывала вирус, то включался «режим совместимости с вирусом», такой же как в Windows 3.x — что сразу замечалось по нереальным тормозам…
Там нет «нескольких VM». Да, там происходит некоторая виртуализация DOS, но это не OS/2 и даже не Windows.
«Некоторая виртуализация» заключалась в том, что эти копии DOS могли работать независимо дург от друга и параллельно, в режиме вытесняющей многозадачности. А то, что они использовали один и тот же код ядра, то это и в других гипервизорах встречалось: например, в VM/SP, где все VM с одной и той же хранимой системой (например, CMS) использовали один и тот же код ядра.
DESQView может работать на 80286 и даже 8086! Какие, к бесу, виртуальные машины???Да, тут требуется уточнение: речь была конкретно о версии Desqview 386 (с которой я некогда реально работал).
Про CEMM от Compaq, вы, я так полагаю, не в курсе?
В курсе: как вы заметили, я отнюдь не утверждал, что Quaterdeck научилась это делать первая.
Тут уже начинается мухлёж с терминологией.Факт состоит в том, что Desqview (равно как и Win3.x Extended mode) выполнял фукцию управляющего ПО, работавшего на уровне ниже ОС (DOS в конкретном случае), с более высокими привилегиями, и определявшего, что именно из аппаратуры и прерываний доступно вышележащей ОС — что обычно как раз и называется в наше время словом «гипервизор» (да, раньше такого слова не было, в VM/SP, к примеру, этот компонент именовался незатейливо: Control Program).
И даже Windows 3.x, научившись использовать VM8086 напрямую… Всё равно делала лишь клоны (откуда и проблемы совместимости с DR-DOS). А вот Windows-95 — там уже был гипервизор…Windows 95 от Windows 3.x Extended Mode в этом плане архитектурно отличалась мало: и WIN386.EXE из Win3.x, и VMM32.VXD выполняли примерно одни и те же функции компонента Virtual Machine Manager: управление вытесняющей многозадачностью для VM (выполняющих DOS и системной, выпоняющей Windows), обработку прерываний, управление памятью… Подробности (которые сейчас представляют, разве что чисто исторический интерес) можно прочесть, например, в старой книге Шульмана «Неофициальная Windows 95». Ну, а режим совместимости — он был поблажкой именно ради совместимости с TSR(резидентными программами для DOS), работающим с обращениями к файловой системе и диску (которые были как полезные, ради которых эта проверка делалалсь, так и наоборот — то есть вирусы). А так, в принципе, Windows могла его и не включать, и работать с файловой системой, не используя код DOS (и Win 3.11 тоже могла, называлось это 32BFA, VxD под это в ней был, только им часто не пользовались, потому как в нем как раз упомянутого режима совместимости не было)
Это каким образом kvm 'первого типа', если это модуль ядра, уважащий все правила ядра? А амазон, вообще говоря, уже на всех парах на firecracker бежит.
Гипервизор второго типа работает в user space как обычное приложение поверх ОС общего назначения.
У вас какое-то извращённое представление о том, что такое "второй тип". Второй тип — это когда "сверху" ОС, т.е. ОС управляет памятью, правами доступа и т.д. kvm прекрасно во второй тип укладывается. Требование "userspace" я ни разу в описании гипервизоров не видел, хотя бы потому, что невозможно реализовать гипервизор в userspace, там можно сделать только эмулятор.
Георгий, это у вас какие то свои термины и понимание того, что такое гипервизор.
Senior director, virtualization business at Red Hat:
“KVM is a bare-metal hypervisor (also known as Type I)”
It is a myth that KVM is not a Type-1 hypervisor. KVM converts Linux into a Type-1 hypervisor. There is only one kernel that is used (and that is the Linux kernel, which has KVM included). On the flip side, I can make an argument that Xen is not a Type-1 hypervisor, because the CPU and memory is scheduled by the hypervisor, but IO is scheduled by Dom0, which is a guest (so it's not bare metal). In the KVM architecture, the CPU, memory, and IO are scheduled by the Linux kernel with KVM.
Senior director, virtualization business at Red Hat:
“KVM is a bare-metal hypervisor (also known as Type I)”
It is a myth that KVM is not a Type-1 hypervisor. KVM converts Linux into a Type-1 hypervisor. There is only one kernel that is used (and that is the Linux kernel, which has KVM included). On the flip side, I can make an argument that Xen is not a Type-1 hypervisor, because the CPU and memory is scheduled by the hypervisor, but IO is scheduled by Dom0, which is a guest (so it's not bare metal). In the KVM architecture, the CPU, memory, and IO are scheduled by the Linux kernel with KVM.
Не могли бы вы посоветовать, что можно почитать по KVM? Интересует, в первую очередь, то, что скрыто под капотом. Пока натыкался лишь на довольно общие описания и обрывки подробной информации. В kernel/Documents/virt неплохо описаны некоторые вещи, но инфы маловато.
Начните с этого материала (тем более, что команда IBM участвовала в процессе создания KVM)
developer.ibm.com/tutorials/l-hypervisor
developer.ibm.com/articles/cl-hypervisorcompare-kvm
developer.ibm.com/tutorials/l-hypervisor
developer.ibm.com/articles/cl-hypervisorcompare-kvm
модуль ядра, конвертирующий ядро в гипервизор. Дерзко. Я думаю, это подтрунивание над xen'ом.
Очевидно, что kvm есть, что kvm нет, линукс как памятью управлял, так и управляет.
Однако, до полноценной виртуализации (и ее варианта в виде паравиртуализации) jail не хватает возможности запускать ядро другой версии в гостевой ВМ и кластеризации с миграцией ВМ на другую хост систему.
Это не соответствует действительности. Во FreeBSD jails с успехом запускаются не только гостевые FreeBSD с другими версиями ядра, но и всевозможные Linux.
При полноценной виртуализации можно запускать любую x86 ОС, не только Linux.
Не подскажете где подробно рассказывается как именно запускается *всевозможный* Linux, в каком формате диски, как мигрировать с одного хоста на другой?
Не подскажете где подробно рассказывается как именно запускается *всевозможный* Linux, в каком формате диски, как мигрировать с одного хоста на другой?
Начните со FreeBSD Handbook а далее, обычно, пользуются поиском.
Кластеризация и миграция не являются признаками "полноценной виртуализации" (чтобы вы под ней не имели ввиду).
Вообще, статья плохо структурирована и столь же плохо читается. Вероятно, это признак того что вы недостаточно сами разобрались в теме.
Я вам сходу указал на явно бросившееся в глаза ошибочное утверждение.
Кроме того, во FreeBSD есть ещё и bhyve.
https://www.bsdstore.ru/ru/articles/bhyve_vs_jails.html
с другими версиями ядра
Ядро используется хостовое, и запустить вы сможете внутри jail только тот набор userspace приложений, который может работать с текущим хостовым ядром. Понятно, что это может быть и linux userspace, если хостовое ядро собрано с linux_enable=«YES».
НЛО прилетело и опубликовало эту надпись здесь
Антон, пишется Fibre Channel.
В статье есть досадный (IMHO) пробел: полностью отсутствует упоминание об аппаратной виртуализации реального режима в процессоре 80386 и его потомках и клонах (режим V86) и о его использовании для создания виртуальных DOS-машин в Windows 3.x и 9x/ME (а также — в уже упомянутой DesqView и других ОС для ПК).
А какая VDM(Virtual DOS Machine) была в OS/2? Мало того что позволяла запускать любые версии DOS с образов дискет, так ещё искаропки в OS/2 шла 3.11 винда с прозрачной интеграцией в десктоп «хостовой» ОС. Мало того, в середине 90-х была микроядерная версия — OS/2 PowerPC Edition, как не сложно понять под архитектуру PowerPC, так вот в ней был и VDM и 3.11 винда и виртуализация x86 процессора…
Увы, да. Готовы восполнить этот пробел?
Очень интересная статья для начинающих в этой теме, благодарю!
Хотелось бы немного более развернуто услышать про
"компьютер, несмотря на свое название, считать не умеет, он умеет делать вид, что умеет считать"
а то звучит как какой-то выпендрёж.
"Компьютер, а конкретно процессор, на самом деле ничего не исполняет — он всего лишь ожидает некоторых входных параметров в определенных местах, а после, посредством страшной черной магии, выдает некоторые результаты в определенных местах."
Опять же, звучит красиво для какого нибудь жёлтого журнала, а по сути — бред, т.к исполнение кода и состоит в том, что бы делать "… некоторых входных параметров в определенных местах, а после, посредством страшной черной магии, выдает некоторые результаты в определенных местах.", и называется это fetch/decode/execute/store циклом.
Смотрите, в гипервизоре II ресурсами (память, ввод-вывод) управляет программное обеспечение установленное поверх операционной системы. Этому программному обеспечению выделяются ресурсы ровно так же как и для любого другого программного обеспечения — базы данных, сервера приложений и т. п. Далее, ПО виртуализации управляет полученными ресурсами, обеспечивая работу виртуальных машин. Например, выделение памяти для ВМ происходит программой виртуализации.
В KVM — управление ресурсами для обеспечения работы виртуальных машин выполняется ну уровне Linux. В этом смысле, Linux такой же гипервизор как VMware — не больше и меньше — гипервизор I типа.
В KVM — управление ресурсами для обеспечения работы виртуальных машин выполняется ну уровне Linux. В этом смысле, Linux такой же гипервизор как VMware — не больше и меньше — гипервизор I типа.
Благодарю за статью!
Отличный экскурс в историю развития современных продуктов. Прочитал всё на одном дыхании.
Отличный экскурс в историю развития современных продуктов. Прочитал всё на одном дыхании.
Большое спасибо! Прочитал с огромным удовольствием. Правда понадобилось два подхода, чтобы прочитать статью полностью.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Общая теория и археология виртуализации x86