Bug 1030789 - qemu crash when hotplug one VF with same boot index 1
qemu crash when hotplug one VF with same boot index 1
Status: CLOSED DUPLICATE of bug 1007759
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt (Show other bugs)
Unspecified Unspecified
medium Severity medium
: rc
: ---
Assigned To: Laine Stump
Virtualization Bugs
Depends On:
Blocks: 1030796
  Show dependency treegraph
Reported: 2013-11-15 01:58 EST by hongming
Modified: 2014-04-02 05:14 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1030796 (view as bug list)
Last Closed: 2014-04-02 05:14:47 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description hongming 2013-11-15 01:58:54 EST
Description of problem:
qemu crash when hotplug one VF with same boot index 1. libvirt should forbid to do this operation.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
# lsmod |grep vfio_pci
vfio_pci               36474  0 
vfio                   20777  2 vfio_iommu_type1,vfio_pci

2. make sure the following parameter of vfio module is "Y".
# cat /sys/module/vfio_iommu_type1/parameters/allow_unsafe_interrupts 

# virsh start r7
Domain r7 started

# virsh dumpxml r7|grep 'boot dev'
    <boot dev='hd'/>

# virsh net-list
 Name                 State      Autostart     Persistent
 default              active     yes           yes
 hostnet              active     no            yes

# virsh net-dumpxml hostnet
  <forward mode='hostdev' managed='yes'>
    <driver name='vfio'/>
    <address type='pci' domain='0x0000' bus='0x0f' slot='0x10' function='0x0'/>
    <address type='pci' domain='0x0000' bus='0x0f' slot='0x10' function='0x2'/>
    <address type='pci' domain='0x0000' bus='0x0f' slot='0x10' function='0x4'/>
    <address type='pci' domain='0x0000' bus='0x0f' slot='0x10' function='0x6'/>

# cat vfpool_bootorder.xml
<interface type='network'>
  <source network='hostnet'/>
  <boot order='1'/>

# virsh attach-device r7 vfpool_bootorder.xml
error: Failed to attach device from vfpool_bootorder.xml
error: Unable to read from monitor: Connection reset by peer

# cat /var/log/libvirt/qemu/r7.log

2013-11-13 08:14:05.171+0000: starting up
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=spice /usr/libexec/qemu-kvm -name r7 -S -machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off -m 1024 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 7662b180-39e4-4e5d-8635-a39458a0621b -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/r7.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=/var/lib/libvirt/images/r7.img,if=none,id=drive-ide0-0-0,format=raw,cache=none -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -spice port=5900,addr=,disable-ticketing,seamless-migration=on -vga qxl -global qxl-vga.ram_size=67108864 -global qxl-vga.vram_size=67108864 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6
Two devices with same boot index 1
2013-11-13 08:15:27.201+0000: shutting down

Actual results:
qemu crash when hotplug one VF with same boot index 1.

Expected results:
libvirt should forbid to do this operation.

Additional info:
Comment 2 Laine Stump 2013-11-27 10:00:16 EST
Note that the problem of qemu exiting in this case (it is an "orderly" shutdown, not a crash) is a longstanding bug in qemu: Bug 771545. Apparently there have been patches posted to fix it, but apparently nothing pushed yet.

In any case, libvirt should be catching this itself, so I'll work up a patch that checks the boot index of existing devices when a new device is added, and fails with an appropriate error before ever getting to the point of calling qemu.
Comment 3 Dave Allan 2013-12-10 14:37:33 EST
It's not clear to me that there can never be a valid use of multiple devices with the same boot index, for example, perhaps a disaster recovery architecture would set two devices as equally valid.  Maybe it's valid, maybe it's not, but I don't think we have enough information at this point to say.
Comment 4 Jiri Denemark 2014-04-02 05:14:47 EDT

*** This bug has been marked as a duplicate of bug 1007759 ***

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