Hi,
I created an HVM type virtual machine and installed RHEL5U7
guest in it. I have assigned 7 scsi disks to the virtual machine in
physical mode (using phy:), however, I see those disks are xvd and not
as scsi.
Is anyone aware what the problem might be ? Please let me know
what kind of information do I need to post in order to narrow down to
the problem.
Thanks,
K
K Mehta wrote:> I created an HVM type virtual machine and installed RHEL5U7 >guest in it. I have assigned 7 scsi disks to the virtual machine in >physical mode (using phy:), however, I see those disks are xvd and not >as scsi. > Is anyone aware what the problem might be ?There isn''t one. All guest disks appear to the guest as xvd devices regardless of the underlying disk type. I believe this is done to avoid potential conflicts with real devices. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books.
Simon.. thanks for your reply.
The problem is that scsi commands are failing on xvd devices.
Few hours ago i renamed xvd devices are sd* devices in vm config file.
scsi inquiry, TUR and few other commands are working on those sd*
devices in the guest. However, scsi reservation commands (executed
using sg util) are failing with error "bad field in cdb including
unsupported service action".
Are some additional steps required to make scsi3 disks visible as
scsi3 in the guest. Or we just need to include line like this
->''phy:/dev/mapper/360060e80056509000000650900000260,xvdf,w!''
in
the config file for each scsi3 disk..????
(I replaced xvdf with sdf in the above line and few commands {scsi
inquiry/tur/read capacity} worked)
On Mon, Jan 16, 2012 at 2:53 PM, Simon Hobson <linux@thehobsons.co.uk>
wrote:> K Mehta wrote:
>
>> I created an HVM type virtual machine and installed RHEL5U7
>> guest in it. I have assigned 7 scsi disks to the virtual machine in
>> physical mode (using phy:), however, I see those disks are xvd and not
>> as scsi.
>> Is anyone aware what the problem might be ?
>
>
> There isn''t one. All guest disks appear to the guest as xvd
devices
> regardless of the underlying disk type. I believe this is done to avoid
> potential conflicts with real devices.
> --
> Simon Hobson
>
> Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
> author Gladys Hobson. Novels - poetry - short stories - ideal as
> Christmas stocking fillers. Some available as e-books.
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
On Mon, Jan 16, 2012 at 6:32 PM, K Mehta <kiranmehta1981@gmail.com> wrote:> Simon.. thanks for your reply. > > The problem is that scsi commands are failing on xvd devices. > Few hours ago i renamed xvd devices are sd* devices in vm config file. > scsi inquiry, TUR and few other commands are working on those sd* > devices in the guest. However, scsi reservation commands (executed > using sg util) are failing with error "bad field in cdb including > unsupported service action".That is expected behavior.> > Are some additional steps required to make scsi3 disks visible as > scsi3 in the guest. Or we just need to include line like this > ->''phy:/dev/mapper/360060e80056509000000650900000260,xvdf,w!'' in > the config file for each scsi3 disk..????Nope. There''s this: http://wiki.xen.org/wiki/Paravirtualized_SCSI but AFAIK it''s not available on RHEL5''s kernel and xen version. You MIGHT find it easier to use iscsi (export on dom0, import on domU) with support for scsi passthru (e.g. tgt) -- Fajar
Ok. 1. So does it mean that installing some recent version of Redhat/SuSE will make (fibre channel) scsi3 disks visible as scsi3 in the guest 2. Or does it mean that guest OS will never be able to see fibre channel scsi3 disks (made visible from Dom0) as scsi3 whatever OS version I install ? 3. If i make scsi3 disks visible to guest directly (not through Dom0), will guest be expected to see it as scsi3 ? (I think it should !!!) Thanks, kiran On Mon, Jan 16, 2012 at 5:19 PM, Fajar A. Nugraha <list@fajar.net> wrote:> On Mon, Jan 16, 2012 at 6:32 PM, K Mehta <kiranmehta1981@gmail.com> wrote: >> Simon.. thanks for your reply. >> >> The problem is that scsi commands are failing on xvd devices. >> Few hours ago i renamed xvd devices are sd* devices in vm config file. >> scsi inquiry, TUR and few other commands are working on those sd* >> devices in the guest. However, scsi reservation commands (executed >> using sg util) are failing with error "bad field in cdb including >> unsupported service action". > > That is expected behavior. > >> >> Are some additional steps required to make scsi3 disks visible as >> scsi3 in the guest. Or we just need to include line like this >> ->''phy:/dev/mapper/360060e80056509000000650900000260,xvdf,w!'' in >> the config file for each scsi3 disk..???? > > Nope. > > There''s this: http://wiki.xen.org/wiki/Paravirtualized_SCSI > but AFAIK it''s not available on RHEL5''s kernel and xen version. You > MIGHT find it easier to use iscsi (export on dom0, import on domU) > with support for scsi passthru (e.g. tgt) > > -- > Fajar
3rd bullet: If i make scsi3 disks visible to guest directly using iscsi(not through Dom0), will guest be expected to see it as scsi3 ? (I think it should !!!) On Mon, Jan 16, 2012 at 5:41 PM, K Mehta <kiranmehta1981@gmail.com> wrote:> Ok. > > 1. So does it mean that installing some recent version of Redhat/SuSE > will make (fibre channel) scsi3 disks visible > as scsi3 in the guest > > 2. Or does it mean that guest OS will never be able to see fibre > channel scsi3 disks (made visible from Dom0) as scsi3 whatever OS > version I install ? > > > 3. If i make scsi3 disks visible to guest directly (not through Dom0), > will guest be expected to see it as scsi3 ? (I think it should !!!) > > > Thanks, > kiran > > On Mon, Jan 16, 2012 at 5:19 PM, Fajar A. Nugraha <list@fajar.net> wrote: >> On Mon, Jan 16, 2012 at 6:32 PM, K Mehta <kiranmehta1981@gmail.com> wrote: >>> Simon.. thanks for your reply. >>> >>> The problem is that scsi commands are failing on xvd devices. >>> Few hours ago i renamed xvd devices are sd* devices in vm config file. >>> scsi inquiry, TUR and few other commands are working on those sd* >>> devices in the guest. However, scsi reservation commands (executed >>> using sg util) are failing with error "bad field in cdb including >>> unsupported service action". >> >> That is expected behavior. >> >>> >>> Are some additional steps required to make scsi3 disks visible as >>> scsi3 in the guest. Or we just need to include line like this >>> ->''phy:/dev/mapper/360060e80056509000000650900000260,xvdf,w!'' in >>> the config file for each scsi3 disk..???? >> >> Nope. >> >> There''s this: http://wiki.xen.org/wiki/Paravirtualized_SCSI >> but AFAIK it''s not available on RHEL5''s kernel and xen version. You >> MIGHT find it easier to use iscsi (export on dom0, import on domU) >> with support for scsi passthru (e.g. tgt) >> >> -- >> Fajar
On Mon, Jan 16, 2012 at 7:11 PM, K Mehta <kiranmehta1981@gmail.com> wrote:> Ok. > > 1. So does it mean that installing some recent version of Redhat/SuSE > will make (fibre channel) scsi3 disks visible > as scsi3 in the guestSee the wiki link. If the OS has a kernel & xen version that supports pvscsi, then it should be so> > 2. Or does it mean that guest OS will never be able to see fibre > channel scsi3 disks (made visible from Dom0) as scsi3 whatever OS > version I install ?Nope.> 3. If i make scsi3 disks visible to guest directly (not through Dom0), > will guest be expected to see it as scsi3 ? (I think it should !!!)Probably, but you''d need to passthru the whole controller (PCI passthru). Which I doubt you can. -- Fajar
Hi, I tried this on Oracle VM 3.0 which is based on xen sles11sp1:~ # sg_persist /dev/sg1>> No service action given; assume Persistent Reserve In command >> with Read Keys service actionATA QEMU HARDDISK 0.10 Peripheral device type: disk PR in: command not supported sles11sp1:~ # sg_readcap /dev/sg1 Read Capacity results: Last logical block address=31457279 (0x1dfffff), Number of blocks=31457280 Logical block length=512 bytes Hence: Device size: 16106127360 bytes, 15360.0 MiB, 16.11 GB sles11sp1:~ # lsmod | grep scsi scsi_tgt 12875 0 vmw_pvscsi 18562 0 scsi_mod 183796 6 scsi_tgt,vmw_pvscsi,sg,sr_mod,sd_mod,libata sles11sp1:~ # lsmod | grep pv vmw_pvscsi 18562 0 ipv6 323245 50 scsi_mod 183796 6 scsi_tgt,vmw_pvscsi,sg,sr_mod,sd_mod,libata sles11sp1:~ # uname -a Linux sles11sp1 2.6.32.12-0.7-default #1 SMP 2010-05-20 11:14:20 +0200 x86_64 x86_64 x86_64 GNU/Linux xen version = 2.6.32.21-41xen Any hints why scsi reservation commands are failing ? On Mon, Jan 16, 2012 at 5:46 PM, Fajar A. Nugraha <list@fajar.net> wrote:> On Mon, Jan 16, 2012 at 7:11 PM, K Mehta <kiranmehta1981@gmail.com> wrote: >> Ok. >> >> 1. So does it mean that installing some recent version of Redhat/SuSE >> will make (fibre channel) scsi3 disks visible >> as scsi3 in the guest > > See the wiki link. If the OS has a kernel & xen version that supports > pvscsi, then it should be so > >> >> 2. Or does it mean that guest OS will never be able to see fibre >> channel scsi3 disks (made visible from Dom0) as scsi3 whatever OS >> version I install ? > > Nope. > >> 3. If i make scsi3 disks visible to guest directly (not through Dom0), >> will guest be expected to see it as scsi3 ? (I think it should !!!) > > Probably, but you''d need to passthru the whole controller (PCI > passthru). Which I doubt you can. > > -- > Fajar
> > Any hints why scsi reservation commands are failing ? >These commands (and a bunch of others) are blocked by scsiback. Not for any particular reason though so if you can recompile the module it is easy to fix... just uncomment the lines in the emulate.c file. James
would same (scsi reserve commands not working) be the case with PVHVM and PV type virtual machines ? On Tue, Jan 17, 2012 at 3:06 PM, James Harper <james.harper@bendigoit.com.au> wrote:>> >> Any hints why scsi reservation commands are failing ? >> > > These commands (and a bunch of others) are blocked by scsiback. Not for any particular reason though so if you can recompile the module it is easy to fix... just uncomment the lines in the emulate.c file. > > James
> > would same (scsi reserve commands not working) be the case with PVHVM > and PV type virtual machines ? >If you are talking about scsi passthrough then it is the same for all types of domains. If you are using pci passthrough to pass through the entire hba or if you are passing through the block device but want it to appear as sdX instead of xvdX then I don''t know. What I said only applied to the scsi passthrough which I thought was what you were talking about. James
Maybe Matching Threads
- LVM Checksum error when using persistent grants (#linux-next + stable/for-jens-3.8)
- getting a CentOS6 VM on VMware ESXi platform to recognize a new disk device
- getting a CentOS6 VM on VMware ESXi platform to recognize a new disk device
- Problems with the rsync command line syntax for multiple files
- What is mclust up to? Different clusters found if x and y interchanged