12:58 a.m.
We wan't to setup two Oracle instance and make RAC work on them.
Both VM are setup based on libvirt + KVM, we use a lvm lun which
formated in qcow2 format and set the shareable properties in the disk
driver like this:
<disk type='block' device='disk'>
<driver name='qemu' type='qcow2' cache='none'/>
<source
dev='/dev/81035c32-d2e4-4aaf-82fa-3e76ae587586/ca18f6a5-7c98-46ea-b562-9424e68a52f3'/>
<target dev='hda' bus='ide'/>
<shareable/>
<address type='drive' controller='0' bus='0'
target='0' unit='0'/>
</disk>
But when we use it as shared data disk like we use iscsi/FC disk for
shared data disk, the disk can't be recognized as a share disk, and
RAC can't be setup in the environment.
Any body can give me some guild on this?
I am wondering shareable in the libvirt config really makes the disk shareable?
How can I setup the RAC environment in this situable?
I found that vmware and vbox can do this according to a blog post, I
am wondering if kvm has this ability to make a disk really shareable.
--
Focus on: Server Vitualization, Network security,Scanner,NodeJS,JAVA,WWW
Blog: http://www.nohouse.net
2:54 a.m.
Anybody have idea on it?
I tried to set the disk as raw format, and retried the setup process,
but still can't get through.
On Fri, Aug 2, 2013 at 1:58 PM, Timon Wang <timonwst(a)gmail.com> wrote:
We wan't to setup two Oracle instance and make RAC work on them.
Both VM are setup based on libvirt + KVM, we use a lvm lun which
formated in qcow2 format and set the shareable properties in the disk
driver like this:
<disk type='block' device='disk'>
<driver name='qemu' type='qcow2' cache='none'/>
<source
dev='/dev/81035c32-d2e4-4aaf-82fa-3e76ae587586/ca18f6a5-7c98-46ea-b562-9424e68a52f3'/>
<target dev='hda' bus='ide'/>
<shareable/>
<address type='drive' controller='0' bus='0'
target='0' unit='0'/>
</disk>
But when we use it as shared data disk like we use iscsi/FC disk for
shared data disk, the disk can't be recognized as a share disk, and
RAC can't be setup in the environment.
Any body can give me some guild on this?
I am wondering shareable in the libvirt config really makes the disk shareable?
How can I setup the RAC environment in this situable?
I found that vmware and vbox can do this according to a blog post, I
am wondering if kvm has this ability to make a disk really shareable.
--
Focus on: Server Vitualization, Network security,Scanner,NodeJS,JAVA,WWW
Blog: http://www.nohouse.net
--
Focus on: Server Vitualization, Network security,Scanner,NodeJS,JAVA,WWW
Blog: http://www.nohouse.net
9:04 a.m.
On 08/08/2013 03:54 AM, Timon Wang wrote:
Anybody have idea on it?
I tried to set the disk as raw format, and retried the setup process,
but still can't get through.
Caveat: I know nothing in particular about Oracle RAC, but...
Assuming that RAC uses something like SCSI reservations in order to
share the disk, I would guess it doesn't like the disk being on the IDE
bus.
On Fri, Aug 2, 2013 at 1:58 PM, Timon Wang <timonwst(a)gmail.com> wrote:
> We wan't to setup two Oracle instance and make RAC work on them.
> Both VM are setup based on libvirt + KVM, we use a lvm lun which
> formated in qcow2 format and set the shareable properties in the disk
> driver like this:
>
> <disk type='block' device='disk'>
> <driver name='qemu' type='qcow2' cache='none'/>
> <source
dev='/dev/81035c32-d2e4-4aaf-82fa-3e76ae587586/ca18f6a5-7c98-46ea-b562-9424e68a52f3'/>
> <target dev='hda' bus='ide'/>
> <shareable/>
> <address type='drive' controller='0' bus='0'
target='0' unit='0'/>
> </disk>
>
> But when we use it as shared data disk like we use iscsi/FC disk for
> shared data disk, the disk can't be recognized as a share disk, and
> RAC can't be setup in the environment.
>
> Any body can give me some guild on this?
>
> I am wondering shareable in the libvirt config really makes the disk shareable?
>
> How can I setup the RAC environment in this situable?
>
> I found that vmware and vbox can do this according to a blog post, I
> am wondering if kvm has this ability to make a disk really shareable.
>
> --
> Focus on: Server Vitualization, Network security,Scanner,NodeJS,JAVA,WWW
> Blog: http://www.nohouse.net
10:14 p.m.
I have tryied change the disk bus to SCSI, add a SCSI controller whose
model is virtio-scsi, still can't setup the RAC instance.
I tried to use windows 2008 Failover Cluster feature to setup a a
Failover Cluster instead, and I can't find any cluster disk to share
between two nodes. So when Failover Cluster is setup, I can't add any
Cluster disk to the Failover Cluster.
Have I missed some thing?
On Thu, Aug 8, 2013 at 10:04 PM, Don Koch <dkoch(a)verizon.com> wrote:
On 08/08/2013 03:54 AM, Timon Wang wrote:
> Anybody have idea on it?
>
> I tried to set the disk as raw format, and retried the setup process,
> but still can't get through.
Caveat: I know nothing in particular about Oracle RAC, but...
Assuming that RAC uses something like SCSI reservations in order to
share the disk, I would guess it doesn't like the disk being on the IDE
bus.
>
> On Fri, Aug 2, 2013 at 1:58 PM, Timon Wang <timonwst(a)gmail.com> wrote:
>> We wan't to setup two Oracle instance and make RAC work on them.
>> Both VM are setup based on libvirt + KVM, we use a lvm lun which
>> formated in qcow2 format and set the shareable properties in the disk
>> driver like this:
>>
>> <disk type='block' device='disk'>
>> <driver name='qemu' type='qcow2'
cache='none'/>
>> <source
dev='/dev/81035c32-d2e4-4aaf-82fa-3e76ae587586/ca18f6a5-7c98-46ea-b562-9424e68a52f3'/>
>> <target dev='hda' bus='ide'/>
>> <shareable/>
>> <address type='drive' controller='0' bus='0'
target='0' unit='0'/>
>> </disk>
>>
>> But when we use it as shared data disk like we use iscsi/FC disk for
>> shared data disk, the disk can't be recognized as a share disk, and
>> RAC can't be setup in the environment.
>>
>> Any body can give me some guild on this?
>>
>> I am wondering shareable in the libvirt config really makes the disk shareable?
>>
>> How can I setup the RAC environment in this situable?
>>
>> I found that vmware and vbox can do this according to a blog post, I
>> am wondering if kvm has this ability to make a disk really shareable.
>>
>> --
>> Focus on: Server Vitualization, Network security,Scanner,NodeJS,JAVA,WWW
>> Blog: http://www.nohouse.net
>
>
>
--
Focus on: Server Vitualization, Network security,Scanner,NodeJS,JAVA,WWW
Blog: http://www.nohouse.net
4:49 a.m.
On Fri, Aug 02, 2013 at 01:58:24PM +0800, Timon Wang wrote:
We wan't to setup two Oracle instance and make RAC work on them.
Both VM are setup based on libvirt + KVM, we use a lvm lun which
formated in qcow2 format and set the shareable properties in the disk
driver like this:
<disk type='block' device='disk'>
<driver name='qemu' type='qcow2' cache='none'/>
qcow2 is not cluster-aware, it cannot be opened by multiple VMs at the
same time.
You must use raw.
Stefan
4:53 a.m.
On Sat, Aug 10, 2013 at 11:14:39AM +0800, Timon Wang wrote:
I have tryied change the disk bus to SCSI, add a SCSI controller
whose
model is virtio-scsi, still can't setup the RAC instance.
I tried to use windows 2008 Failover Cluster feature to setup a a
Failover Cluster instead, and I can't find any cluster disk to share
between two nodes. So when Failover Cluster is setup, I can't add any
Cluster disk to the Failover Cluster.
Have I missed some thing?
I'm not sure what SCSI-level requirements RAC or Failover Cluster have.
If anyone knows which features are needed it would be possible to
confirm whether they are supported under KVM.
I expect this can only work if you are passing through a shared LUN.
Can you describe your configuration?
Stefan
5:17 a.m.
Yes, SCSI bus likes pass through a shared LUN to the vm, and I am
using a shared LUN for 'share' purpose.
I found a post that vmware use lsilogic bus for the shared disk, but
my qemu/kvm version can't support lsilogic bus.
I'm tring to update qemu/kvm version for lsilogic bus support.
On 8/12/13, Stefan Hajnoczi <stefanha(a)gmail.com> wrote:
On Sat, Aug 10, 2013 at 11:14:39AM +0800, Timon Wang wrote:
> I have tryied change the disk bus to SCSI, add a SCSI controller whose
> model is virtio-scsi, still can't setup the RAC instance.
>
> I tried to use windows 2008 Failover Cluster feature to setup a a
> Failover Cluster instead, and I can't find any cluster disk to share
> between two nodes. So when Failover Cluster is setup, I can't add any
> Cluster disk to the Failover Cluster.
>
> Have I missed some thing?
I'm not sure what SCSI-level requirements RAC or Failover Cluster have.
If anyone knows which features are needed it would be possible to
confirm whether they are supported under KVM.
I expect this can only work if you are passing through a shared LUN.
Can you describe your configuration?
Stefan
--
Focus on: Server Vitualization, Network security,Scanner,NodeJS,JAVA,WWW
Blog: http://www.nohouse.net
4:18 a.m.
On Mon, Aug 12, 2013 at 06:17:51PM +0800, Timon Wang wrote:
Yes, SCSI bus likes pass through a shared LUN to the vm, and I am
using a shared LUN for 'share' purpose.
I found a post that vmware use lsilogic bus for the shared disk, but
my qemu/kvm version can't support lsilogic bus.
I'm tring to update qemu/kvm version for lsilogic bus support.
Use virtio-scsi. The emulated LSI SCSI controller has known bugs and is
not actively developed - don't be surprised if you hit issues with it.
The question is still what commands RAC or Failover Clustering use. If
you find that the software refuses to run, it could be because
additional work is required to make it work on KVM.
Stefan
1:33 a.m.
Thanks, i have tried virtio-scsi and LSI SCSI controller, by using a
local file or a LUN as disk. Both raw and qcow2 disk format are be
verified, but no way to make windows Failover Cluster and Oracle RAC
work correctly.
Actually, Oracle RAC and Windows Failover Cluster needs "share"
storage like iscsi disk and fc disk to work correctly.
In iscsi situation, we can use ip network for Failover Cluster "share"
storage, but when we use fc as a high performance solution, we can't
use fc "share" storage direct in VM(Not LUN passthrough).
As I google the windows Failover Cluster requirements, I found that
this issue may be that windows checks only iscsi and fc drivers, the
type of the disk may be check by the driver type. In KVM situation, we
can't emulate a iscsi/fc disk for VM to use, so we can't setup a
environment like this.
I'm wondering, if we want't to make sure the applications and service
in the VM to always work, it's there another way to do this in KVM
environment.
On Tue, Aug 13, 2013 at 5:18 PM, Stefan Hajnoczi <stefanha(a)gmail.com> wrote:
On Mon, Aug 12, 2013 at 06:17:51PM +0800, Timon Wang wrote:
> Yes, SCSI bus likes pass through a shared LUN to the vm, and I am
> using a shared LUN for 'share' purpose.
>
> I found a post that vmware use lsilogic bus for the shared disk, but
> my qemu/kvm version can't support lsilogic bus.
>
> I'm tring to update qemu/kvm version for lsilogic bus support.
Use virtio-scsi. The emulated LSI SCSI controller has known bugs and is
not actively developed - don't be surprised if you hit issues with it.
The question is still what commands RAC or Failover Clustering use. If
you find that the software refuses to run, it could be because
additional work is required to make it work on KVM.
Stefan
--
Focus on: Server Vitualization, Network security,Scanner,NodeJS,JAVA,WWW
Blog: http://www.nohouse.net
3:40 a.m.
Hi all,
I found a article about Hyper-V virtual Fiber Channel, I think this
will make Failover Cluster work if KVM has the same feature.
http://technet.microsoft.com/en-us/library/hh831413.aspx
Hyper-V uses NPIV for virtual Fiber Channel, I have read some article
about KVM NPIV, but how can I config it with libvirt? Any body can
show me some example?
On Wed, Aug 14, 2013 at 2:33 PM, Timon Wang <timonwst(a)gmail.com> wrote:
Thanks, i have tried virtio-scsi and LSI SCSI controller, by using a
local file or a LUN as disk. Both raw and qcow2 disk format are be
verified, but no way to make windows Failover Cluster and Oracle RAC
work correctly.
Actually, Oracle RAC and Windows Failover Cluster needs "share"
storage like iscsi disk and fc disk to work correctly.
In iscsi situation, we can use ip network for Failover Cluster "share"
storage, but when we use fc as a high performance solution, we can't
use fc "share" storage direct in VM(Not LUN passthrough).
As I google the windows Failover Cluster requirements, I found that
this issue may be that windows checks only iscsi and fc drivers, the
type of the disk may be check by the driver type. In KVM situation, we
can't emulate a iscsi/fc disk for VM to use, so we can't setup a
environment like this.
I'm wondering, if we want't to make sure the applications and service
in the VM to always work, it's there another way to do this in KVM
environment.
On Tue, Aug 13, 2013 at 5:18 PM, Stefan Hajnoczi <stefanha(a)gmail.com> wrote:
> On Mon, Aug 12, 2013 at 06:17:51PM +0800, Timon Wang wrote:
>> Yes, SCSI bus likes pass through a shared LUN to the vm, and I am
>> using a shared LUN for 'share' purpose.
>>
>> I found a post that vmware use lsilogic bus for the shared disk, but
>> my qemu/kvm version can't support lsilogic bus.
>>
>> I'm tring to update qemu/kvm version for lsilogic bus support.
>
> Use virtio-scsi. The emulated LSI SCSI controller has known bugs and is
> not actively developed - don't be surprised if you hit issues with it.
>
> The question is still what commands RAC or Failover Clustering use. If
> you find that the software refuses to run, it could be because
> additional work is required to make it work on KVM.
>
> Stefan
--
Focus on: Server Vitualization, Network security,Scanner,NodeJS,JAVA,WWW
Blog: http://www.nohouse.net
--
Focus on: Server Vitualization, Network security,Scanner,NodeJS,JAVA,WWW
Blog: http://www.nohouse.net
9:02 a.m.
On Wed, Aug 14, 2013 at 04:40:44PM +0800, Timon Wang wrote:
I found a article about Hyper-V virtual Fiber Channel, I think this
will make Failover Cluster work if KVM has the same feature.
http://technet.microsoft.com/en-us/library/hh831413.aspx
Hyper-V uses NPIV for virtual Fiber Channel, I have read some article
about KVM NPIV, but how can I config it with libvirt? Any body can
show me some example?
A web search turns up this:
https://docs.fedoraproject.org/en-US/Fedora/18/html/Virtualization_Admini...
You can use this if the host has a supported Fibre Channel HBA and your
image is on a SAN LUN.
From my limited knowledge about this, NPIV itself won't make
clustering
possible. RAC or Failure Cluster probably still require specific SCSI
commands in order to work (like persistent reservations) and that's what
needs to be investigated in order to figure out a solution.
Stefan
5:01 a.m.
Thanks.
I have read the link you provide, there is another link which tells me
to pass a NPIV discovery lun as a disk, this is seen as a local direct
access disk in windows. RAC and Failure Cluster both consider this
pass through disk as local disk, not a share disk, and the setup
process failed.
Hyper-v provides a virtual Fiber Channel implementation, so I
wondering if kvm has the same solution like it.
On Wed, Aug 14, 2013 at 10:02 PM, Stefan Hajnoczi <stefanha(a)gmail.com> wrote:
On Wed, Aug 14, 2013 at 04:40:44PM +0800, Timon Wang wrote:
> I found a article about Hyper-V virtual Fiber Channel, I think this
> will make Failover Cluster work if KVM has the same feature.
> http://technet.microsoft.com/en-us/library/hh831413.aspx
>
> Hyper-V uses NPIV for virtual Fiber Channel, I have read some article
> about KVM NPIV, but how can I config it with libvirt? Any body can
> show me some example?
A web search turns up this:
https://docs.fedoraproject.org/en-US/Fedora/18/html/Virtualization_Admini...
You can use this if the host has a supported Fibre Channel HBA and your
image is on a SAN LUN.
From my limited knowledge about this, NPIV itself won't make clustering
possible. RAC or Failure Cluster probably still require specific SCSI
commands in order to work (like persistent reservations) and that's what
needs to be investigated in order to figure out a solution.
Stefan
--
Focus on: Server Vitualization, Network security,Scanner,NodeJS,JAVA,WWW
Blog: http://www.nohouse.net
6:10 a.m.
Il 15/08/2013 12:01, Timon Wang ha scritto:
Thanks.
I have read the link you provide, there is another link which tells me
to pass a NPIV discovery lun as a disk, this is seen as a local direct
access disk in windows. RAC and Failure Cluster both consider this
pass through disk as local disk, not a share disk, and the setup
process failed.
Hyper-v provides a virtual Fiber Channel implementation, so I
wondering if kvm has the same solution like it.
Can you include the XML file you are using for the domain?
Paolo
1 a.m.
My domain xml is like this:
<domain type='kvm'
xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
<name>2008-2</name>
<uuid>6325d8a5-468d-42e9-b5cb-9a04f5f34e80</uuid>
<memory unit='KiB'>524288</memory>
<currentMemory unit='KiB'>524288</currentMemory>
<vcpu placement='static'>2</vcpu>
<os>
<type arch='x86_64' machine='pc-i440fx-1.4'>hvm</type>
</os>
<features>
<acpi/>
<apic/>
<pae/>
</features>
<clock offset='localtime'/>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>destroy</on_crash>
<devices>
<emulator>/usr/bin/qemu-kvm</emulator>
<disk type='file' device='floppy'>
<driver name='qemu' type='raw' cache='none'/>
<target dev='fda' bus='fdc'/>
<readonly/>
<address type='drive' controller='0' bus='0'
target='0' unit='0'/>
</disk>
<disk type='file' device='disk'>
<driver name='qemu' type='raw' cache='none'/>
<source file='/home/images/win2008_2_sys'/>
<target dev='hda' bus='ide'/>
<boot order='3'/>
<address type='drive' controller='0' bus='0'
target='0' unit='0'/>
</disk>
<disk type='file' device='cdrom'>
<driver name='qemu' type='raw'/>
<source file='/home/isos/windows2008_64r2.iso'/>
<target dev='sdc' bus='ide'/>
<readonly/>
<boot order='1'/>
<address type='drive' controller='0' bus='1'
target='0' unit='0'/>
</disk>
<disk type='block' device='disk'>
<driver name='qemu' type='raw'/>
<source dev='/dev/fedora/q_disk'/>
<target dev='sda' bus='virtio'/>
<shareable/>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x0a'
function='0x0'/>
</disk>
<controller type='fdc' index='0'/>
<controller type='ide' index='0'>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x01'
function='0x1'/>
</controller>
<controller type='virtio-serial' index='0'>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x06'
function='0x0'/>
</controller>
<controller type='usb' index='0'>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x01'
function='0x2'/>
</controller>
<controller type='pci' index='0' model='pci-root'/>
<controller type='scsi' index='0' model='virtio-scsi'>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x07'
function='0x0'/>
</controller>
<interface type='bridge'>
<mac address='52:54:00:71:20:ae'/>
<source bridge='br0'/>
<target dev='vport2'/>
<model type='rtl8139'/>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x03'
function='0x0'/>
</interface>
<interface type='network'>
<mac address='52:54:00:12:a0:fd'/>
<source network='default'/>
<model type='rtl8139'/>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x04'
function='0x0'/>
</interface>
<serial type='pty'>
<target port='0'/>
</serial>
<console type='pty'>
<target type='serial' port='0'/>
</console>
<input type='tablet' bus='usb'/>
<input type='mouse' bus='ps2'/>
<graphics type='spice' autoport='yes' listen='0.0.0.0'>
<listen type='address' address='0.0.0.0'/>
</graphics>
<sound model='ac97'>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x05'
function='0x0'/>
</sound>
<video>
<model type='qxl' ram='65536' vram='32768'
heads='2'/>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x02'
function='0x0'/>
</video>
<memballoon model='virtio'>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x08'
function='0x0'/>
</memballoon>
</devices>
<qemu:commandline>
<qemu:arg value='-rtc-td-hack'/>
</qemu:commandline>
</domain>
On 8/19/13, Paolo Bonzini <pbonzini(a)redhat.com> wrote:
Il 15/08/2013 12:01, Timon Wang ha scritto:
> Thanks.
>
> I have read the link you provide, there is another link which tells me
> to pass a NPIV discovery lun as a disk, this is seen as a local direct
> access disk in windows. RAC and Failure Cluster both consider this
> pass through disk as local disk, not a share disk, and the setup
> process failed.
>
> Hyper-v provides a virtual Fiber Channel implementation, so I
> wondering if kvm has the same solution like it.
Can you include the XML file you are using for the domain?
Paolo
--
Focus on: Server Vitualization, Network security,Scanner,NodeJS,JAVA,WWW
Blog: http://www.nohouse.net
1:05 a.m.
Right now, I found that Windows Failover Cluster needs SCSI-3
Persistent Reservation, I don't know where if virtio-scsi supports
this, according to http://www.ovirt.org/Features/Virtio-SCSI I found
this:
limited flexibility: virtio-blk does not support all possible storage
scenarios. For example, it does not allow SCSI passthrough or
persistent reservations. In principle, virtio-scsi provides anything
that the underlying SCSI target (be it physical storage, iSCSI or the
in-kernel target) supports.
virtio-blk does not support persistent reservations, but virtio-scsi
may surpport.
Another web page which archive mail lists
http://www.spinics.net/lists/target-devel/msg01813.html, which request
virtio-scsi to implement SPC-3 (persistent reservation) feature, but I
can't found any more information about this.
On Tue, Aug 20, 2013 at 2:00 PM, Timon Wang <timonwst(a)gmail.com> wrote:
My domain xml is like this:
<domain type='kvm'
xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
<name>2008-2</name>
<uuid>6325d8a5-468d-42e9-b5cb-9a04f5f34e80</uuid>
<memory unit='KiB'>524288</memory>
<currentMemory unit='KiB'>524288</currentMemory>
<vcpu placement='static'>2</vcpu>
<os>
<type arch='x86_64' machine='pc-i440fx-1.4'>hvm</type>
</os>
<features>
<acpi/>
<apic/>
<pae/>
</features>
<clock offset='localtime'/>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>destroy</on_crash>
<devices>
<emulator>/usr/bin/qemu-kvm</emulator>
<disk type='file' device='floppy'>
<driver name='qemu' type='raw' cache='none'/>
<target dev='fda' bus='fdc'/>
<readonly/>
<address type='drive' controller='0' bus='0'
target='0' unit='0'/>
</disk>
<disk type='file' device='disk'>
<driver name='qemu' type='raw' cache='none'/>
<source file='/home/images/win2008_2_sys'/>
<target dev='hda' bus='ide'/>
<boot order='3'/>
<address type='drive' controller='0' bus='0'
target='0' unit='0'/>
</disk>
<disk type='file' device='cdrom'>
<driver name='qemu' type='raw'/>
<source file='/home/isos/windows2008_64r2.iso'/>
<target dev='sdc' bus='ide'/>
<readonly/>
<boot order='1'/>
<address type='drive' controller='0' bus='1'
target='0' unit='0'/>
</disk>
<disk type='block' device='disk'>
<driver name='qemu' type='raw'/>
<source dev='/dev/fedora/q_disk'/>
<target dev='sda' bus='virtio'/>
<shareable/>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x0a'
function='0x0'/>
</disk>
<controller type='fdc' index='0'/>
<controller type='ide' index='0'>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x01'
function='0x1'/>
</controller>
<controller type='virtio-serial' index='0'>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x06'
function='0x0'/>
</controller>
<controller type='usb' index='0'>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x01'
function='0x2'/>
</controller>
<controller type='pci' index='0' model='pci-root'/>
<controller type='scsi' index='0' model='virtio-scsi'>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x07'
function='0x0'/>
</controller>
<interface type='bridge'>
<mac address='52:54:00:71:20:ae'/>
<source bridge='br0'/>
<target dev='vport2'/>
<model type='rtl8139'/>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x03'
function='0x0'/>
</interface>
<interface type='network'>
<mac address='52:54:00:12:a0:fd'/>
<source network='default'/>
<model type='rtl8139'/>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x04'
function='0x0'/>
</interface>
<serial type='pty'>
<target port='0'/>
</serial>
<console type='pty'>
<target type='serial' port='0'/>
</console>
<input type='tablet' bus='usb'/>
<input type='mouse' bus='ps2'/>
<graphics type='spice' autoport='yes'
listen='0.0.0.0'>
<listen type='address' address='0.0.0.0'/>
</graphics>
<sound model='ac97'>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x05'
function='0x0'/>
</sound>
<video>
<model type='qxl' ram='65536' vram='32768'
heads='2'/>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x02'
function='0x0'/>
</video>
<memballoon model='virtio'>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x08'
function='0x0'/>
</memballoon>
</devices>
<qemu:commandline>
<qemu:arg value='-rtc-td-hack'/>
</qemu:commandline>
</domain>
On 8/19/13, Paolo Bonzini <pbonzini(a)redhat.com> wrote:
> Il 15/08/2013 12:01, Timon Wang ha scritto:
>> Thanks.
>>
>> I have read the link you provide, there is another link which tells me
>> to pass a NPIV discovery lun as a disk, this is seen as a local direct
>> access disk in windows. RAC and Failure Cluster both consider this
>> pass through disk as local disk, not a share disk, and the setup
>> process failed.
>>
>> Hyper-v provides a virtual Fiber Channel implementation, so I
>> wondering if kvm has the same solution like it.
>
> Can you include the XML file you are using for the domain?
>
> Paolo
>
>
--
Focus on: Server Vitualization, Network security,Scanner,NodeJS,JAVA,WWW
Blog: http://www.nohouse.net
--
Focus on: Server Vitualization, Network security,Scanner,NodeJS,JAVA,WWW
Blog: http://www.nohouse.net
3:33 a.m.
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 dev='hda' bus='ide'/>
<boot order='3'/>
<address type='drive' controller='0' bus='0'
target='0' unit='0'/>
</disk>
<disk type='file' device='cdrom'>
<driver name='qemu' type='raw'/>
<source file='/home/isos/windows2008_64r2.iso'/>
<target dev='sdc' bus='ide'/>
<readonly/>
<boot order='1'/>
<address type='drive' controller='0' bus='1'
target='0' unit='0'/>
</disk>
<disk type='block' device='disk'>
I'm not sure this will be enough, but if you want passthrough to the
host device you should use device='lun' here. However, you still would
not be able to issue SCSI reservations unless you run QEMU with the
CAP_SYS_RAWIO capability (using "<disk ... rawio='yes'>").
Most important, it still would be unsafe to do this if the same device
is passed to multiple virtual machines on the same host. You need to
have NPIV and create separate virtual HBAs. Then each virtual machine
should get a separate virtual HBA. Otherwise, persistent reservations
are not attached to a particular virtual machine, but generically to the
host.
<driver name='qemu' type='raw'/>
<source dev='/dev/fedora/q_disk'/>
<target dev='sda' bus='virtio'/>
You are not exposing a virtio-scsi disk here. You are exposing a
virtio-blk disk. You can see this from the type='pci' address that
libvirt gave to the disk.
If you use bus='scsi', you will see that libvirt will use type='drive'
for the address.
<controller type='scsi' index='0'
model='virtio-scsi'>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x07'
function='0x0'/>
</controller>
This is okay.
<qemu:commandline>
<qemu:arg value='-rtc-td-hack'/>
</qemu:commandline>
FWIW, this can be replaced with
<clock offset='localtime'>
<timer name='rtc' tickpolicy='catchup'/>
</clock>
(you already have the <clock> element, but no <timer> element inside).
Paolo
</domain>
On 8/19/13, Paolo Bonzini <pbonzini(a)redhat.com> wrote:
> Il 15/08/2013 12:01, Timon Wang ha scritto:
>> Thanks.
>>
>> I have read the link you provide, there is another link which tells me
>> to pass a NPIV discovery lun as a disk, this is seen as a local direct
>> access disk in windows. RAC and Failure Cluster both consider this
>> pass through disk as local disk, not a share disk, and the setup
>> process failed.
>>
>> Hyper-v provides a virtual Fiber Channel implementation, so I
>> wondering if kvm has the same solution like it.
>
> Can you include the XML file you are using for the domain?
>
> Paolo
>
>
4:59 a.m.
On Tue, Aug 20, 2013 at 4:33 PM, Paolo Bonzini <pbonzini(a)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 dev='hda' bus='ide'/>
> <boot order='3'/>
> <address type='drive' controller='0' bus='0'
target='0' unit='0'/>
> </disk>
> <disk type='file' device='cdrom'>
> <driver name='qemu' type='raw'/>
> <source file='/home/isos/windows2008_64r2.iso'/>
> <target dev='sdc' bus='ide'/>
> <readonly/>
> <boot order='1'/>
> <address type='drive' controller='0' bus='1'
target='0' unit='0'/>
> </disk>
> <disk type='block' device='disk'>
I'm not sure this will be enough, but if you want passthrough to the
host device you should use device='lun' here. However, you still would
not be able to issue SCSI reservations unless you run QEMU with the
CAP_SYS_RAWIO capability (using "<disk ... rawio='yes'>").
After change the libvirt xml like this:
<disk type='block' device='lun' rawio='yes'>
<driver name='qemu' type='raw' cache='none'/>
<source dev='/dev/VM-IMAGES-BACKUP-DO-NOT-REMOVE/q_disk'/>
<target dev='sda' bus='scsi'/>
<shareable/>
<address type='drive' controller='0' bus='0'
target='0' unit='0'/>
</disk>
I got these errors:
char device redirected to /dev/pts/1 (label charserial0)
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:
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
Most important, it still would be unsafe to do this if the same
device
is passed to multiple virtual machines on the same host. You need to
have NPIV and create separate virtual HBAs. Then each virtual machine
should get a separate virtual HBA. Otherwise, persistent reservations
are not attached to a particular virtual machine, but generically to the
host.
How to use NPIV virtual HBAs with libvirt xml configurations? I can
define nodedev, but have no idea about how to pass the nodedev to the
vm.
> <driver name='qemu' type='raw'/>
> <source dev='/dev/fedora/q_disk'/>
> <target dev='sda' bus='virtio'/>
You are not exposing a virtio-scsi disk here. You are exposing a
virtio-blk disk. You can see this from the type='pci' address that
libvirt gave to the disk.
If you use bus='scsi', you will see that libvirt will use type='drive'
for the address.
> <controller type='scsi' index='0'
model='virtio-scsi'>
> <address type='pci' domain='0x0000' bus='0x00'
slot='0x07'
> function='0x0'/>
> </controller>
This is okay.
> <qemu:commandline>
> <qemu:arg value='-rtc-td-hack'/>
> </qemu:commandline>
FWIW, this can be replaced with
<clock offset='localtime'>
<timer name='rtc' tickpolicy='catchup'/>
</clock>
(you already have the <clock> element, but no <timer> element inside).
Thanks for this tip.
Paolo
> </domain>
>
>
>
> On 8/19/13, Paolo Bonzini <pbonzini(a)redhat.com> wrote:
>> Il 15/08/2013 12:01, Timon Wang ha scritto:
>>> Thanks.
>>>
>>> I have read the link you provide, there is another link which tells me
>>> to pass a NPIV discovery lun as a disk, this is seen as a local direct
>>> access disk in windows. RAC and Failure Cluster both consider this
>>> pass through disk as local disk, not a share disk, and the setup
>>> process failed.
>>>
>>> Hyper-v provides a virtual Fiber Channel implementation, so I
>>> wondering if kvm has the same solution like it.
>>
>> Can you include the XML file you are using for the domain?
>>
>> Paolo
>>
>>
>
>
--
Focus on: Server Vitualization, Network security,Scanner,NodeJS,JAVA,WWW
Blog: http://www.nohouse.net
5:16 a.m.
Il 20/08/2013 11:59, Timon Wang ha scritto:
On Tue, Aug 20, 2013 at 4:33 PM, Paolo Bonzini
<pbonzini(a)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 dev='hda' bus='ide'/>
>> <boot order='3'/>
>> <address type='drive' controller='0' bus='0'
target='0' unit='0'/>
>> </disk>
>> <disk type='file' device='cdrom'>
>> <driver name='qemu' type='raw'/>
>> <source file='/home/isos/windows2008_64r2.iso'/>
>> <target dev='sdc' bus='ide'/>
>> <readonly/>
>> <boot order='1'/>
>> <address type='drive' controller='0' bus='1'
target='0' unit='0'/>
>> </disk>
>> <disk type='block' device='disk'>
>
> I'm not sure this will be enough, but if you want passthrough to the
> host device you should use device='lun' here. However, you still would
> not be able to issue SCSI reservations unless you run QEMU with the
> CAP_SYS_RAWIO capability (using "<disk ... rawio='yes'>").
>
After change the libvirt xml like this:
<disk type='block' device='lun' rawio='yes'>
<driver name='qemu' type='raw' cache='none'/>
<source dev='/dev/VM-IMAGES-BACKUP-DO-NOT-REMOVE/q_disk'/>
<target dev='sda' bus='scsi'/>
<shareable/>
<address type='drive' controller='0' bus='0'
target='0' unit='0'/>
</disk>
I got these errors:
char device redirected to /dev/pts/1 (label charserial0)
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:
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
5:42 a.m.
[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] WBus16=1 Sync=1 Linked=0 [TranDis=0] CmdQue=1
length=36 (0x24) Peripheral device type: disk
Vendor identification: MacroSAN
Product identification: LU
Product revision level: 1.0
Unit serial number: 0d9281ae-aea4-6da0-0000-02180142b300
This lun is from a vg build based on iscsi target.
[root@localhost /]# libvirtd --version
libvirtd (libvirt) 1.0.5
[root@localhost /]# qemu-kvm --version
QEMU emulator version 1.4.1, Copyright (c) 2003-2008 Fabrice Bellard
[root@localhost /]# uname -a
Linux localhost.localdomain 3.9.2-301.fc19.x86_64 #1 SMP Mon May 13
12:36:24 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
On Tue, Aug 20, 2013 at 6:16 PM, Paolo Bonzini <pbonzini(a)redhat.com> wrote:
Il 20/08/2013 11:59, Timon Wang ha scritto:
> On Tue, Aug 20, 2013 at 4:33 PM, Paolo Bonzini <pbonzini(a)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 dev='hda' bus='ide'/>
>>> <boot order='3'/>
>>> <address type='drive' controller='0' bus='0'
target='0' unit='0'/>
>>> </disk>
>>> <disk type='file' device='cdrom'>
>>> <driver name='qemu' type='raw'/>
>>> <source file='/home/isos/windows2008_64r2.iso'/>
>>> <target dev='sdc' bus='ide'/>
>>> <readonly/>
>>> <boot order='1'/>
>>> <address type='drive' controller='0' bus='1'
target='0' unit='0'/>
>>> </disk>
>>> <disk type='block' device='disk'>
>>
>> I'm not sure this will be enough, but if you want passthrough to the
>> host device you should use device='lun' here. However, you still would
>> not be able to issue SCSI reservations unless you run QEMU with the
>> CAP_SYS_RAWIO capability (using "<disk ...
rawio='yes'>").
>>
>
> After change the libvirt xml like this:
> <disk type='block' device='lun' rawio='yes'>
> <driver name='qemu' type='raw' cache='none'/>
> <source dev='/dev/VM-IMAGES-BACKUP-DO-NOT-REMOVE/q_disk'/>
> <target dev='sda' bus='scsi'/>
> <shareable/>
> <address type='drive' controller='0' bus='0'
target='0' unit='0'/>
> </disk>
> I got these errors:
> char device redirected to /dev/pts/1 (label charserial0)
> 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:
> 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
--
Focus on: Server Vitualization, Network security,Scanner,NodeJS,JAVA,WWW
Blog: http://www.nohouse.net
5:49 a.m.
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=0] Addr16=0
[RelAdr=0] WBus16=1 Sync=1 Linked=0 [TranDis=0] CmdQue=1
length=36 (0x24) Peripheral device type: disk
Vendor identification: MacroSAN
Product identification: LU
Product revision level: 1.0
Unit serial number: 0d9281ae-aea4-6da0-0000-02180142b300
This lun is from a vg build based on iscsi target.
If it is a logical volume, you cannot pass it as a LUN to the guest.
Only the whole iSCSI LUN can be passed as a LUN.
Paolo
[root@localhost /]# libvirtd --version
libvirtd (libvirt) 1.0.5
[root@localhost /]# qemu-kvm --version
QEMU emulator version 1.4.1, Copyright (c) 2003-2008 Fabrice Bellard
[root@localhost /]# uname -a
Linux localhost.localdomain 3.9.2-301.fc19.x86_64 #1 SMP Mon May 13
12:36:24 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
On Tue, Aug 20, 2013 at 6:16 PM, Paolo Bonzini <pbonzini(a)redhat.com> wrote:
> Il 20/08/2013 11:59, Timon Wang ha scritto:
>> On Tue, Aug 20, 2013 at 4:33 PM, Paolo Bonzini <pbonzini(a)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 dev='hda' bus='ide'/>
>>>> <boot order='3'/>
>>>> <address type='drive' controller='0'
bus='0' target='0' unit='0'/>
>>>> </disk>
>>>> <disk type='file' device='cdrom'>
>>>> <driver name='qemu' type='raw'/>
>>>> <source file='/home/isos/windows2008_64r2.iso'/>
>>>> <target dev='sdc' bus='ide'/>
>>>> <readonly/>
>>>> <boot order='1'/>
>>>> <address type='drive' controller='0'
bus='1' target='0' unit='0'/>
>>>> </disk>
>>>> <disk type='block' device='disk'>
>>>
>>> I'm not sure this will be enough, but if you want passthrough to the
>>> host device you should use device='lun' here. However, you still
would
>>> not be able to issue SCSI reservations unless you run QEMU with the
>>> CAP_SYS_RAWIO capability (using "<disk ...
rawio='yes'>").
>>>
>>
>> After change the libvirt xml like this:
>> <disk type='block' device='lun' rawio='yes'>
>> <driver name='qemu' type='raw'
cache='none'/>
>> <source dev='/dev/VM-IMAGES-BACKUP-DO-NOT-REMOVE/q_disk'/>
>> <target dev='sda' bus='scsi'/>
>> <shareable/>
>> <address type='drive' controller='0' bus='0'
target='0' unit='0'/>
>> </disk>
>> I got these errors:
>> char device redirected to /dev/pts/1 (label charserial0)
>> 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:
>> 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
>
6:43 a.m.
Thanks, the whole iSCSI LUN have been passed to the VM.
But I test it with scsicmd, and found that the driver may be not
support SPC-3, but if i use this by microsoft iscsi initiator, I can
pass all the scsi3_test tests.
Tool can be found here:
http://www.symantec.com/business/support/index?page=content&id=TECH72086
It's this means that the scsi passthrough windows driver does not
support SPC-3 feature, I have read a post about this, it says if
support this we should change both the implementation and the
documents in virtio spec.
I am new to this list, so I don't know what is the situation right now?
Would somebody please give me some advise on it?
On Tue, Aug 20, 2013 at 6:49 PM, Paolo Bonzini <pbonzini(a)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 [MChngr=0] [ACKREQQ=0] Addr16=0
> [RelAdr=0] WBus16=1 Sync=1 Linked=0 [TranDis=0] CmdQue=1
> length=36 (0x24) Peripheral device type: disk
> Vendor identification: MacroSAN
> Product identification: LU
> Product revision level: 1.0
> Unit serial number: 0d9281ae-aea4-6da0-0000-02180142b300
>
> This lun is from a vg build based on iscsi target.
If it is a logical volume, you cannot pass it as a LUN to the guest.
Only the whole iSCSI LUN can be passed as a LUN.
Paolo
> [root@localhost /]# libvirtd --version
> libvirtd (libvirt) 1.0.5
> [root@localhost /]# qemu-kvm --version
> QEMU emulator version 1.4.1, Copyright (c) 2003-2008 Fabrice Bellard
> [root@localhost /]# uname -a
> Linux localhost.localdomain 3.9.2-301.fc19.x86_64 #1 SMP Mon May 13
> 12:36:24 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
>
>
> On Tue, Aug 20, 2013 at 6:16 PM, Paolo Bonzini <pbonzini(a)redhat.com> wrote:
>> Il 20/08/2013 11:59, Timon Wang ha scritto:
>>> On Tue, Aug 20, 2013 at 4:33 PM, Paolo Bonzini <pbonzini(a)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 dev='hda' bus='ide'/>
>>>>> <boot order='3'/>
>>>>> <address type='drive' controller='0'
bus='0' target='0' unit='0'/>
>>>>> </disk>
>>>>> <disk type='file' device='cdrom'>
>>>>> <driver name='qemu' type='raw'/>
>>>>> <source file='/home/isos/windows2008_64r2.iso'/>
>>>>> <target dev='sdc' bus='ide'/>
>>>>> <readonly/>
>>>>> <boot order='1'/>
>>>>> <address type='drive' controller='0'
bus='1' target='0' unit='0'/>
>>>>> </disk>
>>>>> <disk type='block' device='disk'>
>>>>
>>>> I'm not sure this will be enough, but if you want passthrough to the
>>>> host device you should use device='lun' here. However, you still
would
>>>> not be able to issue SCSI reservations unless you run QEMU with the
>>>> CAP_SYS_RAWIO capability (using "<disk ...
rawio='yes'>").
>>>>
>>>
>>> After change the libvirt xml like this:
>>> <disk type='block' device='lun' rawio='yes'>
>>> <driver name='qemu' type='raw'
cache='none'/>
>>> <source
dev='/dev/VM-IMAGES-BACKUP-DO-NOT-REMOVE/q_disk'/>
>>> <target dev='sda' bus='scsi'/>
>>> <shareable/>
>>> <address type='drive' controller='0' bus='0'
target='0' unit='0'/>
>>> </disk>
>>> I got these errors:
>>> char device redirected to /dev/pts/1 (label charserial0)
>>> 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:
>>> 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
>>
>
>
>
--
Focus on: Server Vitualization, Network security,Scanner,NodeJS,JAVA,WWW
Blog: http://www.nohouse.net
6:57 a.m.
I found when I use "scsicmd -d1 -s13" test command to test the
"controller bus reset" request, there will be a blue screen on windows
2008 r2.
The error code is :
BugCheck D1, {4, a, 0, fffff8800154dd06}
1: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: 0000000000000004, memory referenced
Arg2: 000000000000000a, IRQL
Arg3: 0000000000000000, value 0 = read operation, 1 = write operation
Arg4: fffff8800154dd06, address which referenced memory
Debugging Details:
------------------
Page 17c41 not present in the dump file. Type ".hh dbgerr004" for details
READ_ADDRESS: 0000000000000004
CURRENT_IRQL: a
FAULTING_IP:
vioscsi+1d06
fffff880`0154dd06 458b4804 mov r9d,dword ptr [r8+4]
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
BUGCHECK_STR: 0xD1
PROCESS_NAME: scsicmd.exe
TRAP_FRAME: fffff880009f7670 -- (.trap 0xfffff880009f7670)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000002 rbx=0000000000000000 rcx=fffffa800065e738
rdx=fffffa800065e8f8 rsi=0000000000000000 rdi=0000000000000000
rip=fffff8800154dd06 rsp=fffff880009f7800 rbp=fffffa800065e8f8
r8=0000000000000000 r9=0000000000000000 r10=fffffa80009155b0
r11=fffff880009f7848 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl zr na po nc
vioscsi+0x1d06:
fffff880`0154dd06 458b4804 mov r9d,dword ptr [r8+4]
ds:e630:0004=????????
Resetting default scope
LAST_CONTROL_TRANSFER: from fffff800016ca469 to fffff800016caf00
STACK_TEXT:
fffff880`009f7528 fffff800`016ca469 : 00000000`0000000a
00000000`00000004 00000000`0000000a 00000000`00000000 :
nt!KeBugCheckEx
fffff880`009f7530 fffff800`016c90e0 : 00000000`00000000
fffffa80`009151b0 fffffa80`0155a290 fffff880`01339110 :
nt!KiBugCheckDispatch+0x69
fffff880`009f7670 fffff880`0154dd06 : 00000000`00000001
fffff880`0154dcec fffffa80`009151b0 fffff880`01323934 :
nt!KiPageFault+0x260
fffff880`009f7800 fffff880`0132abcf : fffffa80`009151b0
fffffa80`0065e8f8 fffffa80`0065e738 00000000`00000001 : vioscsi+0x1d06
fffff880`009f7850 fffff880`0154d971 : 00000000`00000001
00000000`00000001 00000000`002d5000 fffffa80`00925000 :
storport!StorPortSynchronizeAccess+0x4f
fffff880`009f7890 fffff880`01323a0c : fffffa80`00000fb1
fffffa80`0155a200 00000000`002d5000 fffffa80`01576010 : vioscsi+0x1971
fffff880`009f78d0 fffff880`01333adf : fffffa80`006eeb30
fffffa80`006e2070 00000000`00000000 00000000`00000801 :
storport!RaCallMiniportResetBus+0x1c
fffff880`009f7900 fffff880`01333b68 : fffffa80`0155a290
fffffa80`006b39f0 00000040`00000000 00000000`00000000 :
storport!RaidAdapterResetBus+0x2f
fffff880`009f7950 fffff880`0136de0b : 00000000`20206f49
00000000`00000001 00000000`00000001 00000000`20206f49 :
storport!RaidAdapterStorageResetBusIoctl+0x28
fffff880`009f7980 fffff880`0136d1d0 : fffff880`01339110
fffffa80`00915060 00000000`00000000 fffffa80`006e2070 : storport! ??
::NNGAKEGL::`string'+0x3c8
fffff880`009f79d0 fffff800`019e33a7 : fffffa80`006e2070
fffff880`009f7ca0 fffffa80`006e2070 fffffa80`0155a290 :
storport!RaDriverDeviceControlIrp+0x90
fffff880`009f7a10 fffff800`019e3c06 : 00000000`00000000
00000000`00000000 00000000`00000000 00000000`00000000 :
nt!IopXxxControlFile+0x607
fffff880`009f7b40 fffff800`016ca153 : 00000000`001aeb01
00000000`00000001 00000000`001aeba0 fffff800`019db152 :
nt!NtDeviceIoControlFile+0x56
fffff880`009f7bb0 00000000`77a2ff2a : 00000000`00000000
00000000`00000000 00000000`00000000 00000000`00000000 :
nt!KiSystemServiceCopyEnd+0x13
00000000`001af1d8 00000000`00000000 : 00000000`00000000
00000000`00000000 00000000`00000000 00000000`00000000 : 0x77a2ff2a
STACK_COMMAND: kb
FOLLOWUP_IP:
vioscsi+1d06
fffff880`0154dd06 458b4804 mov r9d,dword ptr [r8+4]
SYMBOL_STACK_INDEX: 3
SYMBOL_NAME: vioscsi+1d06
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: vioscsi
IMAGE_NAME: vioscsi.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 5200724f
FAILURE_BUCKET_ID: X64_0xD1_vioscsi+1d06
BUCKET_ID: X64_0xD1_vioscsi+1d06
Followup: MachineOwner
---------
On Tue, Aug 20, 2013 at 7:43 PM, Timon Wang <timonwst(a)gmail.com> wrote:
Thanks, the whole iSCSI LUN have been passed to the VM.
But I test it with scsicmd, and found that the driver may be not
support SPC-3, but if i use this by microsoft iscsi initiator, I can
pass all the scsi3_test tests.
Tool can be found here:
http://www.symantec.com/business/support/index?page=content&id=TECH72086
It's this means that the scsi passthrough windows driver does not
support SPC-3 feature, I have read a post about this, it says if
support this we should change both the implementation and the
documents in virtio spec.
I am new to this list, so I don't know what is the situation right now?
Would somebody please give me some advise on it?
On Tue, Aug 20, 2013 at 6:49 PM, Paolo Bonzini <pbonzini(a)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 [MChngr=0] [ACKREQQ=0] Addr16=0
>> [RelAdr=0] WBus16=1 Sync=1 Linked=0 [TranDis=0] CmdQue=1
>> length=36 (0x24) Peripheral device type: disk
>> Vendor identification: MacroSAN
>> Product identification: LU
>> Product revision level: 1.0
>> Unit serial number: 0d9281ae-aea4-6da0-0000-02180142b300
>>
>> This lun is from a vg build based on iscsi target.
>
> If it is a logical volume, you cannot pass it as a LUN to the guest.
> Only the whole iSCSI LUN can be passed as a LUN.
>
> Paolo
>
>> [root@localhost /]# libvirtd --version
>> libvirtd (libvirt) 1.0.5
>> [root@localhost /]# qemu-kvm --version
>> QEMU emulator version 1.4.1, Copyright (c) 2003-2008 Fabrice Bellard
>> [root@localhost /]# uname -a
>> Linux localhost.localdomain 3.9.2-301.fc19.x86_64 #1 SMP Mon May 13
>> 12:36:24 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
>>
>>
>> On Tue, Aug 20, 2013 at 6:16 PM, Paolo Bonzini <pbonzini(a)redhat.com>
wrote:
>>> Il 20/08/2013 11:59, Timon Wang ha scritto:
>>>> On Tue, Aug 20, 2013 at 4:33 PM, Paolo Bonzini
<pbonzini(a)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 dev='hda' bus='ide'/>
>>>>>> <boot order='3'/>
>>>>>> <address type='drive' controller='0'
bus='0' target='0' unit='0'/>
>>>>>> </disk>
>>>>>> <disk type='file' device='cdrom'>
>>>>>> <driver name='qemu' type='raw'/>
>>>>>> <source
file='/home/isos/windows2008_64r2.iso'/>
>>>>>> <target dev='sdc' bus='ide'/>
>>>>>> <readonly/>
>>>>>> <boot order='1'/>
>>>>>> <address type='drive' controller='0'
bus='1' target='0' unit='0'/>
>>>>>> </disk>
>>>>>> <disk type='block' device='disk'>
>>>>>
>>>>> I'm not sure this will be enough, but if you want passthrough to
the
>>>>> host device you should use device='lun' here. However, you
still would
>>>>> not be able to issue SCSI reservations unless you run QEMU with the
>>>>> CAP_SYS_RAWIO capability (using "<disk ...
rawio='yes'>").
>>>>>
>>>>
>>>> After change the libvirt xml like this:
>>>> <disk type='block' device='lun'
rawio='yes'>
>>>> <driver name='qemu' type='raw'
cache='none'/>
>>>> <source
dev='/dev/VM-IMAGES-BACKUP-DO-NOT-REMOVE/q_disk'/>
>>>> <target dev='sda' bus='scsi'/>
>>>> <shareable/>
>>>> <address type='drive' controller='0'
bus='0' target='0' unit='0'/>
>>>> </disk>
>>>> I got these errors:
>>>> char device redirected to /dev/pts/1 (label charserial0)
>>>> 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:
>>>> 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
>>>
>>
>>
>>
>
--
Focus on: Server Vitualization, Network security,Scanner,NodeJS,JAVA,WWW
Blog: http://www.nohouse.net
--
Focus on: Server Vitualization, Network security,Scanner,NodeJS,JAVA,WWW
Blog: http://www.nohouse.net
7:09 a.m.
Il 20/08/2013 13:43, Timon Wang ha scritto:
Thanks, the whole iSCSI LUN have been passed to the VM.
But I test it with scsicmd, and found that the driver may be not
support SPC-3, but if i use this by microsoft 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]
>> EncServ=0 MultiP=0 [MChngr=0] [ACKREQQ=0] Addr16=0
>> [RelAdr=0] WBus16=1 Sync=1 Linked=0 [TranDis=0] CmdQue=1
>> length=36 (0x24) Peripheral device type: disk
>> Vendor identification: MacroSAN
>> Product identification: LU
>> Product revision level: 1.0
>> Unit serial number: 0d9281ae-aea4-6da0-0000-02180142b300
Can you try using a Linux VM and executing sg_inq in the VM?
Paolo
9:11 p.m.
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 [TranDis=0] CmdQue=1
length=36 (0x24) Peripheral device type: disk
Vendor identification: MacroSAN
Product identification: LU
Product revision level: 1.0
Unit serial number: fd01ece6-8540-f4c7-0000-fe170142b300
From the fedora 19 vm:
[root@fedoravm ~]# sg_inq /dev/sdb
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 [TranDis=0] CmdQue=1
length=36 (0x24) Peripheral device type: disk
Vendor identification: MacroSAN
Product identification: LU
Product revision level: 1.0
Unit serial number: fd01ece6-8540-f4c7-0000-fe170142b300
The result from fedora 19 host and fedora 19 vm are the same. It's
that means I got a wrong windows vm scsi pass-through driver?
Or is there any tool like sg_inq in windows 2008?
On Tue, Aug 20, 2013 at 8:09 PM, Paolo Bonzini <pbonzini(a)redhat.com> wrote:
Il 20/08/2013 13:43, Timon Wang ha scritto:
> Thanks, the whole iSCSI LUN have been passed to the VM.
>
> But I test it with scsicmd, and found that the driver may be not
> support SPC-3, but if i use this by microsoft 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]
>>> EncServ=0 MultiP=0 [MChngr=0] [ACKREQQ=0] Addr16=0
>>> [RelAdr=0] WBus16=1 Sync=1 Linked=0 [TranDis=0] CmdQue=1
>>> length=36 (0x24) Peripheral device type: disk
>>> Vendor identification: MacroSAN
>>> Product identification: LU
>>> Product revision level: 1.0
>>> Unit serial number: 0d9281ae-aea4-6da0-0000-02180142b300
Can you try using a Linux VM and executing sg_inq in the VM?
Paolo
--
Focus on: Server Vitualization, Network security,Scanner,NodeJS,JAVA,WWW
Blog: http://www.nohouse.net
4:09 a.m.
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] WBus16=1 Sync=1 Linked=0 [TranDis=0] CmdQue=1
length=36 (0x24) Peripheral device type: disk
Vendor identification: MacroSAN
Product identification: LU
Product revision level: 1.0
Unit serial number: fd01ece6-8540-f4c7-0000-fe170142b300
From the fedora 19 vm:
[root@fedoravm ~]# sg_inq /dev/sdb
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 [TranDis=0] CmdQue=1
length=36 (0x24) Peripheral device type: disk
Vendor identification: MacroSAN
Product identification: LU
Product revision level: 1.0
Unit serial number: fd01ece6-8540-f4c7-0000-fe170142b300
The result from fedora 19 host and fedora 19 vm are the same. It's
that means I got a wrong windows vm scsi pass-through driver?
Or is there any tool like sg_inq in windows 2008?
Yeah, there's something weird in the Windows VM.
sg_inq should be available for Windows too, but I don't know where to
get a precompiled binary from.
Paolo
4:40 a.m.
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] Addr16=0
> [RelAdr=0] WBus16=1 Sync=1 Linked=0 [TranDis=0] CmdQue=1
> length=36 (0x24) Peripheral device type: disk
> Vendor identification: MacroSAN
> Product identification: LU
> Product revision level: 1.0
> Unit serial number: fd01ece6-8540-f4c7-0000-fe170142b300
>
> From the fedora 19 vm:
> [root@fedoravm ~]# sg_inq /dev/sdb
> 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 [TranDis=0] CmdQue=1
> length=36 (0x24) Peripheral device type: disk
> Vendor identification: MacroSAN
> Product identification: LU
> Product revision level: 1.0
> Unit serial number: fd01ece6-8540-f4c7-0000-fe170142b300
>
> The result from fedora 19 host and fedora 19 vm are the same. It's
> that means I got a wrong windows vm scsi pass-through driver?
> Or is there any tool like sg_inq in windows 2008?
Yeah, there's something weird in the Windows VM.
sg_inq should be available for Windows too, but I don't know where to
get a precompiled binary from.
AFAIK, the latest sg3-utils build for MSFT is here:
http://sg.danny.cz/sg/p/sg3_utils-1.36exe.zip
--nab
2:46 a.m.
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(a)linux-iscsi.org> wrote:
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] Addr16=0
> > [RelAdr=0] WBus16=1 Sync=1 Linked=0 [TranDis=0] CmdQue=1
> > length=36 (0x24) Peripheral device type: disk
> > Vendor identification: MacroSAN
> > Product identification: LU
> > Product revision level: 1.0
> > Unit serial number: fd01ece6-8540-f4c7-0000-fe170142b300
> >
> > From the fedora 19 vm:
> > [root@fedoravm ~]# sg_inq /dev/sdb
> > 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 [TranDis=0] CmdQue=1
> > length=36 (0x24) Peripheral device type: disk
> > Vendor identification: MacroSAN
> > Product identification: LU
> > Product revision level: 1.0
> > Unit serial number: fd01ece6-8540-f4c7-0000-fe170142b300
> >
> > The result from fedora 19 host and fedora 19 vm are the same. It's
> > that means I got a wrong windows vm scsi pass-through driver?
> > Or is there any tool like sg_inq in windows 2008?
>
> Yeah, there's something weird in the Windows VM.
>
> sg_inq should be available for Windows too, but I don't know where to
> get a precompiled binary from.
>
AFAIK, the latest sg3-utils build for MSFT is here:
http://sg.danny.cz/sg/p/sg3_utils-1.36exe.zip
--nab
--
Focus on: Server Vitualization, Network security,Scanner,NodeJS,JAVA,WWW
Blog: http://www.nohouse.net
4:02 a.m.
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 ("lsisas1078" in
libvirt) instead of virtio-scsi?
Paolo
9:44 p.m.
I don't know if lsisas1078 controller in qemu is not work property or
I did not configure it correct.
Sometimes I can see the lun which passed to the vm, sometimes not.
I have tried that controller before, and sometimes the vm will crash
because qemu process quit, but I did not get the detail logs about the
process quit.
I am wondering if lsisas1078 is still not stable or I did not config it right.
On Thu, Aug 22, 2013 at 5:02 PM, Paolo Bonzini <pbonzini(a)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 megaraid sas controller ("lsisas1078" in
libvirt) instead of virtio-scsi?
Paolo
--
Focus on: Server Vitualization, Network security,Scanner,NodeJS,JAVA,WWW
Blog: http://www.nohouse.net
5:29 a.m.
> 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 of kvm process.
# ps -C qemu-system-x86_64 -o pid=
5177
2. Check the capability for the process.
# getpcaps 5177
Capabilities for `5177': = cap_sys_rawio+i
In my fedora19 environment, as seen in above, only cap_sys_rawio+i was added
with rawio='yes'. Even though, cap_sys_rawio+ep is required to pass-through
SCSI Reservation from the guest.
Note that I succeeded to pass-through SCSI Reservation with the following steps
in my environment, not a Windows guest though.
1. Stop the guest.
2. Add CAP_SYS_RAWIO(effective, permitted) to qemu-kvm.
# setcap cap_sys_rawio=ep /usr/bin/qemu-system-x86_64
3. Start the guest.
However, I don't think this is the right way to workaround it, because it
gives cap_sys_rawio+ep to all the kvm processes executed from this binary.
I believe following patches, which are not merged yet, are trying to solve
this problem in a different approach.
- [PATCH v3 part2] Add per-device sysfs knob to enable unrestricted,
unprivileged SG_IO
https://lkml.org/lkml/2013/5/23/294
- [RFC PATCH 0/4] SG_IO filtering via sysfs and minimal whitelist
https://lkml.org/lkml/2013/5/27/230
Any comments on this?
Masaki
6:07 a.m.
Il 27/08/2013 12:29, Masaki Kimura ha scritto:
I believe following patches, which are not merged yet, are trying to
solve
this problem in a different approach.
- [PATCH v3 part2] Add per-device sysfs knob to enable unrestricted,
unprivileged SG_IO
https://lkml.org/lkml/2013/5/23/294
- [RFC PATCH 0/4] SG_IO filtering via sysfs and minimal whitelist
https://lkml.org/lkml/2013/5/27/230
Any comments on this?
Yes, that's correct.
Paolo
7:09 a.m.
Thanks, all the test in SCSICMD.exe can pass now, when I set the ep
caps on qemu process.
We found that sg_persist --read-keys can't get the same result in VM
and host, and now we get the same result in both VM and host mode.
But Windows 2008 Failover Cluster Still can't get the cluster disk
configured, with some error said that the driver can't support the
cluster.
Thanks, I think I have dig into the windows Failover Cluster to find
why it can't support cluster, I will ask somebody in MSDN.
On Tue, Aug 27, 2013 at 7:07 PM, Paolo Bonzini <pbonzini(a)redhat.com> wrote:
Il 27/08/2013 12:29, Masaki Kimura ha scritto:
> I believe following patches, which are not merged yet, are trying to solve
> this problem in a different approach.
> - [PATCH v3 part2] Add per-device sysfs knob to enable unrestricted,
> unprivileged SG_IO
> https://lkml.org/lkml/2013/5/23/294
> - [RFC PATCH 0/4] SG_IO filtering via sysfs and minimal whitelist
> https://lkml.org/lkml/2013/5/27/230
>
>
> Any comments on this?
Yes, that's correct.
Paolo
--
Focus on: Server Vitualization, Network security,Scanner,NodeJS,JAVA,WWW
Blog: http://www.nohouse.net
4056
days inactive
4081
days old
31 comments
6 participants
participants (6)
-
Don Koch -
Masaki Kimura -
Nicholas A. Bellinger -
Paolo Bonzini -
Stefan Hajnoczi -
Timon Wang