Bug 1339680
| Summary: | libvirt CPU driver fails to translate a custom CPU model into something that QEMU recognizes | ||
|---|---|---|---|
| Product: | [Community] Virtualization Tools | Reporter: | Kashyap Chamarthy <kchamart> |
| Component: | libvirt | Assignee: | Jiri Denemark <jdenemar> |
| Status: | CLOSED NEXTRELEASE | QA Contact: | |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | unspecified | CC: | berrange, jdenemar, libvirt-maint, rbalakri |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-09-22 13:55:15 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1199452 | ||
| Attachments: | |||
|
Description
Kashyap Chamarthy
2016-05-25 15:14:21 UTC
Created attachment 1161481 [details]
libvirt debug log when the error was triggered
Created attachment 1161486 [details]
Modified libvirt cpu_map.xml
So it looks like the whole code which computes the right CPU model is skipped. The reason is <domain type='qemu'>. Our code avoids comparing guest CPU definition to host CPU for TCG mode (since the host CPU is irrelevant in this case). And as a side effect the code that would translate the gate64 CPU model into something that is supported by QEMU is skipped too. Additional info
---------------
When I try to reproduce the error by trying via `virt-install`:
$ sudo virsh cpu-models x86_64 | grep gate64
gate64
$ sudo virt-install --name cvm1 --ram 2048 \
--disk path=/export/cirros-0.3.4.qcow2,format=qcow2 \
--nographics --import --os-variant fedora22 --cpu gate64
Starting install...
ERROR internal error: Unknown CPU model gate64
Domain installation does not appear to have been successful.
[...]
I get a specific error from the CPU driver in the libvirt debug log (but
in the reproducer provided in the Description, I don't see such an
error)
[...]
2016-05-25 14:00:36.267+0000: 27068: error : x86ModelFromCPU:889 : internal error: Unknown CPU model gate64
2016-05-25 14:00:36.267+0000: 27068: debug : cpuDataFree:299 : data=(nil)
2016-05-25 14:00:36.267+0000: 27068: debug : cpuDataFree:299 : data=(nil)
[...]
Which seems to be coming from src/cpu/cpu_x86.c
[...]
878 static struct x86_model *
879 x86ModelFromCPU(const virCPUDef *cpu,
880 const struct x86_map *map,
881 int policy)
882 {
883 struct x86_model *model = NULL;
884 size_t i;
885
886 if (policy == VIR_CPU_FEATURE_REQUIRE) {
887 if ((model = x86ModelFind(map, cpu->model)) == NULL) {
888 virReportError(VIR_ERR_INTERNAL_ERROR,
889 _("Unknown CPU model %s"), cpu->model);
890 goto error;
891 }
[...]
Created attachment 1161612 [details]
libvirtd log with libvirt-1.2.2, where 'gate64' model was successfully translated into something that QEMU can recognize
(In reply to Kashyap Chamarthy from comment #4) > [...] > 2016-05-25 14:00:36.267+0000: 27068: error : x86ModelFromCPU:889 : internal > error: Unknown CPU model gate64 > 2016-05-25 14:00:36.267+0000: 27068: debug : cpuDataFree:299 : data=(nil) > 2016-05-25 14:00:36.267+0000: 27068: debug : cpuDataFree:299 : data=(nil) > [...] This is not very useful. Would you mind attaching a complete log with your virt-install reproducer so that we can check the difference? (In reply to Jiri Denemark from comment #6) > (In reply to Kashyap Chamarthy from comment #4) > > [...] > > 2016-05-25 14:00:36.267+0000: 27068: error : x86ModelFromCPU:889 : internal > > error: Unknown CPU model gate64 > > 2016-05-25 14:00:36.267+0000: 27068: debug : cpuDataFree:299 : data=(nil) > > 2016-05-25 14:00:36.267+0000: 27068: debug : cpuDataFree:299 : data=(nil) > > [...] > > This is not very useful. Would you mind attaching a complete log with your > virt-install reproducer so that we can check the difference? I already did so yesterday, this is this attachment: https://bugzilla.redhat.com/attachment.cgi?id=1161612 libvirtd log with libvirt-1.2.2, where 'gate64' model was successfully translated into something that QEMU can recognize (In reply to Kashyap Chamarthy from comment #7) > > I already did so yesterday, this is this attachment: > > https://bugzilla.redhat.com/attachment.cgi?id=1161612 > > libvirtd log with libvirt-1.2.2, where 'gate64' model was > successfully translated into something that QEMU can recognize No, this log just proves that it used to work with libvirt-1.2.2. But you mentioned that if you try with virt-install, you get an "Unknown CPU model gate64" error from libvirt. And a log showing this error is what I'm interested in. BTW, this bug (in fact a regression) is caused by v1.2.9-31-g445a09b "qemu: Don't compare CPU against host for TCG". (In reply to Jiri Denemark from comment #8) > (In reply to Kashyap Chamarthy from comment #7) > > > > I already did so yesterday, this is this attachment: > > > > https://bugzilla.redhat.com/attachment.cgi?id=1161612 > > > > libvirtd log with libvirt-1.2.2, where 'gate64' model was > > successfully translated into something that QEMU can recognize > > No, this log just proves that it used to work with libvirt-1.2.2. But you > mentioned that if you try with virt-install, you get an "Unknown CPU model > gate64" error from libvirt. And a log showing this error is what I'm > interested in. Duh, right -- I'll blame it on the coffee. I have that log too, forgot to attach. New attachment upcoming... > BTW, this bug (in fact a regression) is caused by v1.2.9-31-g445a09b "qemu: > Don't compare CPU against host for TCG". Thanks for bisecting. I'll go read the details. Created attachment 1161791 [details] libvirt debug log obtained with a reproducer using `virt-install` (refer comment #4) So the virt-install case is different because it uses <domain type='kvm'>. The only question is why it can't find gate64 model. But that's unrelated to this bug. (In reply to Jiri Denemark from comment #11) > So the virt-install case is different because it uses <domain type='kvm'>. Yep, you're right: It's a different code path with <domain type='kvm'>. I just tested the `virt-install` case with the parameter '--virt-type qemu', and indeed, the errors correlate with those from the reproducer using test case guest XML (which uses <domain type='qemu'>) from the bug description. > The only question is why it can't find gate64 model. But that's unrelated to > this bug. This should be fixed as of
commit 7ce711a30eaf882ccd0217b2528362b563b6d670
Refs: v2.2.0-199-g7ce711a
Author: Jiri Denemark <jdenemar>
AuthorDate: Wed Jun 22 15:53:48 2016 +0200
Commit: Jiri Denemark <jdenemar>
CommitDate: Thu Sep 22 15:40:09 2016 +0200
qemu: Update guest CPU def in live XML
Storing the updated CPU definition in the live domain definition saves
us from having to update it over and over when we need it. Not to
mention that we will soon further update the CPU definition according to
QEMU once it's started.
A highly wanted side effect of this patch, libvirt will pass all CPU
features explicitly specified in domain XML to QEMU, even those that are
already included in the host model.
This patch should fix the following bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1207095
https://bugzilla.redhat.com/show_bug.cgi?id=1339680
https://bugzilla.redhat.com/show_bug.cgi?id=1371039
https://bugzilla.redhat.com/show_bug.cgi?id=1373849
https://bugzilla.redhat.com/show_bug.cgi?id=1375524
https://bugzilla.redhat.com/show_bug.cgi?id=1377913
Signed-off-by: Jiri Denemark <jdenemar>
|