VxVM 3.5 and Solaris 8-17: vxdg import fails with error 28 - Veritas Volume Manager

This is a discussion on VxVM 3.5 and Solaris 8-17: vxdg import fails with error 28 - Veritas Volume Manager ; Hi Anyone seen this error before and possible known what might cause it and hinder the disk group to be import and volumes accessable? From the syslog: Feb 13 13:57:59 vxio: [ID 117038 kern.warning] WARNING: vxvm:vxio: cannot log commit record ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: VxVM 3.5 and Solaris 8-17: vxdg import fails with error 28

  1. VxVM 3.5 and Solaris 8-17: vxdg import fails with error 28


    Hi

    Anyone seen this error before and possible known what might cause it and
    hinder the disk group to be import and volumes accessable?

    From the syslog:
    Feb 13 13:57:59 vxio: [ID 117038 kern.warning] WARNING: vxvm:vxio:
    cannot log commit record for Diskgroup datadg: error 28

    if trying to import by hand:
    # vxdg import datadg
    vxvm:vxdg: ERROR: Disk group datadg: import failed: Disk for disk group not
    found

    I suspect our SAN managers to have ****ed something in the SAN, but they
    claim that all LUNS/Disk should be available for the host, unfortunely I
    can't tell for sure, since I normally dont adminstere this host and they
    don't have a dump/backup of the veritas configuration for verify it against.
    At first they had 3 disk groups other than rootdg and only one failed like
    this. Then second IO/DMP path were missing and they messed around and now
    all the disk groups fails like this, but all paths seems okay.

    Any Veritas people whom might verify what error 28 means here?

    /Steffen

  2. Re: VxVM 3.5 and Solaris 8-17: vxdg import fails with error 28

    I hope the following excerpt from SUN's document will give you some ideas.

    Alexander


    Section 12
    Suppressing a Path from DMP and VxVM in a Multipath Array
    (Ref. incident 108881)
    ================================================== =======
    (This applies only when running on Solaris 9.)

    Problem: If you have an array with multiple paths, and after suppressing
    one path from DMP, suppress that path from VxVM using the vxdiskadm
    option 17 and option 1. Then, if all rootdg disks are from that array
    you will receive errors of the following form, and vxconfigd will not start,
    so VxVM will not run:

    vxvm:vxconfigd: NOTICE: Unable to resolve duplicate diskid
    Please refer to release notes and admin guide for possible
    action/solution.
    Following are the disks with duplicate diskid:
    Vendor: SUN Product: T300 - c1t1d2s2, c4t2d2s2
    ...
    Following are the disks with duplicate diskid:
    Vendor: SUN Product: T300 - c1t1d3s2, c4t2d3s2
    WARNING: vxvm:vxio: cannot log commit record for Diskgroup rootdg:
    error 28
    vxvm:vxconfigd: ERROR: enable failed: Error in disk group configuration
    copies
    Unexpected kernel error in configuration update; transactions are
    disabled.
    vxvm:vxconfigd: FATAL ERROR: Rootdg cannot be imported during boot

    Workaround:

    A. If only one array is connected to one controller, perform the following
    two steps:
    1. Suppress path from DMP, using vxdiskadm option 17, then option 5
    2. Suppress path from VxVM, using vxdiskadm option 17, then option 1

    B. If more than one array is connected to one controller, perform the
    following two steps:
    1. Suppress path from DMP, using vxdiskadm option 17, then option 5
    2. Suppress every path from VxVM belonging to the array, using
    vxdiskadm option 17, then option 2

    > Hi
    >
    > Anyone seen this error before and possible known what might cause it and
    > hinder the disk group to be import and volumes accessable?
    >
    > From the syslog:
    > Feb 13 13:57:59 vxio: [ID 117038 kern.warning] WARNING: vxvm:vxio:
    > cannot log commit record for Diskgroup datadg: error 28
    >
    > if trying to import by hand:
    > # vxdg import datadg
    > vxvm:vxdg: ERROR: Disk group datadg: import failed: Disk for disk group not
    > found
    >
    > I suspect our SAN managers to have ****ed something in the SAN, but they
    > claim that all LUNS/Disk should be available for the host, unfortunely I
    > can't tell for sure, since I normally dont adminstere this host and they
    > don't have a dump/backup of the veritas configuration for verify it against.
    > At first they had 3 disk groups other than rootdg and only one failed like
    > this. Then second IO/DMP path were missing and they messed around and now
    > all the disk groups fails like this, but all paths seems okay.
    >
    > Any Veritas people whom might verify what error 28 means here?
    >
    > /Steffen




  3. Re: VxVM 3.5 and Solaris 8-17: vxdg import fails with error 28


    Alexander Olkhovsky wrote:
    >I hope the following excerpt from SUN's document will give you some ideas.

    Thanks Alexander, but I found this already yesterday, They changed the SAN
    so disks now has mulitple PATHs, so doing a vxddladm addjbod vid=HITACHI
    and a reboot did the job

    But you pointed me in the right direction, except we want to utilize DMP
    from our HITACHI 99x0V array.

    Earlier versions automatically by default regonized our HITACHI arrays, but
    with 3.5 it has to be enabled through Device Discovery Layer

    >Alexander
    >
    >
    >Section 12
    >Suppressing a Path from DMP and VxVM in a Multipath Array
    >(Ref. incident 108881)
    >================================================== =======
    >(This applies only when running on Solaris 9.)
    >
    >Problem: If you have an array with multiple paths, and after suppressing
    >one path from DMP, suppress that path from VxVM using the vxdiskadm
    >option 17 and option 1. Then, if all rootdg disks are from that array
    >you will receive errors of the following form, and vxconfigd will not start,
    >so VxVM will not run:
    >
    > vxvm:vxconfigd: NOTICE: Unable to resolve duplicate diskid
    > Please refer to release notes and admin guide for possible
    >action/solution.
    > Following are the disks with duplicate diskid:
    > Vendor: SUN Product: T300 - c1t1d2s2, c4t2d2s2
    > ...
    > Following are the disks with duplicate diskid:
    > Vendor: SUN Product: T300 - c1t1d3s2, c4t2d3s2
    > WARNING: vxvm:vxio: cannot log commit record for Diskgroup rootdg:
    >error 28
    > vxvm:vxconfigd: ERROR: enable failed: Error in disk group configuration
    > copies
    > Unexpected kernel error in configuration update; transactions are
    >disabled.
    > vxvm:vxconfigd: FATAL ERROR: Rootdg cannot be imported during boot
    >
    >Workaround:
    >
    >A. If only one array is connected to one controller, perform the following
    >two steps:
    > 1. Suppress path from DMP, using vxdiskadm option 17, then option 5
    > 2. Suppress path from VxVM, using vxdiskadm option 17, then option 1
    >
    >B. If more than one array is connected to one controller, perform the
    >following two steps:
    > 1. Suppress path from DMP, using vxdiskadm option 17, then option 5
    > 2. Suppress every path from VxVM belonging to the array, using
    > vxdiskadm option 17, then option 2
    >
    >> Hi
    >>
    >> Anyone seen this error before and possible known what might cause it and
    >> hinder the disk group to be import and volumes accessable?
    >>
    >> From the syslog:
    >> Feb 13 13:57:59 vxio: [ID 117038 kern.warning] WARNING: vxvm:vxio:
    >> cannot log commit record for Diskgroup datadg: error 28
    >>
    >> if trying to import by hand:
    >> # vxdg import datadg
    >> vxvm:vxdg: ERROR: Disk group datadg: import failed: Disk for disk group

    not
    >> found
    >>
    >> I suspect our SAN managers to have ****ed something in the SAN, but they
    >> claim that all LUNS/Disk should be available for the host, unfortunely

    I
    >> can't tell for sure, since I normally dont adminstere this host and they
    >> don't have a dump/backup of the veritas configuration for verify it against.
    >> At first they had 3 disk groups other than rootdg and only one failed

    like
    >> this. Then second IO/DMP path were missing and they messed around and

    now
    >> all the disk groups fails like this, but all paths seems okay.
    >>
    >> Any Veritas people whom might verify what error 28 means here?
    >>
    >> /Steffen

    >
    >



+ Reply to Thread