Despois de oito meses de desenvolvemento, lanzouse o hipervisor gratuíto Xen 4.16. No desenvolvemento da nova versión participaron empresas como Amazon, Arm, Bitdefender, Citrix e EPAM Systems. O lanzamento de actualizacións para a rama Xen 4.16 durará ata o 2 de xuño de 2023 e a publicación de correccións de vulnerabilidades ata o 2 de decembro de 2024.
Cambios clave en Xen 4.16:
- O Xestor de TPM, que garante o funcionamento de chips virtuais para almacenar claves criptográficas (vTPM), implementado sobre a base dun TPM físico común (Módulo de plataforma de confianza), foi corrixido para implementar posteriormente soporte para a especificación TPM 2.0.
- Aumento da dependencia da capa PV Shim utilizada para executar hóspedes paravirtualizados (PV) non modificados en ambientes PVH e HVM. No futuro, o uso de convidados paravirtualizados de 32 bits só será posible no modo PV Shim, o que reducirá o número de lugares no hipervisor que poderían conter vulnerabilidades.
- Engadida a posibilidade de arrincar en dispositivos Intel sen temporizador programable (PIT, Temporizador de intervalo programable).
- Limpou os compoñentes obsoletos, deixou de construír o código predeterminado "qemu-xen-traditional" e PV-Grub (a necesidade destes forks específicos de Xen desapareceu despois de que os cambios co soporte de Xen fosen transferidos á estrutura principal de QEMU e Grub).
- Para os hóspedes con arquitectura ARM, implementouse o soporte inicial para os contadores de monitores de rendemento virtualizados.
- Compatibilidade mellorada para o modo dom0less, que permite evitar a implantación do ambiente dom0 ao iniciar máquinas virtuais nunha fase inicial do inicio do servidor. Os cambios realizados permitiron implementar soporte para sistemas ARM de 64 bits con firmware EFI.
- Compatibilidade mellorada para sistemas ARM heteroxéneos de 64 bits baseados na arquitectura big.LITTLE, que combinan núcleos potentes pero que consumen enerxía e núcleos de menor rendemento pero máis eficientes en enerxía nun só chip.
Ao mesmo tempo, Intel publicou o lanzamento do hipervisor Cloud Hypervisor 20.0, construído a partir de compoñentes do proxecto conxunto Rust-VMM, no que tamén participan, ademais de Intel, Alibaba, Amazon, Google e Red Hat. Rust-VMM está escrito na linguaxe Rust e permítelle crear hipervisores específicos para tarefas. Cloud Hypervisor é un destes hipervisores que proporciona un monitor de máquina virtual (VMM) de alto nivel que se executa enriba de KVM e está optimizado para tarefas nativas da nube. O código do proxecto está dispoñible baixo a licenza Apache 2.0.
Cloud Hypervisor céntrase en executar distribucións Linux modernas utilizando dispositivos paravirtualizados baseados en virtio. Entre os obxectivos fundamentais mencionados están: alta capacidade de resposta, baixo consumo de memoria, alto rendemento, configuración simplificada e redución de posibles vectores de ataque. O soporte de emulación redúcese ao mínimo e o foco está na paravirtualización. Actualmente só se admiten sistemas x86_64, pero está previsto o soporte para AArch64. Para os sistemas convidados, actualmente só se admiten compilacións de 64 bits de Linux. A CPU, a memoria, o PCI e o NVDIMM están configurados na fase de montaxe. É posible migrar máquinas virtuais entre servidores.
Na nova versión:
- Para as arquitecturas x86_64 e aarch64, agora están permitidos ata 16 segmentos PCI, o que aumenta o número total de dispositivos PCI permitidos de 31 a 496.
- Implementouse o soporte para vincular CPU virtuais a núcleos físicos de CPU (fixación da CPU). Para cada vCPU, agora é posible definir un conxunto limitado de CPUs anfitrións nas que se permite a execución, o que pode ser útil ao mapear directamente (1:1) recursos de host e convidado ou cando se executa unha máquina virtual nun nodo NUMA específico.
- Compatibilidade mellorada para a virtualización de E/S. Agora pódese mapear cada rexión VFIO á memoria, o que reduce o número de saídas da máquina virtual e mellora o rendemento dos dispositivos de reenvío á máquina virtual.
- No código Rust, traballouse para substituír seccións inseguras por implementacións alternativas executadas en modo seguro. Para as seccións inseguras restantes, engadíronse comentarios detallados que explican por que o código inseguro restante se pode considerar seguro.
Fonte: opennet.ru