[libvirt] [PATCH] qemu: Starting a domain with custom model and allowed-fallback failed when host lacks some CPU features
An attemp to start a domain requesting a custom CPU model, core2duo, for example, will fail if some feature that the model needs doesn't exist in that host, even though fallback attibute is set allow: "error: the CPU is incompatible with host CPU: Host CPU does not provide required features: monitor" Of course we can start that domain through forbidding that feature, but that may not be flexible. Signed-off-by: Yi Wang <wang.yi59@zte.com.cn> --- src/qemu/qemu_process.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index 32ba8e3..1bb65d3 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -5324,7 +5324,8 @@ qemuProcessUpdateGuestCPU(virDomainDefPtr def, virCPUCompare(caps->host.arch, virQEMUCapsGetHostModel(qemuCaps, def->virtType, VIR_QEMU_CAPS_HOST_CPU_FULL), - def->cpu, true) < 0) + def->cpu, + def->cpu->fallback != VIR_CPU_FALLBACK_ALLOW) < 0) return -1; if (virCPUUpdate(def->os.arch, def->cpu, -- 1.8.3.1
On Tue, Jun 06, 2017 at 12:23:01 -0400, Yi Wang wrote:
An attemp to start a domain requesting a custom CPU model, core2duo, for example, will fail if some feature that the model needs doesn't exist in that host, even though fallback attibute is set allow: "error: the CPU is incompatible with host CPU: Host CPU does not provide required features: monitor" Of course we can start that domain through forbidding that feature, but that may not be flexible.
NACK, it works exactly as designed. The fallback attribute would make a difference only if core2duo CPU model was not supported by QEMU, then libvirt would translate it into a different supported one. Jirka
SGkgSmlya2EsVGhhbmtzIGZvciB5b3VyIHJldmlld2luZy4gQnV0IGluIHRoZSBjb25kaXRpb24g SSBkZXNjcmliZWQsIGxpYnZpcnQgaGFzIG5vIGNoYW5jZSB0byB0cmFuc2xhdGUgaW50byBhIGRp ZmZlcmVudCBtb2RlbCwgYmVjYXVzZSBpdCBoYXMgZmFpbGVkIGluIHRoZSB2aXJDUFVDb21wYXJl IGJlZm9yZSB0cmFuc2xhdGUgYW5kIHRoZSBzdGFydCBvZiB0aGUgZG9tYWluIHdpbGwgcmVwb3J0 IHRoZSBlcnJvciwgaXQgdGhhdCBjb3JyZWN0PyBGb3IgZXhhbXBsZSwgYSBob3N0IGxhY2tzICJt b25pdG9yIiBmZWF0dXJlLCB3aGljaCBtZWFucyB0aGF0IHdlIGNhbid0IHNlZSAibW9uaXRvciIg ZmxhZyB3aGVuIHdlIHJ1biAiY2F0IC9wcm9jL2NwdWluZm8iLCBpdCB3aWxsIHJlcG9ydCBlcnJv ciB3aGVuIHdlIHRyeSB0byBzdGFydCB0aGUgZG9tYWluIHdpdGggY29yZTJkdW8gbW9kZWw6ImVy cm9yOiB0aGUgQ1BVIGlzIGluY29tcGF0aWJsZSB3aXRoIGhvc3QgQ1BVOiBIb3N0IENQVSBkb2Vz IG5vdCBwcm92aWRlcmVxdWlyZWQgZmVhdHVyZXM6IG1vbml0b3IiWWkgV2FuZyANCg0KT3JpZ2lu YWwgDQogDQogDQogDQoNClNlbmRlcjpKaXJpRGVuZW1hcmsNCg0KVG86V2FuZ1lpMTAxMjk5NjMN Cg0KQ2M6bGlidmlyLWxpc3RAcmVkaGF0LmNvbUxpdUppYW5KdW4xMDAzMzQ4Mg0KDQpEYXRlOjIw MTctMDYtMDcgMDE6NTY6MDINCg0KU3ViamVjdDpSZTogW2xpYnZpcnRdIFtQQVRDSF0gcWVtdTog U3RhcnRpbmcgYSBkb21haW4gd2l0aCBjdXN0b20gbW9kZWwgYW5kYWxsb3dlZC1mYWxsYmFjayBm YWlsZWQgd2hlbiBob3N0IGxhY2tzIHNvbWUgQ1BVIGZlYXR1cmVzDQoNCiBPbiBUdWUsIEp1biAw NiwgMjAxNyBhdCAxMjoyMzowMSAtMDQwMCwgWWkgV2FuZyB3cm90ZTo+IEFuIGF0dGVtcCB0byBz dGFydCBhIGRvbWFpbiByZXF1ZXN0aW5nIGEgY3VzdG9tIENQVSBtb2RlbCwgY29yZTJkdW8sIGZv cj4gZXhhbXBsZSwgd2lsbCBmYWlsIGlmIHNvbWUgZmVhdHVyZSB0aGF0IHRoZSBtb2RlbCBuZWVk cyBkb2Vzbid0IGV4aXN0IGluIHRoYXQ+IGhvc3QsIGV2ZW4gdGhvdWdoIGZhbGxiYWNrIGF0dGli dXRlIGlzIHNldCBhbGxvdzo+ICJlcnJvcjogdGhlIENQVSBpcyBpbmNvbXBhdGlibGUgd2l0aCBo b3N0IENQVTogSG9zdCBDUFUgZG9lcyBub3QgcHJvdmlkZT4gcmVxdWlyZWQgZmVhdHVyZXM6IG1v bml0b3IiPiBPZiBjb3Vyc2Ugd2UgY2FuIHN0YXJ0IHRoYXQgZG9tYWluIHRocm91Z2ggZm9yYmlk ZGluZyB0aGF0IGZlYXR1cmUsIGJ1dD4gdGhhdCBtYXkgbm90IGJlIGZsZXhpYmxlLk5BQ0ssIGl0 IHdvcmtzIGV4YWN0bHkgYXMgZGVzaWduZWQuIFRoZSBmYWxsYmFjayBhdHRyaWJ1dGUgd291bGQg bWFrZSBhZGlmZmVyZW5jZSBvbmx5IGlmIGNvcmUyZHVvIENQVSBtb2RlbCB3YXMgbm90IHN1cHBv cnRlZCBieSBRRU1VLCB0aGVubGlidmlydCB3b3VsZCB0cmFuc2xhdGUgaXQgaW50byBhIGRpZmZl cmVudCBzdXBwb3J0ZWQgb25lLkppcmth
On Wed, Jun 07, 2017 at 02:52:05 +0800, wang.yi59@zte.com.cn wrote:
But in the condition I described, libvirt has no chance to translate into a different model
It doesn't need to translate the CPU model because QEMU supports core2duo CPU model. It's hard to imagine with such an ancient CPU model, let's consider Skylake-Client CPU model for now... If you try to use this model with old QEMU which does not know anything about Skylake-Client, fallback='allow' will allow libvirt to translate the CPU model to something else known to the old QEMU, but adding all features present in Skylake-Client and missing from the other model. With fallback='forbid' libvirt will just refuse to start the domain because the CPU model is unknown to QEMU. In addition to this libvirt checks whether such CPU can even be provided by QEMU/KVM on the current host. And in your case libvirt decides core2duo cannot be used on your host because it does not support 'monitor' feature required for the core2duo CPU model. You either need to use a different CPU model or explicitly disable this feature. Another option is to add check='none' attribute into the <cpu> element to tell libvirt to ignore this. In such a case QEMU will likely disable the feature itself. Jirka
participants (3)
-
Jiri Denemark -
wang.yi59＠zte.com.cn -
Yi Wang