It doesn't make much sense to pass a block partition as scsi-block device. The host happens to accept SG ioctl on both a sdX block device or on its partition, which can be told by running sg_readcap(8).

A "fix", if any, would be detect this case in QEMU and refuse to start the guest. But I'm not sure if that is doable, though.

Is this reproducible with libvirt?

(In reply to Fam Zheng from comment #2)
> It doesn't make much sense to pass a block partition as scsi-block device.
> The host happens to accept SG ioctl on both a sdX block device or on its
> partition, which can be told by running sg_readcap(8).
> 
> A "fix", if any, would be detect this case in QEMU and refuse to start the
> guest. But I'm not sure if that is doable, though.
> 
> Is this reproducible with libvirt?

As you said that libvirt prevent to create VM disk from a scsi partition; libvirt report error like:

internal error: process exited while connecting to monitor: 2016-04-14T06:53:34.599155Z qemu-kvm: -device scsi-block,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1: INQUIRY failed

see our xml file in attachment.

Created attachment 1147051 [details]
VM create xml

I'm confused. Why does the command line in comment 0 run, but not the one in comment 3? What is the difference? Can you post the full command line executed by libvirt?

(In reply to Fam Zheng from comment #5)
> I'm confused. Why does the command line in comment 0 run, but not the one in
> comment 3? What is the difference? Can you post the full command line
> executed by libvirt?

Commands as bellow:
/usr/libexec/qemu-kvm -name rhel7.1 -S \
-machine pc-i440fx-rhel7.2.0,accel=kvm,usb=off,vmport=off \
-cpu SandyBridge -m 1024 -realtime mlock=off \
-smp 1,sockets=1,cores=1,threads=1 \
-uuid da3ad4b0-71ae-469a-b912-33f2c8c3658e -no-user-config -nodefaults \
-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-rhel7.1/monitor.sock,server,nowait \
-mon chardev=charmonitor,id=monitor,mode=control \
-rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet \
-no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 \
-boot strict=on \
-device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x6.0x7 \
-device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x6 \
-device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x6.0x1 \ -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x6.0x2 \
-device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x5 \
-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x7 \
-drive file=/dev/sdb1,if=none,id=drive-scsi0-0-0-0,format=raw,cache=none -device scsi-block,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 \
-netdev tap,fd=23,id=hostnet0 \
-device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:99:8c:cd,bus=pci.0,addr=0x3 \
-chardev pty,id=charserial0 \
-device isa-serial,chardev=charserial0,id=serial0 \
-chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-rhel7.1/org.qemu.guest_agent.0,server,nowait \
-device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \
-chardev spicevmc,id=charchannel1,name=vdagent \
-device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=com.redhat.spice.0 \
-device usb-tablet,id=input0 -spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on \
-device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vgamem_mb=16,bus=pci.0,addr=0x2 \
-device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 \
-chardev spicevmc,id=charredir0,name=usbredir \
-device usb-redir,chardev=charredir0,id=redir0 \
-chardev spicevmc,id=charredir1,name=usbredir \
-device usb-redir,chardev=charredir1,id=redir1 \
-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 \
-msg timestamp=on

It's clear enough that this is not a qemu-kvm problem.