Пасля васьмі месяцаў распрацоўкі апублікаваны рэліз вольнага гіпервізара Xen 4.16. У распрацоўцы новага выпуску прынялі ўдзел такія кампаніі, як Amazon, Arm, Bitdefender, Citrix і EPAM Systems. Выпуск абнаўленняў для галінкі Xen 4.16 працягнецца да 2 чэрвеня 2023 гады, а публікацыя выпраўленняў уразлівасцяў да 2 снежня 2024 гады.
Ключавыя змены ў Xen 4.16:
- У TPM Manager, які забяспечвае працу віртуальных чыпаў для захоўвання крыптаграфічных ключоў (vTPM), якія рэалізуюцца на базе агульнага фізічнага TPM (Trusted Platform Module), унесены выпраўленні для наступнай рэалізацыі падтрымкі спецыфікацыі TPM 2.0.
- Падвышаная залежнасць ад праслойкі PV Shim, ужывальнай для запуску немадыфікаваных паравіртуалізаваных гасцявых сістэм (PV) у асяроддзі PVH і HVM. У далейшым выкарыстанне 32-разрадных паравіртуалізаванай гасцявых сістэм будзе магчымым толькі ў рэжыме PV Shim, што дазволіць паменшыць колькасць месцаў у гіпервізоры, у якіх патэнцыйна могуць быць уразлівасці.
- Дададзена магчымасць загрузкі на прыладах Intel без праграмуемага таймера (PIT, Programmable Interval Timer).
- Праведзена чыстка састарэлых кампанентаў, спынена зборка па змаўчанні кода "qemu-xen-traditional" і PV-Grub (неабходнасць у дадзеных спецыфічных для Xen форках знікла пасля перадачы змен з падтрымкай Xen у асноўны склад QEMU і Grub).
- Для гасцявых сістэм з архітэктрай ARM рэалізавана пачатковая падтрымка віртуалізаваных лічыльнікаў для адсочвання прадукцыйнасці (Performance Monitor Counters).
- Палепшана падтрымка рэжыму dom0less, які дазваляе абыйсціся без разгортвання асяроддзя dom0 пры запуску віртуальных машын на ранняй стадыі загрузкі сервера. Унесеныя змены дазволілі рэалізаваць падтрымку 64-разрадных сістэм ARM з EFI-прашыўкамі.
- Палепшана падтрымка гетэрагенных 64-разрадных сістэм ARM на базе архітэктуры big.LITTLE, якія камбінуюць у адным чыпе магутныя, але спажываюць шмат энергіі, ядры, і менш прадукцыйныя, але больш энергаэфектыўныя ядра.
Адначасова кампанія Intel апублікавала выпуск гіпервізара Cloud Hypervisor 20.0, пабудаванага на аснове кампанентаў сумеснага праекту Rust-VMM, у якім акрамя Intel таксама ўдзельнічаюць кампаніі Alibaba, Amazon, Google і Red Hat. Rust-VMM напісаны на мове Rust і дазваляе ствараць спецыфічныя для пэўных задач гіпервізары. Cloud Hypervisor з'яўляецца адным з такіх гіпервізораў, які дае высокаўзроўневы манітор віртуальных машын (VMM), які працуе па-над KVM і аптымізаваны для рашэння задач, уласцівых для хмарных сістэм. Код праекту даступны пад ліцэнзіяй Apache 2.0.
Cloud Hypervisor зфакусаваны на запуску сучасных дыстрыбутываў Linux з выкарыстаннем паравіртуалізаваных прылад на базе virtio. З ключавых задач згадваецца: высокая спагадлівасць, нізкае спажыванне памяці, высокая прадукцыйнасць, спрашчэнне наладкі і скарачэнне магчымых вектараў для нападаў. Падтрымка эмуляцыі зведзена да мінімуму і стаўка робіцца на паравіртуалізацыю. У наш час падтрымліваюцца толькі сістэмы x86_64, але ў планах маецца і падтрымка AArch64. З гасцявых сістэм пакуль падтрымліваецца толькі 64-разрадныя зборкі Linux. Настройка CPU, памяці, PCI і NVDIMM вырабляецца на этапе зборкі. Прадугледжана магчымасць міграцыі віртуальных машын паміж серверамі.
У новай версіі:
- Для архітэктур x86_64 і aarch64 зараз дапушчаецца стварэнне да 16 PCI-сегментаў, што павялічвае агульны лік дапушчальных PCI-прылад з 31 да 496.
- Рэалізаваная падтрымка прывязкі віртуальных CPU да фізічных ядраў CPU (CPU pinning). Для кожнага vCPU зараз можна вызначыць абмежаваны набор хостовых CPU, на якіх дапушчаецца выкананне, што можа быць карысным пры прамым адлюстраванні (1:1) рэсурсаў хаста і гасцёўні сістэмы або пры запуску віртуальнай машыны на вызначаным вузле NUMA.
- Палепшана падтрымка віртуалізацыі ўводу/высновы. Кожны рэгіён VFIO зараз можа быць адлюстраваны ў памяць, што зніжае колькасць аперацый выхаду з віртуальнай машыны і дазваляе дабіцца павышэння прадукцыйнасці пракіду прылад у віртуальную машыну.
- У кодзе на мове Rust праведзена праца па замене unsafe-секцый на альтэрнатыўныя рэалізацыі, якія выконваюцца ў рэжыме safe. Для пакінутых unsafe-секцый дададзены падрабязныя каментары з тлумачэннем чаму пакінуты unsafe-код можна лічыць бяспечным.
Крыніца: opennet.ru