Redundant VIOS and disk mapping - Aix

This is a discussion on Redundant VIOS and disk mapping - Aix ; Hi one of our p595 have two vios and many san disks mapped from both vios. Some days ago, we try to add some new LUNs to both vios - no problem. Next step was to map the new "disks" ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Redundant VIOS and disk mapping

  1. Redundant VIOS and disk mapping

    Hi

    one of our p595 have two vios and many san disks mapped from both vios.
    Some days ago, we try to add some new LUNs to both vios - no problem.
    Next step was to map the new "disks" to a lpar with the mkvdev-command
    which is successful from one vio - I can see the new disks on the lpar
    and add it to an existing vg.
    Try to map these disks from the second vio to the lpar - its impossible,
    because mkvdev commands says "Can't access device". It think this should
    a kind of lock or reservation ?
    Next we found that both vios must updated with FP9.2 (updateios ...),
    but which steps we should do for this update ?

    Thinking about the following:

    1. remove all applied efixes (emgr ...)
    2. remove the complete disk mapping on both vios
    (what's about the hdisks itself on the vios - must they be deleted by
    rmdev -Rdl hdiskxx or is remove mapping the only step to do ???)
    3. update vios with *updateios -dev /mountpoint of fp92 -accept -install
    4. recreate the mapping from both vios to the lpars

    Is this the correct way to do so ?
    What's about the real data on the defined vgs on the lpars ?
    (are they still there after recreate the mapping or must we done a
    backup/restore ?)
    Is there a cfgmgr on the vios neccessary after the update to bring back
    the hdisks on vios ?
    Will the hdisk numbers the same as before ?

    Thx in advance
    Friedhelm



  2. Re: Redundant VIOS and disk mapping

    Friedhelm Neyer wrote:
    > Hi
    >
    > one of our p595 have two vios and many san disks mapped from both vios.
    > Some days ago, we try to add some new LUNs to both vios - no problem.
    > Next step was to map the new "disks" to a lpar with the mkvdev-command
    > which is successful from one vio - I can see the new disks on the lpar
    > and add it to an existing vg.
    > Try to map these disks from the second vio to the lpar - its impossible,
    > because mkvdev commands says "Can't access device". It think this should
    > a kind of lock or reservation ?
    > Next we found that both vios must updated with FP9.2 (updateios ...),
    > but which steps we should do for this update ?
    >
    > Thinking about the following:
    >
    > 1. remove all applied efixes (emgr ...)
    > 2. remove the complete disk mapping on both vios
    > (what's about the hdisks itself on the vios - must they be deleted by
    > rmdev -Rdl hdiskxx or is remove mapping the only step to do ???)
    > 3. update vios with *updateios -dev /mountpoint of fp92 -accept -install
    > 4. recreate the mapping from both vios to the lpars
    >
    > Is this the correct way to do so ?
    > What's about the real data on the defined vgs on the lpars ?
    > (are they still there after recreate the mapping or must we done a
    > backup/restore ?)
    > Is there a cfgmgr on the vios neccessary after the update to bring back
    > the hdisks on vios ?
    > Will the hdisk numbers the same as before ?
    >
    > Thx in advance
    > Friedhelm
    >
    >


    First of all, what kind of storage do you have?

    We have DS8100 storage attached to our p595's and their vio servers, and
    never ran into this problem. BTW, cfgdev is your "cfgmgr" on the vio
    server using the padmin account. Also, choose a lun on the good vio
    server, change to "oem_setup_env", and run "lsattr -El hdiskX" to see if
    you are having SCSI reservation issues. Look for the "reserve_policy"
    attribute. I highly doubt it, but it never hurts to check.

    Some important things to remember:

    1. Make sure that your storage is set up to be seen by both vio
    servers. You have to explicitly define your luns with that in mind. On
    the DS8100, I have a "volume group" which contains both vio servers'
    host attachment information. I add luns to that group and my storage
    shows up on both.

    2. Once you get the luns seen by both vio servers, always verify that
    they appear in the same order as they do on the first vio server, i.e,
    hdisk4 on vio1 is the same lun as hdisk4 on vio2. If not, you are in
    for a nightmare of trying to keep track. I have never seen them not
    show up in order, but it never hurts to check.

    If you don't find anything with this information, let us know what kind
    of storage you are using, along with the type of switchwork you are
    using as well. All of my expertise is with the IBM DS8XXX hardware, but
    if you post about other hardware, there is somebody else in here that
    will chime in.

  3. Re: Redundant VIOS and disk mapping

    On 24 Aug, 10:35, 0xdeadabe wrote:
    > Friedhelm Neyer wrote:
    > > Hi

    >
    > > one of our p595 have two vios and many san disks mapped from both vios.
    > > Some days ago, we try to add some new LUNs to both vios - no problem.
    > > Next step was to map the new "disks" to a lpar with the mkvdev-command
    > > which is successful from one vio - I can see the new disks on the lpar
    > > and add it to an existing vg.
    > > Try to map these disks from the second vio to the lpar - its impossible,
    > > because mkvdev commands says "Can't access device". It think this should
    > > a kind of lock or reservation ?
    > > Next we found that both vios must updated with FP9.2 (updateios ...),
    > > but which steps we should do for this update ?

    >
    > > Thinking about the following:

    >
    > > 1. remove all applied efixes (emgr ...)
    > > 2. remove the complete disk mapping on both vios
    > > (what's about the hdisks itself on the vios - must they be deleted by
    > > rmdev -Rdl hdiskxx or is remove mapping the only step to do ???)
    > > 3. update vios with *updateios -dev /mountpoint of fp92 -accept -install
    > > 4. recreate the mapping from both vios to the lpars

    >
    > > Is this the correct way to do so ?
    > > What's about the real data on the defined vgs on the lpars ?
    > > (are they still there after recreate the mapping or must we done a
    > > backup/restore ?)
    > > Is there a cfgmgr on the vios neccessary after the update to bring back
    > > the hdisks on vios ?
    > > Will the hdisk numbers the same as before ?

    >
    > > Thx in advance
    > > Friedhelm

    >
    > First of all, what kind of storage do you have?
    >
    > We have DS8100 storage attached to our p595's and their vio servers, and
    > never ran into this problem. BTW, cfgdev is your "cfgmgr" on the vio
    > server using the padmin account. Also, choose a lun on the good vio
    > server, change to "oem_setup_env", and run "lsattr -El hdiskX" to see if
    > you are having SCSI reservation issues. Look for the "reserve_policy"
    > attribute. I highly doubt it, but it never hurts to check.
    >
    > Some important things to remember:
    >
    > 1. Make sure that your storage is set up to be seen by both vio
    > servers. You have to explicitly define your luns with that in mind. On
    > the DS8100, I have a "volume group" which contains both vio servers'
    > host attachment information. I add luns to that group and my storage
    > shows up on both.
    >
    > 2. Once you get the luns seen by both vio servers, always verify that
    > they appear in the same order as they do on the first vio server, i.e,
    > hdisk4 on vio1 is the same lun as hdisk4 on vio2. If not, you are in
    > for a nightmare of trying to keep track. I have never seen them not
    > show up in order, but it never hurts to check.
    >
    > If you don't find anything with this information, let us know what kind
    > of storage you are using, along with the type of switchwork you are
    > using as well. All of my expertise is with the IBM DS8XXX hardware, but
    > if you post about other hardware, there is somebody else in here that
    > will chime in.- Hide quoted text -
    >
    > - Show quoted text -


    See here for the updating to FP9.2

    http://www14.software.ibm.com/webapp...d/fixpack.html

    You dont need to remove any disks/mappings at all. Just make sure
    your virtual lpar's are either shutdown or that they can failover to
    your second VIO server while you update the first.

    We are on VIO 1.3.0.0 (no FP's) and use DS4500's (I think) and we can
    see the same LUN on both VIO's and run mkvdev on both VIO's
    successfully using the same LUN.

    It doesnt sound like a VIO level issue to me.

    Regards,
    Scott


  4. Re: Redundant VIOS and disk mapping

    0xdeadabe schrieb:
    > Friedhelm Neyer wrote:
    >> Hi
    >>
    >> one of our p595 have two vios and many san disks mapped from both vios.
    >> Some days ago, we try to add some new LUNs to both vios - no problem.
    >> Next step was to map the new "disks" to a lpar with the mkvdev-command
    >> which is successful from one vio - I can see the new disks on the lpar
    >> and add it to an existing vg.
    >> Try to map these disks from the second vio to the lpar - its
    >> impossible, because mkvdev commands says "Can't access device". It
    >> think this should a kind of lock or reservation ?
    >> Next we found that both vios must updated with FP9.2 (updateios ...),
    >> but which steps we should do for this update ?
    >>
    >> Thinking about the following:
    >>
    >> 1. remove all applied efixes (emgr ...)
    >> 2. remove the complete disk mapping on both vios
    >> (what's about the hdisks itself on the vios - must they be deleted by
    >> rmdev -Rdl hdiskxx or is remove mapping the only step to do ???)
    >> 3. update vios with *updateios -dev /mountpoint of fp92 -accept -install
    >> 4. recreate the mapping from both vios to the lpars
    >>
    >> Is this the correct way to do so ?
    >> What's about the real data on the defined vgs on the lpars ?
    >> (are they still there after recreate the mapping or must we done a
    >> backup/restore ?)
    >> Is there a cfgmgr on the vios neccessary after the update to bring
    >> back the hdisks on vios ?
    >> Will the hdisk numbers the same as before ?
    >>
    >> Thx in advance
    >> Friedhelm
    >>
    >>

    >
    > First of all, what kind of storage do you have?


    We have HDS storage and - forgot before - we should install the hds mpio
    driver package 5.4.0.0. and 5.4.0.1

    > We have DS8100 storage attached to our p595's and their vio servers, and
    > never ran into this problem.


    Before we add 8 new luns to the two vios, we have more than 150 luns in
    this configuration, mapped to 10 lpars and they were mapped correct from
    botz vios, so I don't understand, why the the new luns can't mapped in
    the same way as the old disks ...

    > BTW, cfgdev is your "cfgmgr" on the vio
    > server using the padmin account. Also, choose a lun on the good vio
    > server, change to "oem_setup_env", and run "lsattr -El hdiskX" to see if
    > you are having SCSI reservation issues. Look for the "reserve_policy"
    > attribute. I highly doubt it, but it never hurts to check.


    Have check this point and the disks are at reserve_policy=no_reserve
    nevertheless we are unable to map a disk from the second vio to a lpar,
    when it was just mapped from the first vio

    > Some important things to remember:
    >
    > 1. Make sure that your storage is set up to be seen by both vio
    > servers. You have to explicitly define your luns with that in mind. On
    > the DS8100, I have a "volume group" which contains both vio servers'
    > host attachment information. I add luns to that group and my storage
    > shows up on both.


    All the disks were seen by both vios with the same lun

    > 2. Once you get the luns seen by both vio servers, always verify that
    > they appear in the same order as they do on the first vio server, i.e,
    > hdisk4 on vio1 is the same lun as hdisk4 on vio2. If not, you are in
    > for a nightmare of trying to keep track. I have never seen them not
    > show up in order, but it never hurts to check.


    Will check it on monday, but I think they are in correct order

    > If you don't find anything with this information, let us know what kind
    > of storage you are using, along with the type of switchwork you are
    > using as well. All of my expertise is with the IBM DS8XXX hardware, but
    > if you post about other hardware, there is somebody else in here that
    > will chime in.


  5. Re: Redundant VIOS and disk mapping

    .... don't know how or why, but try it today again and all works fine...


    0xdeadabe schrieb:
    > Friedhelm Neyer wrote:
    >> Hi
    >>
    >> one of our p595 have two vios and many san disks mapped from both vios.
    >> Some days ago, we try to add some new LUNs to both vios - no problem.
    >> Next step was to map the new "disks" to a lpar with the mkvdev-command
    >> which is successful from one vio - I can see the new disks on the lpar
    >> and add it to an existing vg.
    >> Try to map these disks from the second vio to the lpar - its
    >> impossible, because mkvdev commands says "Can't access device". It
    >> think this should a kind of lock or reservation ?
    >> Next we found that both vios must updated with FP9.2 (updateios ...),
    >> but which steps we should do for this update ?
    >>
    >> Thinking about the following:
    >>
    >> 1. remove all applied efixes (emgr ...)
    >> 2. remove the complete disk mapping on both vios
    >> (what's about the hdisks itself on the vios - must they be deleted by
    >> rmdev -Rdl hdiskxx or is remove mapping the only step to do ???)
    >> 3. update vios with *updateios -dev /mountpoint of fp92 -accept -install
    >> 4. recreate the mapping from both vios to the lpars
    >>
    >> Is this the correct way to do so ?
    >> What's about the real data on the defined vgs on the lpars ?
    >> (are they still there after recreate the mapping or must we done a
    >> backup/restore ?)
    >> Is there a cfgmgr on the vios neccessary after the update to bring
    >> back the hdisks on vios ?
    >> Will the hdisk numbers the same as before ?
    >>
    >> Thx in advance
    >> Friedhelm
    >>
    >>

    >
    > First of all, what kind of storage do you have?
    >
    > We have DS8100 storage attached to our p595's and their vio servers, and
    > never ran into this problem. BTW, cfgdev is your "cfgmgr" on the vio
    > server using the padmin account. Also, choose a lun on the good vio
    > server, change to "oem_setup_env", and run "lsattr -El hdiskX" to see if
    > you are having SCSI reservation issues. Look for the "reserve_policy"
    > attribute. I highly doubt it, but it never hurts to check.
    >
    > Some important things to remember:
    >
    > 1. Make sure that your storage is set up to be seen by both vio
    > servers. You have to explicitly define your luns with that in mind. On
    > the DS8100, I have a "volume group" which contains both vio servers'
    > host attachment information. I add luns to that group and my storage
    > shows up on both.
    >
    > 2. Once you get the luns seen by both vio servers, always verify that
    > they appear in the same order as they do on the first vio server, i.e,
    > hdisk4 on vio1 is the same lun as hdisk4 on vio2. If not, you are in
    > for a nightmare of trying to keep track. I have never seen them not
    > show up in order, but it never hurts to check.
    >
    > If you don't find anything with this information, let us know what kind
    > of storage you are using, along with the type of switchwork you are
    > using as well. All of my expertise is with the IBM DS8XXX hardware, but
    > if you post about other hardware, there is somebody else in here that
    > will chime in.


+ Reply to Thread