This does not guarantee the CPU family, stepping, etc will precisely match the host CPU, as they would with “Host passthrough”, but gives much of the benefit of passthrough, while making live migration safe. This uses the QEMU “Named model” feature, automatically picking a CPU model that is similar the host CPU, and then adding extra features to approximate the host model as closely as possible. Libvirt supports a third way to configure CPU models known as “Host model”. In both cases, it is possible to optionally add or remove individual CPU features, to alter what is presented to the guest by default. These allow the guest VMs to have a degree of isolation from the host CPU, allowing greater flexibility in live migrating between hosts with differing hardware. Named model QEMU comes with a number of predefined named CPU models, that typically refer to specific generations of hardware released by Intel and AMD. This is the recommended CPU to use, provided live migration is not required. Live migration is unsafe when this mode is used as libvirt / QEMU cannot guarantee a stable CPU is exposed to the guest across hosts. Note that KVM may filter out some host CPU model features if they cannot be supported with virtualization. QEMU / KVM virtualization supports two ways to configure CPU models Host passthrough This passes the host CPU model features, model, stepping, exactly to the guest. This blog post contains content I’ve written that is on its way to become part of the QEMU documentation. With the various CPU hardware vulnerabilities reported this year, guest CPU configuration is now a security critical task. Posted: June 29th, 2018 | Filed under: Fedora, libvirt, OpenStack, Security, Virt Tools | Tags: cpu, kvm, libvirt, meltdown, qemu, spectre, ssbd, virtual machine | 15 Comments »
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |