Cloud Hypervisor v0.3.0 Released!
Posted October 18, 2019 by Cloud Hypervisor Team ‐ 2 min read
This release has been tracked through the 0.3.0 project.
cloud-hypervisor version 0.3.0 include:
Block device offloading
We continue to work on offloading paravirtualized I/O to external processes, and we added support for vhost-user-blk backends.
cloud-hypervisor users to plug a
vhost-user based block device like SPDK) into the VMM as their paravirtualized storage backend.
Network device backend
The previous release provided support for vhost-user-net backends. Now we also provide a TAP based vhost-user-net backend, implemented in Rust. Together with the vhost-user-net device implementation, this will eventually become the Cloud Hypervisor default paravirtualized networking architecture.
In order to more efficiently and securely communicate between host and guest, we added an hybrid implementation of the VSOCK socket address family over virtio. Credits go to the Firecracker project as our implementation is a copy of theirs.
HTTP based API
In anticipation of the need to support asynchronous operations to Cloud Hypervisor guests (e.g. resources hotplug and guest migration), we added a HTTP based API to the VMM. The API will be more extensively documented during the next release cycle.
Memory mapped virtio transport
In order to support potential PCI-free use cases, we added support for the virtio MMIO transport layer. This will allow us to support simple, minimal guest configurations that do not require a PCI bus emulation.
As we want to improve our nested guests support, we added support for exposing a paravirtualized IOMMU device through virtio. This allows for a safer nested virtio and directly assigned devices support.
To add the IOMMU support, we had to make some CLI changes for Cloud Hypervisor users to be able to specify if devices had to be handled through this virtual IOMMU or not. In particular, the
--disk option now expects disk paths to be prefixed with a
path= string, and supports an optional
Large memory guests
After simplifying and changing our guest address space handling, we can now support guests with large amount of memory (more than 64GB).
See the GitHub Release for the release assets.