Bug 1016775
Summary: | libvirt generates conflicting pci address when adding qxl device | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Dusty Mabe <dustymabe> | ||||||
Component: | libvirt | Assignee: | Libvirt Maintainers <libvirt-maint> | ||||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
Severity: | unspecified | Docs Contact: | |||||||
Priority: | unspecified | ||||||||
Version: | 20 | CC: | berrange, codong, crobinso, dallan, dyuan, itamar, jforbes, jtomko, laine, lcui, libvirt-maint, mfuruta, sstar, veillard, virt-maint, zpeng | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | x86_64 | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | libvirt-1.1.3.5-1.fc20 | Doc Type: | Bug Fix | ||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2014-05-08 10:09:08 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: | |||||||||
Attachments: |
|
Description
Dusty Mabe
2013-10-08 16:32:50 UTC
Created attachment 809412 [details]
guest xml
Root issue seems to be libvirt generating colliding PCI addresses (virt-manager/virt-install never fill in explict <address> topology) Take this XML: <domain type='kvm'> <name>qxl-collide-test</name> <uuid>22ed806e-910b-40ae-8882-61dcaf9f9d04</uuid> <memory unit='KiB'>2097152</memory> <currentMemory unit='KiB'>2097152</currentMemory> <vcpu placement='static'>1</vcpu> <os> <type arch='x86_64' machine='pc-i440fx-1.6'>hvm</type> <boot dev='hd'/> </os> <devices> <emulator>/usr/bin/qemu-kvm</emulator> <interface type='network'> <mac address='52:54:00:e4:8e:a5'/> <source network='default'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </interface> <video> <model type="qxl"/> </video> </devices> </domain> And define it: $ sudo virsh define t.xml error: Failed to define domain from t.xml error: XML error: Attempted double use of PCI slot 0000:00:02.0 (may need "multifunction='on'" for device on function 0) libvirt requires that the primary video device on an i440fx system be in slot 2 of bus 0 (00:02.0). I don't remember the exact reason for this, but I think it has something to do with some piece of software being hardcoded for that address. Even when no video device is present in the configuration, libvirt is *supposed* to reserve 00:02.0 in case a video device is added in the future. Even if 00:02.0 was manually assigned to a non-video device (rather than auto-assigned), the error message when the video is later added is incorrect - it should report PCI address 0:0:2.0 is in use, QEMU needs it for primary video This has been fixed upstream by: commit ec128e69f1e8416ae20fb86ac32970499bc05e00 Author: Ján Tomko <jtomko> CommitDate: 2014-01-06 09:31:32 +0100 Fix explicit usage of default video PCI slots Do not leave the PCI address of the primary video card set to the legacy default (0000:00:02.0) if we're doing two-pass allocation. Since QEMU 1.6 (QEMU_CAPS_VIDEO_PRIMARY) we allow the primary video card to be on other slots than 0000:00:02.0 (as we use -device instead of -vga). However we fail to assign it an address if: * another device explicitly uses 0000:00:02.0 and * the primary video device has no address specified On the first pass, we have set the address to default, then checked if it's available, leaving it set even if it wasn't. This address got picked up by the second pass, resulting in a conflict: XML error: Attempted double use of PCI slot 0000:00:02.0 (may need "multifunction='on'" for device on function 0) Also fix the test that was supposed to catch this. git describe: v1.2.0-212-gec128e6 contains: v1.2.1-rc1~39 And I've pushed it on the maint branch as v1.1.3.4-11-gbe7636c libvirt-1.1.3.5-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/libvirt-1.1.3.5-1.fc20 Package libvirt-1.1.3.5-1.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing libvirt-1.1.3.5-1.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-6018/libvirt-1.1.3.5-1.fc20 then log in and leave karma (feedback). libvirt-1.1.3.5-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report. |