scsi_vhci driver support for EMC DMX3

Does the Sun Storedge Traffic Manager support EMC DMX3 devices? How
does SVM handles the multipathing in case if the metadevice is created
on one path and that fails?
I understand that the psuedo device naming convention takes care of the
meta devices in case if they are Sun Storage devices. As of now format
lists both the EMC devices are separate luns and not by a pseudo lun.
By editing the scsi_vhci.conf file and adding the product and vendor
id, should I be able to get Multipathing working? I have already some
metadevices that were configured on one path. Lets say if c2 and c3 are
the original controllers and c6 is a psuedo device, how will the
metadevices created on c2 work once I enable the multipathing and
psuedo devices come into picture in the device tree. Will SVM rebuild
its metadevice information upon reboot automatically?

Thanks

wrote:
Does the Sun Storedge Traffic Manager support EMC DMX3 devices? How
does SVM handles the multipathing in case if the metadevice is created
on one path and that fails?
I understand that the psuedo device naming convention takes care of the
meta devices in case if they are Sun Storage devices. As of now format
lists both the EMC devices are separate luns and not by a pseudo lun.
By editing the scsi_vhci.conf file and adding the product and vendor
id, should I be able to get Multipathing working? I have already some
metadevices that were configured on one path. Lets say if c2 and c3 are
the original controllers and c6 is a psuedo device, how will the
metadevices created on c2 work once I enable the multipathing and
psuedo devices come into picture in the device tree. Will SVM rebuild
its metadevice information upon reboot automatically?

Thanks

To add

Qlogic HBA's and Sun Leadville drivers are being used

wrote:
wrote:
Does the Sun Storedge Traffic Manager support EMC DMX3 devices? How
does SVM handles the multipathing in case if the metadevice is created
on one path and that fails?
I understand that the psuedo device naming convention takes care of the
meta devices in case if they are Sun Storage devices. As of now format
lists both the EMC devices are separate luns and not by a pseudo lun.
By editing the scsi_vhci.conf file and adding the product and vendor
id, should I be able to get Multipathing working? I have already some
metadevices that were configured on one path. Lets say if c2 and c3 are
the original controllers and c6 is a psuedo device, how will the
metadevices created on c2 work once I enable the multipathing and
psuedo devices come into picture in the device tree. Will SVM rebuild
its metadevice information upon reboot automatically?

Thanks

To add

Qlogic HBA's and Sun Leadville drivers are being used

I am doing some googling and saw some posts that said, if you have EMC
PP you are covered. I understand that EMC's PP is a multpathing
software. How ever, I am trying ot figure out how a metadevice d111
created on c2t20d101s0 will automatically start pointing d111 to
c3t21d101s0 if there is a HBA failure that corresponds to controller
c2. I know veritas dmp does that by looking at the serial numbers on
the disk and figures that c2 is down and pushes traffic throught c3.
veritas does know that c2 and c3 are pointing to the same lun and lists
only one device (c2/c3) in vxdisk list output. Does EMC's PP
automatically update the SVM daemon about the path failure and SVM
starts sending I/O through the other Channel? or will SVM keep sending
I/O as per info it has and PP intercepts it and makes a decision about
how the data should be sent? (In this case send the data through the
live channel)

In comp.unix.solaris wrote:
I am doing some googling and saw some posts that said, if you have EMC
PP you are covered. I understand that EMC's PP is a multpathing
software. How ever, I am trying ot figure out how a metadevice d111
created on c2t20d101s0 will automatically start pointing d111 to
c3t21d101s0 if there is a HBA failure that corresponds to controller
c2. I know veritas dmp does that by looking at the serial numbers on
the disk and figures that c2 is down and pushes traffic throught c3.
veritas does know that c2 and c3 are pointing to the same lun and lists
only one device (c2/c3) in vxdisk list output. Does EMC's PP
automatically update the SVM daemon about the path failure and SVM
starts sending I/O through the other Channel? or will SVM keep sending
I/O as per info it has and PP intercepts it and makes a decision about
how the data should be sent? (In this case send the data through the
live channel)

I dunno about powerpath but MPxIO is free. I tried out 2 days ago and
it worked fine (we're still a VxVM shop though).

- make sure you can see the devices with 'cfgadm'
- run 'echo | format' - you should see 2 paths
- run 'format' and 'inq' about one of the luns
- use the vendor-id & product-id tags in scsi_vhci.conf (refer to the
sun storage foundation manual on docs.sun.com for more details)
- stmsboot -e
- reboot

run format and you should see 1/2 the luns there (multi-pathing is
working!).

stmsboot -L

That's about all it took for me. The tricky part is setting up the scsi_vhci.conf
file. When I made a small typo I could only get MPxIO to work by disabling and
re-enabling it.

Sanjay wrote:
In comp.unix.solaris wrote:
I am doing some googling and saw some posts that said, if you have EMC
PP you are covered. I understand that EMC's PP is a multpathing
software. How ever, I am trying ot figure out how a metadevice d111
created on c2t20d101s0 will automatically start pointing d111 to
c3t21d101s0 if there is a HBA failure that corresponds to controller
c2. I know veritas dmp does that by looking at the serial numbers on
the disk and figures that c2 is down and pushes traffic throught c3.
veritas does know that c2 and c3 are pointing to the same lun and lists
only one device (c2/c3) in vxdisk list output. Does EMC's PP
automatically update the SVM daemon about the path failure and SVM
starts sending I/O through the other Channel? or will SVM keep sending
I/O as per info it has and PP intercepts it and makes a decision about
how the data should be sent? (In this case send the data through the
live channel)

I dunno about powerpath but MPxIO is free. I tried out 2 days ago and
it worked fine (we're still a VxVM shop though).

- make sure you can see the devices with 'cfgadm'
- run 'echo | format' - you should see 2 paths
- run 'format' and 'inq' about one of the luns
- use the vendor-id & product-id tags in scsi_vhci.conf (refer to the
sun storage foundation manual on docs.sun.com for more details)
- stmsboot -e
- reboot

run format and you should see 1/2 the luns there (multi-pathing is
working!).

stmsboot -L

That's about all it took for me. The tricky part is setting up the scsi_vhci.conf
file. When I made a small typo I could only get MPxIO to work by disabling and
re-enabling it.

I understood getting the MPxIO part working. How ever, I can use EMC
PP. What I am trying to understand is how SVM and EMC PP work in case
of a HBA oranything that results in a path failure. More precisely, if
a metadevice is created on c2t20d101s0 and HBA corresponding to
controller c2 fails, How does SVM figure out to send I/O down
c3t21d101s0? (or) SVM doesnt figure it out and PP intercepts I/O bound
for c2 and sends it down c3

Thanks

With MPxIO what happens is that you end up with virtual devices listed
in format and you create your metas using the virtual devices. The
virtual devices are identified by looking at the device path in format.
They wiill have "vhci" in the device path. If you still see QLGC or the
likes in the device path then multipathing is not working for that
disk.

The vhci devices handle the multipathing. You can see primary and
secondary device paths for those vhci disks using luxadm.

Regards,
Vic Engle



wrote:
Sanjay wrote:
In comp.unix.solaris wrote:
I am doing some googling and saw some posts that said, if you have EMC
PP you are covered. I understand that EMC's PP is a multpathing
software. How ever, I am trying ot figure out how a metadevice d111
created on c2t20d101s0 will automatically start pointing d111 to
c3t21d101s0 if there is a HBA failure that corresponds to controller
c2. I know veritas dmp does that by looking at the serial numbers on
the disk and figures that c2 is down and pushes traffic throught c3.
veritas does know that c2 and c3 are pointing to the same lun and lists
only one device (c2/c3) in vxdisk list output. Does EMC's PP
automatically update the SVM daemon about the path failure and SVM
starts sending I/O through the other Channel? or will SVM keep sending
I/O as per info it has and PP intercepts it and makes a decision about
how the data should be sent? (In this case send the data through the
live channel)

I dunno about powerpath but MPxIO is free. I tried out 2 days ago and
it worked fine (we're still a VxVM shop though).

- make sure you can see the devices with 'cfgadm'
- run 'echo | format' - you should see 2 paths
- run 'format' and 'inq' about one of the luns
- use the vendor-id & product-id tags in scsi_vhci.conf (refer to the
sun storage foundation manual on docs.sun.com for more details)
- stmsboot -e
- reboot

run format and you should see 1/2 the luns there (multi-pathing is
working!).

stmsboot -L

That's about all it took for me. The tricky part is setting up the scsi_vhci.conf
file. When I made a small typo I could only get MPxIO to work by disabling and
re-enabling it.

I understood getting the MPxIO part working. How ever, I can use EMC
PP. What I am trying to understand is how SVM and EMC PP work in case
of a HBA oranything that results in a path failure. More precisely, if
a metadevice is created on c2t20d101s0 and HBA corresponding to
controller c2 fails, How does SVM figure out to send I/O down
c3t21d101s0? (or) SVM doesnt figure it out and PP intercepts I/O bound
for c2 and sends it down c3

Thanks

wrote:
With MPxIO what happens is that you end up with virtual devices listed
in format and you create your metas using the virtual devices. The
virtual devices are identified by looking at the device path in format.
They wiill have "vhci" in the device path. If you still see QLGC or the
likes in the device path then multipathing is not working for that
disk.

The vhci devices handle the multipathing. You can see primary and
secondary device paths for those vhci disks using luxadm.

Regards,
Vic Engle



wrote:
Sanjay wrote:
In comp.unix.solaris wrote:
I am doing some googling and saw some posts that said, if you have EMC
PP you are covered. I understand that EMC's PP is a multpathing
software. How ever, I am trying ot figure out how a metadevice d111
created on c2t20d101s0 will automatically start pointing d111 to
c3t21d101s0 if there is a HBA failure that corresponds to controller
c2. I know veritas dmp does that by looking at the serial numbers on
the disk and figures that c2 is down and pushes traffic throught c3.
veritas does know that c2 and c3 are pointing to the same lun and lists
only one device (c2/c3) in vxdisk list output. Does EMC's PP
automatically update the SVM daemon about the path failure and SVM
starts sending I/O through the other Channel? or will SVM keep sending
I/O as per info it has and PP intercepts it and makes a decision about
how the data should be sent? (In this case send the data through the
live channel)

I dunno about powerpath but MPxIO is free. I tried out 2 days ago and
it worked fine (we're still a VxVM shop though).

- make sure you can see the devices with 'cfgadm'
- run 'echo | format' - you should see 2 paths
- run 'format' and 'inq' about one of the luns
- use the vendor-id & product-id tags in scsi_vhci.conf (refer to the
sun storage foundation manual on docs.sun.com for more details)
- stmsboot -e
- reboot

run format and you should see 1/2 the luns there (multi-pathing is
working!).

stmsboot -L

That's about all it took for me. The tricky part is setting up the scsi_vhci.conf
file. When I made a small typo I could only get MPxIO to work by disabling and
re-enabling it.

I understood getting the MPxIO part working. How ever, I can use EMC
PP. What I am trying to understand is how SVM and EMC PP work in case
of a HBA oranything that results in a path failure. More precisely, if
a metadevice is created on c2t20d101s0 and HBA corresponding to
controller c2 fails, How does SVM figure out to send I/O down
c3t21d101s0? (or) SVM doesnt figure it out and PP intercepts I/O bound
for c2 and sends it down c3

Thanks

Victor,

I understood how MPxIO works on servers which are going on to SAN for
the first time. How does it work in case if I have a bunch of veritas
diskgroups / SVM metadevices which were created on the device hierarchy
as seen before MPxIO. I am curious if it can still relate to the old
devices. More precisely, lets say c2 and c3 are the original
controllers and some meta devices / volumes were created based on
these. How does SVM handle it if the pseudo device controller is c6.
VxVM does have the disk media name option which will remain the same,
but VxVM can relate to the change and point the new device to the old
media name. I am not sure it works in case of meta devices from SVM. I
dont have a test box handy to test it. May be MPxIO will still see the
metadevices through c2 and c3 and format might be the only one thats
showing the psuedo controller.