[libvirt] [PATCH] qemu: Starting a domain with custom model and allowed-fallback failed when host lacks some CPU features
11:23 a.m.
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(a)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
12:56 p.m.
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
2:52 a.m.
New subject: [libvirt] [PATCH] qemu: Starting a domain with custom model andallowed-fallback failed when host lacks some CPU features
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
2:54 p.m.
New subject: [libvirt] [PATCH] qemu: Starting a domain with custom model andallowed-fallback failed when host lacks some CPU features
On Wed, Jun 07, 2017 at 02:52:05 +0800, wang.yi59(a)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
2756
days inactive
2756
days old
3 comments
3 participants
participants (3)
-
Jiri Denemark -
wang.yi59＠zte.com.cn -
Yi Wang