On Fri, Apr 29, 2016 at 10:10:39AM +0100, Stefan Hajnoczi wrote:
> On Thu, Apr 28, 2016 at 05:44:21PM -0000, Tom Yan wrote:
>
> CCing Keith Busch <email address hidden>, maintainer of QEMU NVMe.
> Maybe he has an idea.
Thanks for the report. Sounds like a Windows specific issue as I have no
problem with multiple nvme drives on my dev machines:
# ls /dev/nvme*
/dev/nvme0 /dev/nvme0n1 /dev/nvme1 /dev/nvme1n1
# nvme id-ctrl /dev/nvme0 | grep sn
sn : foo
# nvme id-ctrl /dev/nvme1 | grep sn
sn : bar
> > When there are two NVMe devices specified, only the second one will be
> > usable in Windows. The following error is shown under "Device status" of
> > the failed NVMe controller in Device Manager:
> >
> > "This device cannot start. (Code 10)
> >
> > The I/O device is configured incorrectly or the configuration parameters
> > to the driver are incorrect."
> >
> > The only thing seems suspicious to me is that the nvme emulation in qemu
> > does not have WWN/EUI-64 set for the devices, though I have no idea at
> > all whether that is mandatory:
These are not mandatory. They were only introduced in the 1.1 and 1.2 versions
of the NVMe spec, though we only cared to emulate the 1.0 portions rather than
provide a full featured NVMe controller.
That said, there needs to be care in the host OS to provide an appropriate
translation IF it is using a SCSI stack to talk to NVMe. Linux doesn't care,
but Windows does.
The above looks reasonable for your second controller that had serial
2BDAC262CF831698.
> > C:\Windows\system32>sg_vpd -p sn PD1
> > Unit serial number VPD page:
> > Unit serial number: 0000_0000_0000_0000."
This doesn't look like a very good SCSI-NVMe translation and possibly
suspicious. But I don't know the first thing about windows; does it care about
unique unit serial numbers in order to surface a "SCSI" disk?
On Fri, Apr 29, 2016 at 10:10:39AM +0100, Stefan Hajnoczi wrote:
> On Thu, Apr 28, 2016 at 05:44:21PM -0000, Tom Yan wrote:
>
> CCing Keith Busch <email address hidden>, maintainer of QEMU NVMe.
> Maybe he has an idea.
Thanks for the report. Sounds like a Windows specific issue as I have no
problem with multiple nvme drives on my dev machines:
[Host]
# uname -r
4.6.0-rc5+
# qemu-system-x86_64 --version
QEMU emulator version 2.5.50, Copyright (c) 2003-2008 Fabrice Bellard
# qemu-system-x86_64 -m 4096 -smp 4 -enable-kvm debian.img \ 1.img,if= none,id= one -device nvme,drive= one,serial= foo \ 2.img,if= none,id= two -device nvme,drive= two,serial= bar
-drive file=nvme.
-drive file=nvme.
[Guest]
# uname -r
4.5.0
# ls /dev/nvme*
/dev/nvme0 /dev/nvme0n1 /dev/nvme1 /dev/nvme1n1
# nvme id-ctrl /dev/nvme0 | grep sn
sn : foo
# nvme id-ctrl /dev/nvme1 | grep sn
sn : bar
> > When there are two NVMe devices specified, only the second one will be
> > usable in Windows. The following error is shown under "Device status" of
> > the failed NVMe controller in Device Manager:
> >
> > "This device cannot start. (Code 10)
> >
> > The I/O device is configured incorrectly or the configuration parameters
> > to the driver are incorrect."
> >
> > The only thing seems suspicious to me is that the nvme emulation in qemu
> > does not have WWN/EUI-64 set for the devices, though I have no idea at
> > all whether that is mandatory:
These are not mandatory. They were only introduced in the 1.1 and 1.2 versions
of the NVMe spec, though we only cared to emulate the 1.0 portions rather than
provide a full featured NVMe controller.
That said, there needs to be care in the host OS to provide an appropriate
translation IF it is using a SCSI stack to talk to NVMe. Linux doesn't care,
but Windows does.
> > "C:\Windows\ system32> sg_vpd -i PD1 31698
> > Device Identification VPD page:
> > Addressed logical unit:
> > designator type: SCSI name string, code set: UTF-8
> > SCSI name string:
> > 8086QEMU NVMe Ctrl 00012BDAC262CF8
The above looks reasonable for your second controller that had serial
2BDAC262CF831698.
> > C:\Windows\ system32> sg_vpd -p sn PD1 0000_0000. "
> > Unit serial number VPD page:
> > Unit serial number: 0000_0000_
This doesn't look like a very good SCSI-NVMe translation and possibly
suspicious. But I don't know the first thing about windows; does it care about
unique unit serial numbers in order to surface a "SCSI" disk?