Bug 920972

(In reply to comment #0)
> Description of problem:
> Add a scsi controller will cause guest can not boot up, and it will also
> cause virsh destroy guest very slow.
> 
> Version-Release number of selected component (if applicable):
> kernel-3.7.0-0.36.el7.x86_64
> libvirt-1.0.3-1.el7.x86_64
> qemu-kvm-1.4.0-1.el7.x86_64
> 
> How reproducible:
> 100%
> 
> Steps to Reproduce:
> 1. prepare a healthy guest with os, and add following xml to guest:
>     <controller type='scsi' index='0'>
>       <address type='pci' domain='0x0000' bus='0x00' slot='0x07'
> function='0x0'/>
>     </controller>
> 
> 2. # virsh start guest
> 
> 3. # virt-viewer guest
> guest will be blank screen and hang there can not boot up.
>   

I believe it's qemu problem if it's problem. But can you confirm it? Though it's
a bit out of your work, but better to find out why it hangs (e.g. any soft locks of guest kernel?).

(In reply to comment #2)
> (In reply to comment #0)
> 
> I believe it's qemu problem if it's problem. But can you confirm it? Though
> it's
> a bit out of your work, but better to find out why it hangs (e.g. any soft
> locks of guest kernel?).

Some times it will hang at: loading initial ramdisk...., and some times it will black screen in limine.

BTW, I found this problem because I want to add a scsi disk to the guest, which will add scsi controller automatically, and only delete the scsi disk will not work.

Reassign to qemu.

Hi all,

   I tried to test by hand with qemu-kvm command line, but did not hit this issue from qemu, both guest and host work well according to my testing.
BTW, i also tried to hot-plug/unplug the SCSI disk to guest which is ok.

host info:
kernel-3.9.0-0.rc4.45.el7.x86_64
qemu-kvm-1.4.0-1.el7.x86_64
seabios-1.7.2-0.2.gita810e4e7.el7.x86_64
guest info:
kernel-3.9.0-0.rc4.45.el7.x86_64

Steps:
1.boot a guest under pc-i440fx-1.4 machine type.
# /usr/libexec/qemu-kvm -S -M pc-i440fx-1.4 -cpu SandyBridge -enable-kvm -m 4096 -smp 2,sockets=2,cores=1,threads=1 -no-kvm-pit-reinjection -usb -device usb-tablet,id=input0 -device usb-mouse,id=mouse -name sluo-test -uuid ed09fa10-6ffe-4811-a42f-0294afcb5a42 -rtc base=localtime,clock=host,driftfix=slew -device virtio-serial-pci,id=virtio-serial0,max_ports=16,vectors=0,bus=pci.0,addr=0x3 -chardev socket,id=channel1,path=/tmp/helloworld1,server,nowait -device virtserialport,chardev=channel1,name=com.redhat.rhevm.vdsm,bus=virtio-serial0.0,id=port1 -chardev socket,id=channel2,path=/tmp/helloworld2,server,nowait -device virtserialport,chardev=channel2,name=com.redhat.rhevm.vdsm,bus=virtio-serial0.0,id=port2 -drive file=/home/RHEL-Server-7.0-64-scsi.qcow2,if=none,id=drive-system-disk,format=qcow2,cache=none,aio=native,werror=stop,rerror=stop,serial=QEMU-DISK1 -device virtio-scsi-pci,bus=pci.0,addr=0x4,id=scsi0 -device scsi-hd,bus=scsi0.0,drive=drive-system-disk,id=system-disk,bootindex=1 -netdev tap,id=hostnet0,vhost=off,script=/etc/qemu-ifup -device virtio-net-pci,netdev=hostnet0,id=virtio-net-pci0,mac=08:2e:5f:0a:0d:b1,bus=pci.0,addr=0x5,bootindex=2 -device virtio-balloon-pci,id=ballooning,bus=pci.0,addr=0x6 -device usb-ehci,id=ehci0 -drive file=/home/my-usb-storage.qcow2,if=none,id=drive-usb-0-1,media=disk,format=qcow2,cache=none,aio=native -device usb-storage,drive=drive-usb-0-1,id=usb-0-1,removable=on -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 -serial unix:/tmp/ttyS0,server,nowait -qmp tcp:0:4444,server,nowait -k en-us -boot menu=on -vnc :1 -spice disable-ticketing,port=5931 -monitor stdio
2.hot plug a scsi controller after guest boot up.
(qemu) device_add virtio-scsi-pci,id=scsi1,vectors=0,bus=pci.0,addr=0x8
3.check the HMP and guest dmesg.
(qemu) info qtree
guest] dmesg
4.reboot guest via 'reboot' command in guest.
guest] reboot
5.hot unplug the scsi controller after guest reboot ok.
(qemu) device_del scsi1
6.reboot guest again.
guest] reboot

Result:
after step 1, guest boot up successfully.
after step 2, hot plug a scsi controller correctly.
after step 3, the qtree/dmesg info display correctly.
(qemu) info qtree
...
  dev: i440FX-pcihost, id ""
    irq 0
    bus: pci.0
      type PCI
      dev: virtio-scsi-pci, id "scsi1"
        ioeventfd = on
        vectors = 0
        indirect_desc = on
        event_idx = on
        num_queues = 1
        max_sectors = 65535
        cmd_per_lun = 128
        hotplug = on
        param_change = on
        addr = 08.0
        romfile = <null>
        rombar = 1
        multifunction = off
        command_serr_enable = on
        class SCSI controller, addr 00:08.0, pci id 1af4:1004 (sub 1af4:0008)
        bar 0: i/o at 0x1000 [0x103f]
        bus: scsi1.0
          type SCSI
...

[  126.420189] pci 0000:00:08.0: [1af4:1004] type 00 class 0x010000
[  126.420448] pci 0000:00:08.0: reg 10: [io  0x0000-0x003f]
[  126.421225] pci 0000:00:08.0: BAR 0: assigned [io  0x1000-0x103f]
[  126.421277] pci 0000:00:00.0: no hotplug settings from platform
[  126.421280] pci 0000:00:00.0: using default PCI settings
[  126.421333] pci 0000:00:01.0: no hotplug settings from platform
[  126.421335] pci 0000:00:01.0: using default PCI settings
[  126.421386] ata_piix 0000:00:01.1: no hotplug settings from platform
[  126.421389] ata_piix 0000:00:01.1: using default PCI settings
[  126.421439] uhci_hcd 0000:00:01.2: no hotplug settings from platform
[  126.421442] uhci_hcd 0000:00:01.2: using default PCI settings
[  126.421493] piix4_smbus 0000:00:01.3: no hotplug settings from platform
[  126.421495] piix4_smbus 0000:00:01.3: using default PCI settings
[  126.421546] cirrus 0000:00:02.0: no hotplug settings from platform
[  126.421548] cirrus 0000:00:02.0: using default PCI settings
[  126.421599] virtio-pci 0000:00:03.0: no hotplug settings from platform
[  126.421602] virtio-pci 0000:00:03.0: using default PCI settings
[  126.421652] virtio-pci 0000:00:04.0: no hotplug settings from platform
[  126.421655] virtio-pci 0000:00:04.0: using default PCI settings
[  126.421705] virtio-pci 0000:00:05.0: no hotplug settings from platform
[  126.421708] virtio-pci 0000:00:05.0: using default PCI settings
[  126.421758] virtio-pci 0000:00:06.0: no hotplug settings from platform
[  126.421760] virtio-pci 0000:00:06.0: using default PCI settings
[  126.421811] ehci-pci 0000:00:07.0: no hotplug settings from platform
[  126.421814] ehci-pci 0000:00:07.0: using default PCI settings
[  126.421865] pci 0000:00:08.0: no hotplug settings from platform
[  126.421867] pci 0000:00:08.0: using default PCI settings
[  126.422360] virtio-pci 0000:00:08.0: enabling device (0000 -> 0001)
[  126.428328] virtio-pci 0000:00:08.0: setting latency timer to 64
[  126.429331] scsi4 : Virtio SCSI HBA
after step 4, reboot guest successfully.
after step 5, hot unplug the scsi controller correctly.
after step 6, reboot guest successfuly, both guest and host work well.

(In reply to comment #5)
> Hi all,
> 
>    I tried to test by hand with qemu-kvm command line, but did not hit this
> issue from qemu, both guest and host work well according to my testing.
> BTW, i also tried to hot-plug/unplug the SCSI disk to guest which is ok.
> 
I also tried that append scsi controller '-device virtio-scsi-pci,id=scsi1,vectors=0,bus=pci.0,addr=0x8' to qemu-kvm command line to start the guest, it can start successfully, and then i hot-remove the scsi controller and reboot guest which can reboot sucucessfully.

Maybe this promblem is that if didn't specify a model for the SCSI controller in xml, it uses the defalt which is 'lsi', but our qemu-kvm has disable it(bug 903918#3).

Best Regards.
sluo

Add the following xml to guest.xml in libvirt:
    <controller type='scsi' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
    </controller>
that means <type> as "scsi", <model> using "default", then start the guest, guest can not boot up. I have got the libvirtd.log when guest start, please see the next comment.

And that xml translate to qemu-cli is "-device lsi,id=scsi0,bus=pci.0,addr=0x7". That means libvirt use 'lsi' as default <model> for a scsi controller which is not conform to to qemu-kvm's intent(Bug 903918 comment #3).

And I think libvirt should do some change after qemu-kvm disable the 'lsi'.

Created attachment 730650 [details]
can not boot up guest libvirtd log

This is because the default SCSI controller model, "lsilogic", has not been disabled yet.  That controller is buggy.

The fix will be to disable the default SCSI controller model and is tracked by a separate bug (https://bugzilla.redhat.com/show_bug.cgi?id=903918), so I'm closing as WONTFIX.