Created attachment 1702035 [details] libvirtd log Description of problem: Attach a scsi disk to the guest, but the disk can not be found in the guest. If use virtio disk, the problem does not happen. Version-Release number of selected component (if applicable): libvirt-6.5.0-1.module+el8.3.0+7323+d54bb644.ppc64le qemu-kvm-5.0.0-2.module+el8.3.0+7379+0505d6ca.ppc64le kernel-4.18.0-221.el8.ppc64le How reproducible: 100% Steps to Reproduce: 1. Prepare a disk xml with scsi bus # cat disk.xml <disk type="file"> <driver name="qemu" type="raw" /> <source file="/tmp/disk2.raw" /> <target bus="scsi" dev="sdb" /> </disk> 2. Start guest 3. Attach the disk to the guest # virsh attach-device vm1 disk.xml Device attached successfully 4. Monitor the event # virsh event --loop --all event 'device-added' for domain vm1: scsi0-0-0-1 5. Check disk in the guest, the second disk does not exist. <in guest>: [root@localhost ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT vda 252:0 0 10G 0 disk \u251c\u2500vda1 252:1 0 4M 0 part \u251c\u2500vda2 252:2 0 1G 0 part /boot \u2514\u2500vda3 252:3 0 9G 0 part \u251c\u2500rhel-root 253:0 0 8G 0 lvm / \u2514\u2500rhel-swap 253:1 0 1G 0 lvm [SWAP] 6. Dumpxml of the guest that the second disk exists. # virsh dumpxml vm1 |grep disk -A7 <disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='none'/> <source file='/tmp/vm1.qcow2' index='1'/> <backingStore/> <target dev='vda' bus='virtio'/> <alias name='virtio-disk0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </disk> <disk type='file' device='disk'> <driver name='qemu' type='raw'/> <source file='/tmp/disk2.raw' index='10'/> <backingStore/> <target dev='sdb' bus='scsi'/> <alias name='scsi0-0-0-1'/> <address type='drive' controller='0' bus='0' target='0' unit='1'/> </disk> Actual results: The attached disk can not be found in the guest. Expected results: The attached disk should be found in the guest. Additional info: See attachment for libvirtd log.
This problem only happens on ppc64le, not x86_64.
It looks good in the libvirtd qmp log: 2020-07-22 07:46:50.354+0000: 231462: info : qemuMonitorIOWrite:433 : QEMU_MONITOR_IO_WRITE: mon=0x7fff20006010 buf={"execute":"blockdev-add","arguments":{"driver":"file","filename":"/tmp/disk2.raw","node-name":"libvirt-10-storage","auto-read-only":true,"discard":"unmap"},"id":"libvirt-41"} 2020-07-22 07:46:50.357+0000: 231462: info : qemuMonitorIOWrite:433 : QEMU_MONITOR_IO_WRITE: mon=0x7fff20006010 buf={"execute":"blockdev-add","arguments":{"node-name":"libvirt-10-format","read-only":false,"driver":"raw","file":"libvirt-10-storage"},"id":"libvirt-42"} 2020-07-22 07:46:50.360+0000: 231462: info : qemuMonitorIOWrite:433 : QEMU_MONITOR_IO_WRITE: mon=0x7fff20006010 buf={"execute":"device_add","arguments":{"driver":"scsi-hd","bus":"scsi0.0","channel":"0","scsi-id":"0","lun":"1","device_id":"drive-scsi0-0-0-1","drive":"libvirt-10-format","id":"scsi0-0-0-1"},"id":"libvirt-43"} Check as following: 1. After hot-plug scsi disk, check the scsi device by `lsscsi` command 2. Check if the cold-plugged scsi disk work well 3. Follow the qmp log, use pure qmp instead of virsh command to hot-plug a scsi disk.
1. After hot-plug scsi disk, 'lsscsi' shows nothing. 2. cold-plugged scsi disk work well. [root@localhost ~]# lsscsi [0:0:0:1] disk QEMU QEMU HARDDISK 2.5+ /dev/sda [root@localhost ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 500M 0 disk vda 252:0 0 10G 0 disk \u251c\u2500vda1 252:1 0 4M 0 part \u251c\u2500vda2 252:2 0 1G 0 part /boot \u2514\u2500vda3 252:3 0 9G 0 part \u251c\u2500rhel-root 253:0 0 8G 0 lvm / \u2514\u2500rhel-swap 253:1 0 1G 0 lvm [SWAP]
Please attach the full VM XML before and also after attach. Especially the <controller> section as it's not obvious to which controller the disk is being plugged into.
(In reply to Dan Zheng from comment #4) > 1. After hot-plug scsi disk, 'lsscsi' shows nothing. > 2. cold-plugged scsi disk work well. > [root@localhost ~]# lsscsi > [0:0:0:1] disk QEMU QEMU HARDDISK 2.5+ /dev/sda > [root@localhost ~]# lsblk > NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT > sda 8:0 0 500M 0 disk > vda 252:0 0 10G 0 disk > \u251c\u2500vda1 252:1 0 4M 0 part > \u251c\u2500vda2 252:2 0 1G 0 part /boot > \u2514\u2500vda3 252:3 0 9G 0 part > \u251c\u2500rhel-root 253:0 0 8G 0 lvm / > \u2514\u2500rhel-swap 253:1 0 1G 0 lvm [SWAP] So it's unlikely the problem of guest kernel driver or qemu device emulation. You can post the VM xml and qemu command line. Start an VM by pure qemu command line with the same scsi controller. Then attach the scsi disk by the qmp of comment3 to see if the bug can be reproduced
I did a little more tests. Case 1: 1.1 Start without any scsi controller (neither ibmvscsi nor virtio-scsi) 1.2 Dumpxml of vm. no scsi controller is automatically created by libvirt. (This may be reasonable) 1.3 Prepare the scsi disk xml and attach to the vm # cat disk.xml <disk type="file"><driver name="qemu" type="raw" /><source file="/tmp/disk2.raw" /><target bus="scsi" dev="sdb" /></disk> # virsh attach-device vm1 disk.xml error: Failed to attach device from disk.xml error: internal error: unable to execute QEMU command 'device_add': Device 'spapr-vscsi' can't go on PCI bus libvirtd.log 2020-07-23 07:46:49.233+0000: 236430: debug : qemuMonitorJSONCheckErrorFull:402 : unable to execute QEMU command {"execute":"device_add","arguments":{"driver":"spapr-vscsi","id":"scsi0","bus":"pci.0","addr":"0x7"},"id":"libvirt-15"}: {"id":"libvirt-15","error":{"class":"GenericError","desc":"Device 'spapr-vscsi' can't go on PCI bus"}} 2020-07-23 07:46:49.233+0000: 236430: error : qemuMonitorJSONCheckErrorFull:416 : internal error: unable to execute QEMU command 'device_add': Device 'spapr-vscsi' can't go on PCI bus This result seems unreasonable and confused. Either libvirt creates a suitable controller (maybe we can't), or report controller missing error, seems acceptable. Case 2: Start vm with virtio-scsi controller -- seems work, see virtio-scsi_vm_xml and virtio-scsi_attach_scsi_disk_vm_xml attached. 2.1. Start vm and dumpxml vm including this controller <controller type='scsi' index='0' model='virtio-scsi'> <alias name='scsi0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> </controller> 2.2. Attach same device above in case 1. 2.3. Dumpxml vm to check the attached disk <disk type='file' device='disk'> <driver name='qemu' type='raw'/> <source file='/tmp/disk2.raw' index='2'/> <backingStore/> <target dev='sdb' bus='scsi'/> <alias name='scsi0-0-0-1'/> <address type='drive' controller='0' bus='0' target='0' unit='1'/> </disk> 2.4. Qemu command line: device spapr-pci-host-bridge,index=4,id=pci.3 -device spapr-pci-host-bridge,index=1,id=pci.4 -device qemu-xhci,id=usb,bus=pci.0,addr=0x2 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x7 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x3 -blockdev {"driver":"file","filename":"/tmp/vm1.qcow2","node-name":"libvirt-1-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"} -blockdev {"node-name":"libvirt-1-format","read-only":false,"cache":{"direct":true,"no-flush":false},"driver":"qcow2","file":"libvirt-1-storage","backing":null} -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=libvirt-1-format,id=virtio-disk0,bootindex=1,write-cache=on 2.5. Some libvirtd log 2020-07-23 08:07:55.084+0000: 272741: info : qemuMonitorIOWrite:433 : QEMU_MONITOR_IO_WRITE: mon=0x7fff90047e20 buf={"execute":"device_add","arguments":{"driver":"scsi-hd","bus":"scsi0.0","channel":"0","scsi-id":"0","lun":"1","device_id":"drive-scsi0-0-0-1","drive":"libvirt-2-format","id":"scsi0-0-0-1"},"id":"libvirt-17"}^M ... 2020-07-23 08:07:55.088+0000: 272741: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"return": [{"name": "type", "type": "string"}, {"name": "scsi0-0-0-1", "type": "child<scsi-hd>"}, {"name": "serial0", "type": "child<spapr-vty>"}, {"name": "balloon0", "type": "child<virtio-balloon-pci>"}, {"name": "virtio-serial0", "type": "child<virtio-serial-pci>"}, {"name": "virtio-disk0", "type": "child<virtio-blk-pci>"}, {"name": "video0", "type": "child<VGA>"}, {"name": "pci.4", "type": "child<spapr-pci-host-bridge>"}, {"name": "pci.3", "type": "child<spapr-pci-host-bridge>"}, {"name": "pci.2", "type": "child<spapr-pci-host-bridge>"}, {"name": "pci.1", "type": "child<spapr-pci-host-bridge>"}, {"name": "channel0", "type": "child<virtserialport>"}, {"name": "net0", "type": "child<virtio-net-pci>"}, {"name": "input1", "type": "child<usb-kbd>"}, {"name": "input0", "type": "child<usb-tablet>"}, {"name": "scsi0", "type": "child<virtio-scsi-pci>"}, {"name": "usb", "type": "child<qemu-xhci>"}], "id": "libvirt-18"}] 2.6. Check within vm and found the attached disk exists in vm as a scsi disk. [root@localhost ~]# lspci 00:01.0 Ethernet controller: Red Hat, Inc. Virtio network device 00:02.0 USB controller: Red Hat, Inc. QEMU XHCI Host Controller (rev 01) 00:03.0 Communication controller: Red Hat, Inc. Virtio console 00:04.0 SCSI storage controller: Red Hat, Inc. Virtio block device 00:05.0 Unclassified device [00ff]: Red Hat, Inc. Virtio memory balloon 00:06.0 VGA compatible controller: Device 1234:1111 (rev 02) 00:07.0 SCSI storage controller: Red Hat, Inc. Virtio SCSI ===> here [root@localhost ~]# lsscsi [0:0:0:1] disk QEMU QEMU HARDDISK 2.5+ /dev/sda ====> here [root@localhost ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 500M 0 disk ====> here vda 252:0 0 10G 0 disk \u251c\u2500vda1 252:1 0 4M 0 part \u251c\u2500vda2 252:2 0 1G 0 part /boot \u2514\u2500vda3 252:3 0 9G 0 part \u251c\u2500rhel-root 253:0 0 8G 0 lvm / \u2514\u2500rhel-swap 253:1 0 1G 0 lvm [SWAP] Case 3: Start vm with ibmvscsi controller - not work, see ibmvscsi_vm_xml and ibmvscsi_attach_scsi_disk_vm_xml attached. 3.1. Start and dumpxml <controller type='scsi' index='0' model='ibmvscsi'> <alias name='scsi0'/> <address type='spapr-vio' reg='0x00002000'/> </controller> 3.2 attach same disk to vm and check qemu command line -device qemu-xhci,id=usb,bus=pci.0,addr=0x2 -device spapr-vscsi,id=scsi0,reg=0x00002000 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x3 -blockdev {"driver":"file","filename":"/tmp/vm1.qcow2","node-name":"libvirt-1-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"} -blockdev {"node-name":"libvirt-1-format","read-only":false,"cache":{"direct":true,"no-flush":false},"driver":"qcow2","file":"libvirt-1-storage","backing":null} -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=libvirt-1-format,id=virtio-disk0,bootindex=1,write-cache=on 3.3 dumpxml vm <disk type='file' device='disk'> <driver name='qemu' type='raw'/> <source file='/tmp/disk2.raw' index='2'/> <backingStore/> <target dev='sdb' bus='scsi'/> <alias name='scsi0-0-0-1'/> <address type='drive' controller='0' bus='0' target='0' unit='1'/> </disk> 3.4 check with vm and lsscsi has zero return. Case 4: coldplug a scsi disk - it works. 4.1 edit vm without any scsi controller and coldplug a scsi disk, and start vm 4.2 dumpxml vm and found ibmvscsi is automatically created. 4.3 qemu cmd: -device spapr-pci-host-bridge,index=2,id=pci.1 ... -device spapr-pci-host-bridge,index=1,id=pci.4 -device qemu-xhci,id=usb,bus=pci.0,addr=0x2 -device spapr-vscsi,id=scsi0,reg=0x00002000 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x3 -blockdev {"driver":"file","filename":"/tmp/vm1.qcow2","node-name":"libvirt-2-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"} -blockdev {"node-name":"libvirt-2-format","read-only":false,"cache":{"direct":true,"no-flush":false},"driver":"qcow2","file":"libvirt-2-storage","backing":null} -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=libvirt-2-format,id=virtio-disk0,bootindex=1,write-cache=on -blockdev {"driver":"file","filename":"/tmp/disk2.raw","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"} -blockdev {"node-name":"libvirt-1-format","read-only":false,"driver":"raw","file":"libvirt-1-storage"} -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,device_id=drive-scsi0-0-0-1,drive=libvirt-1-format,id=scsi0-0-0-1 -netdev tap,fd=36,id=hostnet0,vhost=on,vhostfd=37 ...
Created attachment 1702190 [details] guest xml with ibmvscsi controller before attach
Created attachment 1702191 [details] guest xml with ibmvscsi controller after attach
Created attachment 1702193 [details] guest xml with virtio-scsi controller before attach
Created attachment 1702194 [details] guest xml with virtio-scsi controller after attach
(In reply to Dan Zheng from comment #7) > I did a little more tests. > > Case 1: > 1.1 Start without any scsi controller (neither ibmvscsi nor virtio-scsi) > 1.2 Dumpxml of vm. > no scsi controller is automatically created by libvirt. (This may be > reasonable) > 1.3 Prepare the scsi disk xml and attach to the vm > # cat disk.xml > <disk type="file"><driver name="qemu" type="raw" /><source > file="/tmp/disk2.raw" /><target bus="scsi" dev="sdb" /></disk> > > # virsh attach-device vm1 disk.xml > error: Failed to attach device from disk.xml > error: internal error: unable to execute QEMU command 'device_add': Device > 'spapr-vscsi' can't go on PCI bus > > libvirtd.log > 2020-07-23 07:46:49.233+0000: 236430: debug : > qemuMonitorJSONCheckErrorFull:402 : unable to execute QEMU command > {"execute":"device_add","arguments":{"driver":"spapr-vscsi","id":"scsi0", > "bus":"pci.0","addr":"0x7"},"id":"libvirt-15"}: > {"id":"libvirt-15","error":{"class":"GenericError","desc":"Device > 'spapr-vscsi' can't go on PCI bus"}} > 2020-07-23 07:46:49.233+0000: 236430: error : > qemuMonitorJSONCheckErrorFull:416 : internal error: unable to execute QEMU > command 'device_add': Device 'spapr-vscsi' can't go on PCI bus > > > This result seems unreasonable and confused. Either libvirt creates a > suitable controller (maybe we can't), or report controller missing error, > seems acceptable. > > > Case 2: Start vm with virtio-scsi controller -- seems work, see > virtio-scsi_vm_xml and virtio-scsi_attach_scsi_disk_vm_xml attached. > 2.1. Start vm and dumpxml vm including this controller > <controller type='scsi' index='0' model='virtio-scsi'> > <alias name='scsi0'/> > <address type='pci' domain='0x0000' bus='0x00' slot='0x07' > function='0x0'/> > </controller> > > 2.2. Attach same device above in case 1. > 2.3. Dumpxml vm to check the attached disk > <disk type='file' device='disk'> > <driver name='qemu' type='raw'/> > <source file='/tmp/disk2.raw' index='2'/> > <backingStore/> > <target dev='sdb' bus='scsi'/> > <alias name='scsi0-0-0-1'/> > <address type='drive' controller='0' bus='0' target='0' unit='1'/> > > </disk> > 2.4. Qemu command line: > device spapr-pci-host-bridge,index=4,id=pci.3 -device > spapr-pci-host-bridge,index=1,id=pci.4 -device > qemu-xhci,id=usb,bus=pci.0,addr=0x2 -device > virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x7 -device > virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x3 -blockdev > {"driver":"file","filename":"/tmp/vm1.qcow2","node-name":"libvirt-1-storage", > "cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard": > "unmap"} -blockdev > {"node-name":"libvirt-1-format","read-only":false,"cache":{"direct":true,"no- > flush":false},"driver":"qcow2","file":"libvirt-1-storage","backing":null} > -device > virtio-blk-pci,bus=pci.0,addr=0x4,drive=libvirt-1-format,id=virtio-disk0, > bootindex=1,write-cache=on > > 2.5. Some libvirtd log > 2020-07-23 08:07:55.084+0000: 272741: info : qemuMonitorIOWrite:433 : > QEMU_MONITOR_IO_WRITE: mon=0x7fff90047e20 > buf={"execute":"device_add","arguments":{"driver":"scsi-hd","bus":"scsi0.0", > "channel":"0","scsi-id":"0","lun":"1","device_id":"drive-scsi0-0-0-1", > "drive":"libvirt-2-format","id":"scsi0-0-0-1"},"id":"libvirt-17"}^M > ... > 2020-07-23 08:07:55.088+0000: 272741: debug : > qemuMonitorJSONIOProcessLine:220 : Line [{"return": [{"name": "type", > "type": "string"}, {"name": "scsi0-0-0-1", "type": "child<scsi-hd>"}, > {"name": "serial0", "type": "child<spapr-vty>"}, {"name": "balloon0", > "type": "child<virtio-balloon-pci>"}, {"name": "virtio-serial0", "type": > "child<virtio-serial-pci>"}, {"name": "virtio-disk0", "type": > "child<virtio-blk-pci>"}, {"name": "video0", "type": "child<VGA>"}, {"name": > "pci.4", "type": "child<spapr-pci-host-bridge>"}, {"name": "pci.3", "type": > "child<spapr-pci-host-bridge>"}, {"name": "pci.2", "type": > "child<spapr-pci-host-bridge>"}, {"name": "pci.1", "type": > "child<spapr-pci-host-bridge>"}, {"name": "channel0", "type": > "child<virtserialport>"}, {"name": "net0", "type": "child<virtio-net-pci>"}, > {"name": "input1", "type": "child<usb-kbd>"}, {"name": "input0", "type": > "child<usb-tablet>"}, {"name": "scsi0", "type": "child<virtio-scsi-pci>"}, > {"name": "usb", "type": "child<qemu-xhci>"}], "id": "libvirt-18"}] > > 2.6. Check within vm and found the attached disk exists in vm as a scsi disk. > [root@localhost ~]# lspci > 00:01.0 Ethernet controller: Red Hat, Inc. Virtio network device > 00:02.0 USB controller: Red Hat, Inc. QEMU XHCI Host Controller (rev 01) > 00:03.0 Communication controller: Red Hat, Inc. Virtio console > 00:04.0 SCSI storage controller: Red Hat, Inc. Virtio block device > 00:05.0 Unclassified device [00ff]: Red Hat, Inc. Virtio memory balloon > 00:06.0 VGA compatible controller: Device 1234:1111 (rev 02) > 00:07.0 SCSI storage controller: Red Hat, Inc. Virtio SCSI ===> here > [root@localhost ~]# lsscsi > [0:0:0:1] disk QEMU QEMU HARDDISK 2.5+ /dev/sda ====> here > [root@localhost ~]# lsblk > NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT > sda 8:0 0 500M 0 disk ====> here > vda 252:0 0 10G 0 disk > \u251c\u2500vda1 252:1 0 4M 0 part > \u251c\u2500vda2 252:2 0 1G 0 part /boot > \u2514\u2500vda3 252:3 0 9G 0 part > \u251c\u2500rhel-root 253:0 0 8G 0 lvm / > \u2514\u2500rhel-swap 253:1 0 1G 0 lvm [SWAP] > > > Case 3: Start vm with ibmvscsi controller - not work, see ibmvscsi_vm_xml > and ibmvscsi_attach_scsi_disk_vm_xml attached. > 3.1. Start and dumpxml > <controller type='scsi' index='0' model='ibmvscsi'> > <alias name='scsi0'/> > <address type='spapr-vio' reg='0x00002000'/> > </controller> > 3.2 attach same disk to vm and check qemu command line > -device qemu-xhci,id=usb,bus=pci.0,addr=0x2 -device > spapr-vscsi,id=scsi0,reg=0x00002000 -device > virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x3 -blockdev > {"driver":"file","filename":"/tmp/vm1.qcow2","node-name":"libvirt-1-storage", > "cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard": > "unmap"} -blockdev > {"node-name":"libvirt-1-format","read-only":false,"cache":{"direct":true,"no- > flush":false},"driver":"qcow2","file":"libvirt-1-storage","backing":null} > -device > virtio-blk-pci,bus=pci.0,addr=0x4,drive=libvirt-1-format,id=virtio-disk0, > bootindex=1,write-cache=on > 3.3 dumpxml vm > <disk type='file' device='disk'> > <driver name='qemu' type='raw'/> > <source file='/tmp/disk2.raw' index='2'/> > <backingStore/> > <target dev='sdb' bus='scsi'/> > <alias name='scsi0-0-0-1'/> > <address type='drive' controller='0' bus='0' target='0' unit='1'/> > </disk> > 3.4 check with vm and lsscsi has zero return. > > > > Case 4: coldplug a scsi disk - it works. > 4.1 edit vm without any scsi controller and coldplug a scsi disk, and start > vm > 4.2 dumpxml vm and found ibmvscsi is automatically created. > > 4.3 qemu cmd: -device spapr-pci-host-bridge,index=2,id=pci.1 ... -device > spapr-pci-host-bridge,index=1,id=pci.4 -device > qemu-xhci,id=usb,bus=pci.0,addr=0x2 -device > spapr-vscsi,id=scsi0,reg=0x00002000 -device > virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x3 -blockdev > {"driver":"file","filename":"/tmp/vm1.qcow2","node-name":"libvirt-2-storage", > "cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard": > "unmap"} -blockdev > {"node-name":"libvirt-2-format","read-only":false,"cache":{"direct":true,"no- > flush":false},"driver":"qcow2","file":"libvirt-2-storage","backing":null} > -device > virtio-blk-pci,bus=pci.0,addr=0x4,drive=libvirt-2-format,id=virtio-disk0, > bootindex=1,write-cache=on -blockdev > {"driver":"file","filename":"/tmp/disk2.raw","node-name":"libvirt-1-storage", > "auto-read-only":true,"discard":"unmap"} -blockdev > {"node-name":"libvirt-1-format","read-only":false,"driver":"raw","file": > "libvirt-1-storage"} -device > scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,device_id=drive-scsi0-0-0-1, > drive=libvirt-1-format,id=scsi0-0-0-1 -netdev > tap,fd=36,id=hostnet0,vhost=on,vhostfd=37 ... I think that is more clear here: the bug is caused by spapr-vscsi scsi controller. So it cannnot be reproudced on x86_64: no spapr-vscsi scsi controller on the arch. To confirm that conclusion, you can turn to qemu QE for help, then reproduce it by pure qemu cmdline and qmp. If reproduced, change the component to qemu.
yes, I have set the hardware to 'ppc64le' already.
spapr-vscsi don't support hot plug, either the controller or the hard disks. Please refer to https://bugzilla.redhat.com/show_bug.cgi?id=1192355
Right, if you want to hotplug scsi disks you'll need to add a virtio-scsi controller.
Ngu, David, thanks for the information. Then I will close it. *** This bug has been marked as a duplicate of bug 1192355 ***