Bug 1016775 - libvirt generates conflicting pci address when adding qxl device
libvirt generates conflicting pci address when adding qxl device
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: libvirt (Show other bugs)
20
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Libvirt Maintainers
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-08 12:32 EDT by Dusty Mabe
Modified: 2014-05-08 06:09 EDT (History)
16 users (show)

See Also:
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 06:09:08 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
virt-manager.log (3.84 KB, text/plain)
2013-10-08 12:32 EDT, Dusty Mabe
no flags Details
guest xml (3.88 KB, text/plain)
2013-10-08 12:34 EDT, Dusty Mabe
no flags Details

  None (edit)
Description Dusty Mabe 2013-10-08 12:32:50 EDT
Created attachment 809411 [details]
virt-manager.log

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):

F20 alpha:
virt-manager-0.10.0-4.git79196cdf.fc20.noarch
libvirt-client-1.1.3-2.fc20.x86_64
kernel-3.11.3-301.fc20.x86_64
qemu-kvm-1.6.0-9.fc20.x86_64



How reproducible:
Always


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.
3.

Actual results:
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)


Expected results:
Successful add. 


Additional info:
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.
Comment 1 Dusty Mabe 2013-10-08 12:34:03 EDT
Created attachment 809412 [details]
guest xml
Comment 2 Cole Robinson 2013-10-08 12:39:26 EDT
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)
Comment 3 Laine Stump 2013-10-09 05:29:59 EDT
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
Comment 4 Ján Tomko 2014-04-10 03:38:47 EDT
This has been fixed upstream by:
commit ec128e69f1e8416ae20fb86ac32970499bc05e00
Author:     Ján Tomko <jtomko@redhat.com>
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
Comment 5 Fedora Update System 2014-05-03 18:56:45 EDT
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
Comment 6 Fedora Update System 2014-05-05 23:36:47 EDT
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).
Comment 7 Fedora Update System 2014-05-08 06:09:08 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.