Red Hat Bugzilla – Bug 1016775
libvirt generates conflicting pci address when adding qxl device
Last modified: 2014-05-08 06:09:08 EDT
Created attachment 809411 [details]
Description of problem:
I created a guest with "--graphics none" and then later attempted to add a graphical console to the machine using virt-manager. This failed because the pci address was already being used by the network card in the xml description. I will attach the guest xml and the virt-manager log file for investigation. Here is an example virt-install command with "--graphics none"
virt-install --name nest2 --ram 2048 --disk /guests/nest2.img,size=10,bus=scsi --controller=scsi,model=virtio-scsi --accelerate --location http://download.fedoraproject.org/pub/fedora/linux/development/20/x86_64/os/ --extra-args "ks=http://192.168.133.1:8000/kickstart.ks console=hvc0 cmdline" --graphics none --os-variant fedora20
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Create a guest with virt-install using "--graphics none"
2. Finish install and then attempt to add graphics using virt-manager UI.
virt-manager fails with:
details=Error adding device: XML error: Attempted double use of PCI slot 0000:00:02.0 (may need "multifunction='on'" for device on function 0)
This was a nested virt setup F19(L0) F20(L1) F20(L2). Problem observed when running virt-manager on L1 guest and attempting to add graphics to L2 guest.
Created attachment 809412 [details]
Root issue seems to be libvirt generating colliding PCI addresses (virt-manager/virt-install never fill in explict <address> topology)
Take this XML:
<type arch='x86_64' machine='pc-i440fx-1.6'>hvm</type>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
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:
Author: Ján Tomko <firstname.lastname@example.org>
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
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 v188.8.131.52-11-gbe7636c
libvirt-184.108.40.206-1.fc20 has been submitted as an update for Fedora 20.
* 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-220.127.116.11-1.fc20'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
libvirt-18.104.22.168-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.