search for: sg_inq

>From the fedora 19 host: [root@fedora ~]# sg_inq /dev/sdc standard INQUIRY: PQual=0 Device_type=0 RMB=0 version=0x05 [SPC-3] [AERC=0] [TrmTsk=0] NormACA=0 HiSUP=0 Resp_data_format=0 SCCS=1 ACC=0 TPGS=1 3PC=0 Protect=0 [BQue=0] EncServ=0 MultiP=0 [MChngr=0] [ACKREQQ=0] Addr16=0 [RelAdr=0] WBus16=1 Sync=1 Linked=0 [Tr...

On Wed, 2013-08-21 at 11:09 +0200, Paolo Bonzini wrote: > Il 21/08/2013 04:11, Timon Wang ha scritto: > > From the fedora 19 host: > > [root@fedora ~]# sg_inq /dev/sdc > > standard INQUIRY: > > PQual=0 Device_type=0 RMB=0 version=0x05 [SPC-3] > > [AERC=0] [TrmTsk=0] NormACA=0 HiSUP=0 Resp_data_format=0 > > SCCS=1 ACC=0 TPGS=1 3PC=0 Protect=0 [BQue=0] > > EncServ=0 MultiP=0 [MChngr=0] [ACKREQQ=0] Addr...

Thanks Nicholas. I found that scsicmd can't pass all the scsi3_test but the result of sg_inq is the same as it in the host. I am absolutely confused about this situation. Am I missed some information about it? On Wed, Aug 21, 2013 at 5:40 PM, Nicholas A. Bellinger <nab@linux-iscsi.org> wrote: > On Wed, 2013-08-21 at 11:09 +0200, Paolo Bonzini wrote: >> Il 21/08/2013 04:11,...

...onzini@redhat.com> wrote: > Il 20/08/2013 12:42, Timon Wang ha scritto: >> [root@localhost /]# ls -l /dev/VM-IMAGES-BACKUP-DO-NOT-REMOVE/q_disk >> lrwxrwxrwx. 1 root root 8 8月 20 17:38 >> /dev/VM-IMAGES-BACKUP-DO-NOT-REMOVE/q_disk -> ../dm-13 >> [root@localhost /]# sg_inq /dev/VM-IMAGES-BACKUP-DO-NOT-REMOVE/q_disk >> standard INQUIRY: >> PQual=0 Device_type=0 RMB=0 version=0x05 [SPC-3] >> [AERC=0] [TrmTsk=0] NormACA=0 HiSUP=0 Resp_data_format=0 >> SCCS=1 ACC=0 TPGS=1 3PC=0 Protect=0 [BQue=0] >> EncServ=0 MultiP=0...

Il 21/08/2013 04:11, Timon Wang ha scritto: > From the fedora 19 host: > [root@fedora ~]# sg_inq /dev/sdc > standard INQUIRY: > PQual=0 Device_type=0 RMB=0 version=0x05 [SPC-3] > [AERC=0] [TrmTsk=0] NormACA=0 HiSUP=0 Resp_data_format=0 > SCCS=1 ACC=0 TPGS=1 3PC=0 Protect=0 [BQue=0] > EncServ=0 MultiP=0 [MChngr=0] [ACKREQQ=0] Addr16=0 > [RelAdr=0] W...

[root@localhost /]# ls -l /dev/VM-IMAGES-BACKUP-DO-NOT-REMOVE/q_disk lrwxrwxrwx. 1 root root 8 8月 20 17:38 /dev/VM-IMAGES-BACKUP-DO-NOT-REMOVE/q_disk -> ../dm-13 [root@localhost /]# sg_inq /dev/VM-IMAGES-BACKUP-DO-NOT-REMOVE/q_disk standard INQUIRY: PQual=0 Device_type=0 RMB=0 version=0x05 [SPC-3] [AERC=0] [TrmTsk=0] NormACA=0 HiSUP=0 Resp_data_format=0 SCCS=1 ACC=0 TPGS=1 3PC=0 Protect=0 [BQue=0] EncServ=0 MultiP=0 [MChngr=0] [ACKREQQ=0] Addr16=0 [RelAdr=0...

Il 22/08/2013 09:46, Timon Wang ha scritto: > Thanks Nicholas. > > I found that scsicmd can't pass all the scsi3_test but the result of > sg_inq is the same as it in the host. > > I am absolutely confused about this situation. Am I missed some > information about it? I am also confused. You need to understand the limitations that the clustering software is putting. Can you also try using the megaraid sas controller ("lsisa...

...=drive-scsi0-0-0-6,format=raw,serial=8aad44f9e53e05868e81,cache=none -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=6,drive=drive-scsi0-0-0-6,id=scsi0-0-0-6,wwn=44f9e53e05868e81 I am seeing an error on device /dev/sdg on the guest when I query SCSI page 0x83 for that device. [root@node1 ~]# sg_inq -p 0x83 /dev/sdg VPD INQUIRY: Device Identification page Designation descriptor number 1, descriptor length: 24 designator_type: vendor specific [0x0], code_set: ASCII associated with the addressed logical unit vendor specific: 22b0daf285d88050fd39 Designation descriptor number 2...

Hi Christoph, 2017-01-04 6:25 GMT+01:00 Christoph Hellwig <hch at lst.de>: > Most users of BLOCK_PC requests allocate the sense buffer on the stack, > so to avoid DMA to the stack copy them to a field in the heap allocated > virtblk_req structure. Without that any attempt at SCSI passthrough I/O, > including the SG_IO ioctl from userspace will crash the kernel. Note that >

Hi Christoph, 2017-01-04 6:25 GMT+01:00 Christoph Hellwig <hch at lst.de>: > Most users of BLOCK_PC requests allocate the sense buffer on the stack, > so to avoid DMA to the stack copy them to a field in the heap allocated > virtblk_req structure. Without that any attempt at SCSI passthrough I/O, > including the SG_IO ioctl from userspace will crash the kernel. Note that >

...iscsi initiator, I can > pass all the scsi3_test tests. If you are passing the LUN to the VM with device='lun', the driver and VMM do not interpret any SCSI command. You should see exactly the same data as in the host, which includes support for SPC-3: >>> [root@localhost /]# sg_inq /dev/VM-IMAGES-BACKUP-DO-NOT-REMOVE/q_disk >>> standard INQUIRY: >>> PQual=0 Device_type=0 RMB=0 version=0x05 [SPC-3] >>> [AERC=0] [TrmTsk=0] NormACA=0 HiSUP=0 Resp_data_format=0 >>> SCCS=1 ACC=0 TPGS=1 3PC=0 Protect=0 [BQue=0] >>> E...

Hi! This question emerged during testing of oVirt sparsify integration. oVirt now is able to run virt-sparsify on VM disks. But virt-sparsify seems to have no effect on iSCSI disks. Does virt-sparsify work on iSCSI disks? Maybe in sum situation, with some configuration of iSCSI server, with some specific virt-sparsify options? Shmuel

Il 20/08/2013 12:42, Timon Wang ha scritto: > [root@localhost /]# ls -l /dev/VM-IMAGES-BACKUP-DO-NOT-REMOVE/q_disk > lrwxrwxrwx. 1 root root 8 8月 20 17:38 > /dev/VM-IMAGES-BACKUP-DO-NOT-REMOVE/q_disk -> ../dm-13 > [root@localhost /]# sg_inq /dev/VM-IMAGES-BACKUP-DO-NOT-REMOVE/q_disk > standard INQUIRY: > PQual=0 Device_type=0 RMB=0 version=0x05 [SPC-3] > [AERC=0] [TrmTsk=0] NormACA=0 HiSUP=0 Resp_data_format=0 > SCCS=1 ACC=0 TPGS=1 3PC=0 Protect=0 [BQue=0] > EncServ=0 MultiP=0 [MChngr=0] [ACKREQQ...

On Tue, Aug 20, 2013 at 4:33 PM, Paolo Bonzini <pbonzini@redhat.com> wrote: > Il 20/08/2013 08:00, Timon Wang ha scritto: >> <disk type='file' device='disk'> >> <driver name='qemu' type='raw' cache='none'/> >> <source file='/home/images/win2008_2_sys'/> >> <target

On Wed, Jan 04, 2017 at 04:47:03PM +0100, ??? wrote: > This sounds scary. > Could you share how to reproduce it, this should go into stable if > it's the case. Step 1: Build your kernel with CONFIG_VMAP_STACK=y Step 2: issue a SG_IO ioctl, e.g. sg_inq /dev/vda

...t.de>: > On Wed, Jan 04, 2017 at 04:47:03PM +0100, ??? wrote: >> This sounds scary. >> Could you share how to reproduce it, this should go into stable if >> it's the case. > > Step 1: Build your kernel with CONFIG_VMAP_STACK=y > Step 2: issue a SG_IO ioctl, e.g. sg_inq /dev/vda > Thanks, so it's only relevant to kernel > 4.9, as CONFIG_VMAP_STACK only introduced in 4.9 kernel. Regards, Jinpu

...t.de>: > On Wed, Jan 04, 2017 at 04:47:03PM +0100, ??? wrote: >> This sounds scary. >> Could you share how to reproduce it, this should go into stable if >> it's the case. > > Step 1: Build your kernel with CONFIG_VMAP_STACK=y > Step 2: issue a SG_IO ioctl, e.g. sg_inq /dev/vda > Thanks, so it's only relevant to kernel > 4.9, as CONFIG_VMAP_STACK only introduced in 4.9 kernel. Regards, Jinpu

...,id=scsi0-0-0-0: > scsi-block: INQUIRY failed > qemu-system-x86_64: -device > scsi-block,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0: > Device 'scsi-block' could not be initialized Can you do # ls -l /dev/VM-IMAGES-BACKUP-DO-NOT-REMOVE/q_disk # sg_inq /dev/VM-IMAGES-BACKUP-DO-NOT-REMOVE/q_disk ? Paolo

...not stable or I did not config it right. On Thu, Aug 22, 2013 at 5:02 PM, Paolo Bonzini <pbonzini@redhat.com> wrote: > Il 22/08/2013 09:46, Timon Wang ha scritto: >> Thanks Nicholas. >> >> I found that scsicmd can't pass all the scsi3_test but the result of >> sg_inq is the same as it in the host. >> >> I am absolutely confused about this situation. Am I missed some >> information about it? > > I am also confused. You need to understand the limitations that the > clustering software is putting. > > Can you also try using the me...

>> I found that scsicmd can't pass all the scsi3_test but the result of >> sg_inq is the same as it in the host. >> >> I am absolutely confused about this situation. Am I missed some >> information about it? I guess this is caused by the lack of capability. Please check if enough capability was added to kvm process by the following steps. 1. Check the pid...