vxdg fails to import - "No valid disk found containing disk group" - Veritas Volume Manager

This is a discussion on vxdg fails to import - "No valid disk found containing disk group" - Veritas Volume Manager ; old config: Sun box sitting on top of a bunch of A5200. It died. We were waiting for replacement, but there seems to be some prob with it -and I have management breathing down my neck - so I took ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: vxdg fails to import - "No valid disk found containing disk group"

  1. vxdg fails to import - "No valid disk found containing disk group"


    old config:
    Sun box sitting on top of a bunch of A5200. It died. We were waiting for
    replacement, but there seems to be some prob with it -and I have management

    breathing down my neck - so I took a spare PC, installed RHAS 3.0 and VxVM
    4.0
    (got the temp key), moved the HBAs. I can see the disks - vxdisk list shows
    them all online, ready and all that. If I do -s list it shows proper volume
    group names they belonged to. But vxdg import dies with the infamous V-5-1-587.
    Tried to release the locks, tried to rename the dg on import - to no avail.
    Perhaps I've been at it too long. I hope I'm missing something obvious
    - can someone tell me what? No, of course the group was not deported...
    TIA!

  2. Re: vxdg fails to import - "No valid disk found containing diskgroup"

    Tom


    You say that "vxdisk list" shows the disks online, please post a "vxdisk
    -o alldgs list"

    See if you can see the disks that should belong to the diskgroup in
    question.

    If you can see all the disks, then try a "vxdg -f import"

    If, not .......

    Then (the part where you have to do a bit of work), you have to look at
    all the disks that belong to the diskgroup.

    Do a /etc/vx/diag.d/vxprivutil dumpconfig /dev/sd?? on the disks
    belonging to the diskgroup. We need a disk with configuration copies
    enabled. (You need to specify the slice where the private information is
    stored on - so a "fdisk -l" might help to identify the private region)

    Once you can get a good dump (thus one where you can "read" the
    configuration) where all the records can be seen, then you need to pipe
    the output to vxprint, to see if this is the diskgroup that you want
    (say that the slice with the private info on is /dev/sdh3 --> then do
    "/etc/vx/diag.d/vxprinvutil dumpconfig /dev/sdh3 | vxprint -D -th -")


    If you're happy that you can see the correct config, then you need to
    figure out if you have all the disks (compare the vxprint output at the
    top, with the vxdisk list output), then you need to do some magic.

    Again, dump the config from this good disk ( something like:
    "/etc/vx/diag.d/vxprinvutil dumpconfig /dev/sdh3 | vxprint -D -mqvpd - >
    /tmp/keep-config"

    Now, you need to init all the disks again in the correct order. So look
    at the vxprint again, make sure you know which disk was which, and then do

    vxdisk -f init

    (where the disk is sd?)

    Now, we need to re-create the private area on the disks and put them
    back into the diskgroup in the correct order

    So, say the name of the diskgroup was datadg, and the disks should be in
    the order sdh,sdj,sdi,sdd,sde ; then the next command will re-create the
    diskgroup:


    vxdg init datadg disk01=sdh,disk02=sdj,disk03=sdi,disk04=sdd,disk05 =sde


    Once you've got that going, we need to build the diskgroup from the
    bottom up,

    vxmake -g datadg -d /tmp/kee-config


    And that should be it !!!


    Biggest question at this point will be what next ??? If the data was on
    Solaris, what are you going to do with the data now ??? Linux works with
    the "Big Indian" conversion on all data (least significant bit first)
    while Solaris works with "Little Indian" (leats significant bit last).
    In short, this means that your data will be useless !!!!

    You might be lucky in the sense that the diskgroup was created on VxVM
    4.0 on Solaris, in which case you will have to do a conversion on the
    data. (All documented in the CDS doco)

    Best would be to get a spare SUN box to set this up, or to get Veritas
    Support on the line.



    GOOD LUCK !!!!


    Tom Korycki wrote:
    > old config:
    > Sun box sitting on top of a bunch of A5200. It died. We were waiting for
    > replacement, but there seems to be some prob with it -and I have management
    >
    > breathing down my neck - so I took a spare PC, installed RHAS 3.0 and VxVM
    > 4.0
    > (got the temp key), moved the HBAs. I can see the disks - vxdisk list shows
    > them all online, ready and all that. If I do -s list it shows proper volume
    > group names they belonged to. But vxdg import dies with the infamous V-5-1-587.
    > Tried to release the locks, tried to rename the dg on import - to no avail.
    > Perhaps I've been at it too long. I hope I'm missing something obvious
    > - can someone tell me what? No, of course the group was not deported...
    > TIA!


  3. Re: vxdg fails to import - "No valid disk found containing disk


    Me wrote:
    >Tom
    >
    >
    >You say that "vxdisk list" shows the disks online, please post a "vxdisk


    >-o alldgs list"
    >


    Here You go: >>>>>>>>>>>>>>>>> start
    DEVICE TYPE DISK GROUP STATUS
    hda auto:none - - online invalid
    hdd auto:none - - online invalid
    sda auto:sliced - (GR2) online aliased
    sdaa auto:sliced - (GR3) online aliased
    sdab auto:sliced - (GR3) online aliased
    sdac auto:sliced - (GR3) online aliased
    sdad auto:sliced - (GR3) online aliased
    sdae auto:sliced - (GR3) online aliased
    sdaf auto:sliced - (GR3) online aliased
    sdag auto:sliced - (GR3) online aliased
    sdah auto:sliced - (GR2) online aliased
    sdai auto:sliced - (GR2) online aliased
    sdaj auto:sliced - (GR2) online aliased
    sdak auto:sliced - (GR2) online aliased
    sdal auto:sliced - (GR2) online aliased
    sdam auto:sliced - (GR2) online aliased
    sdan auto:sliced - (GR2) online aliased
    sdao auto:sliced - (GR2) online aliased
    sdap auto:sliced - (GR2) online aliased
    sdaq auto:sliced - (GR2) online aliased
    sdar auto:sliced - (GR2) online aliased
    sdas auto:sliced - (GR1) online aliased
    sdat auto:sliced - (GR1) online aliased
    sdau auto:sliced - (GR1) online aliased
    sdav auto:sliced - (GR1) online aliased
    sdaw auto:sliced - (GR1) online aliased
    sdax auto:sliced - (GR1) online aliased
    sday auto:sliced - (GR1) online aliased
    sdaz auto:sliced - (GR1) online aliased
    sdb auto:sliced - (GR2) online aliased
    sdba auto:sliced - (GR1) online aliased
    sdbb auto:sliced - (GR1) online aliased
    sdbc auto:sliced - (GR2) online aliased
    sdbd auto:sliced - (GR3) online aliased
    sdbe auto:sliced - (GR3) online aliased
    sdbf auto:sliced - (GR3) online aliased
    sdbg auto:sliced - (GR3) online aliased
    sdbh auto:sliced - (GR3) online aliased
    sdbi auto:sliced - (GR3) online aliased
    sdbj auto:sliced - (GR3) online aliased
    sdbk auto:sliced - (GR3) online aliased
    sdbl auto:sliced - (GR3) online aliased
    sdbm auto:sliced - (GR3) online aliased
    sdbn auto:sliced - (GR3) online aliased
    sdc auto:sliced - (GR2) online aliased
    sdd auto:sliced - (GR2) online aliased
    sde auto:sliced - (GR2) online aliased
    sdf auto:sliced - (GR2) online aliased
    sdg auto:sliced - (GR2) online aliased
    sdh auto:sliced - (GR2) online aliased
    sdi auto:sliced - (GR2) online aliased
    sdj auto:sliced - (GR2) online aliased
    sdk auto:sliced - (GR2) online aliased
    sdl auto:sliced - (GR1) online aliased
    sdm auto:sliced - (GR1) online aliased
    sdn auto:sliced - (GR1) online aliased
    sdo auto:sliced - (GR1) online aliased
    sdp auto:sliced - (GR1) online aliased
    sdq auto:sliced - (GR1) online aliased
    sdr auto:sliced - (GR1) online aliased
    sds auto:sliced - (GR1) online aliased
    sdt auto:sliced - (GR1) online aliased
    sdu auto:sliced - (GR1) online aliased
    sdv auto:sliced - (GR1) online aliased
    sdw auto:sliced - (GR3) online aliased
    sdx auto:sliced - (GR3) online aliased
    sdy auto:sliced - (GR3) online aliased
    sdz auto:sliced - (GR3) online aliased
    <<<<<<<<<<<<<<<<<<<<<<<<<<< end
    Do not worry about hd?, they are obviously not under VxVM control.

    And here's an excerpt from `vxdisk -s list`:
    >>>>>>>>>>>>>>>>>>>>>>>>>>> start

    Disk: sdz
    type: auto
    flags: online ready private autoconfig autoimport aliased
    diskid: 1045501646.3090.helix
    dgname: GR3
    dgid: 1045503446.3170.helix
    hostid: helix
    info: format=sliced,privoffset=1,pubslice=5,privslice=4
    <<<<<<<<<<<<<<<<<<<<<<<<<<<<< end

    What bothes me about that is that the disk has no name... And it did. They
    all did, in fact. Now none of them do.

    >See if you can see the disks that should belong to the diskgroup in
    >question.
    >


    All three of them (GR[1-3]) fail to import, exactly the same way. GR3 is
    smallest, so I'm playing with it first. Plus, it's the only one I am confident
    I have a backup for - since I took it myself...

    >If you can see all the disks, then try a "vxdg -f import"
    >


    I see all disks, but import fails with:
    [root@helix root]# vxdg -f import GR3
    VxVM vxdg ERROR V-5-1-587 Disk group GR3: import failed: No valid disk found
    containing disk group
    Now, after I do the import (and fail), all disks show error status - I clear
    it with `vxdctl enable` - usually...

    >If, not .......
    >
    >Then (the part where you have to do a bit of work), you have to look at


    >all the disks that belong to the diskgroup.
    >
    >Do a /etc/vx/diag.d/vxprivutil dumpconfig /dev/sd?? on the disks
    >belonging to the diskgroup. We need a disk with configuration copies
    >enabled. (You need to specify the slice where the private information is


    >stored on - so a "fdisk -l" might help to identify the private region)
    >


    It's slice 4 on all of them, but trying to dump from any one errors out all
    of them - `vxdctl enable` does not fix that, only full reboot does...
    [[[[[after a while]]]]
    got one!

    >Once you can get a good dump (thus one where you can "read" the
    >configuration) where all the records can be seen, then you need to pipe


    >the output to vxprint, to see if this is the diskgroup that you want
    >(say that the slice with the private info on is /dev/sdh3 --> then do


    >"/etc/vx/diag.d/vxprinvutil dumpconfig /dev/sdh3 | vxprint -D -th -")
    >


    Hmmm... When I did `-D -th -`, it complained it didn't know anythng about
    -th database format, so I did:
    [root@helix root]# /etc/vx/diag.d/vxprivutil dumpconfig /dev/sdbd4 |vxprint
    -thD -
    VxVM vxprint ERROR V-5-1-326 unrecognized value for variable, context: last_platform=0x0
    #bad


    >
    >If you're happy that you can see the correct config, then you need to
    >figure out if you have all the disks (compare the vxprint output at the


    >top, with the vxdisk list output), then you need to do some magic.


    I obviously can't see squat... Anyway, I am beginning to feel like I'm ready
    for a _really big mistake_ - I guess I need some zeez, at laeast 2-3 hours...


    Thanks a lot! And I will continue, it's just... I begin to feel like I do
    not care about errors - and that is dangerous.

    >
    >Again, dump the config from this good disk ( something like:
    >"/etc/vx/diag.d/vxprinvutil dumpconfig /dev/sdh3 | vxprint -D -mqvpd - >


    >/tmp/keep-config"
    >
    >Now, you need to init all the disks again in the correct order. So look


    >at the vxprint again, make sure you know which disk was which, and then

    do
    >
    >vxdisk -f init
    >
    >(where the disk is sd?)
    >
    >Now, we need to re-create the private area on the disks and put them
    >back into the diskgroup in the correct order
    >
    >So, say the name of the diskgroup was datadg, and the disks should be in


    >the order sdh,sdj,sdi,sdd,sde ; then the next command will re-create the


    >diskgroup:
    >
    >
    >vxdg init datadg disk01=sdh,disk02=sdj,disk03=sdi,disk04=sdd,disk05 =sde
    >
    >
    >Once you've got that going, we need to build the diskgroup from the
    >bottom up,
    >
    >vxmake -g datadg -d /tmp/kee-config
    >
    >
    >And that should be it !!!
    >
    >
    >Biggest question at this point will be what next ??? If the data was on


    >Solaris, what are you going to do with the data now ??? Linux works with


    >the "Big Indian" conversion on all data (least significant bit first)
    >while Solaris works with "Little Indian" (leats significant bit last).
    >In short, this means that your data will be useless !!!!
    >
    >You might be lucky in the sense that the diskgroup was created on VxVM
    >4.0 on Solaris, in which case you will have to do a conversion on the
    >data. (All documented in the CDS doco)
    >
    >Best would be to get a spare SUN box to set this up, or to get Veritas
    >Support on the line.
    >
    >
    >
    >GOOD LUCK !!!!
    >
    >
    >Tom Korycki wrote:
    >> old config:
    >> Sun box sitting on top of a bunch of A5200. It died. We were waiting for
    >> replacement, but there seems to be some prob with it -and I have management
    >>
    >> breathing down my neck - so I took a spare PC, installed RHAS 3.0 and

    VxVM
    >> 4.0
    >> (got the temp key), moved the HBAs. I can see the disks - vxdisk list

    shows
    >> them all online, ready and all that. If I do -s list it shows proper volume
    >> group names they belonged to. But vxdg import dies with the infamous V-5-1-587.
    >> Tried to release the locks, tried to rename the dg on import - to no avail.
    >> Perhaps I've been at it too long. I hope I'm missing something obvious
    >> - can someone tell me what? No, of course the group was not deported...
    >> TIA!



  4. Re: vxdg fails to import - "No valid disk found containing disk

    Tom



    The solution might be easier than all this.


    If you look at any of the disks in question, you see that it is "onlined
    aliased"


    This means that somehow (long story about the new CDS with version 4.0
    and the old layout with the private region and public regions), Volume
    Manager thinks that this disk is a sliced disk (as can be seen from the
    vxdisk list you posted), but the private region (where all the volume
    manager config is kept), says that it is a simple disk (a simple disk is
    a disk where the public and private regions sit on the same slice).

    To check, please do "vxdisk list sda"

    You should see that the private region points to the same slice as the
    public region (post it here and I will point it out if you want)


    OK, so that is the problem, now the fix.



    You say you want to start with GR3, so let's do it !!

    The first thing we have to do, is tell volume Manager to forget about
    the sliced disks. After that, we will tell volume manager to look at
    them agani, but to look at them as simple disks.

    So the steps are:

    vxdisk rm sdab
    vxdisk define sdab type=simple

    ...
    ...



    Once you've done all the disks, then look at them again through a
    "vxdisk list"


    It should not show the "aliased" anymore and the TYPE should show "simple"



    If the "vxdisk list sda" does not show the public and private regions on
    the same slice, all we need to do, is to remove the disk (vxdisk rm) and
    define it again as a "sliced" disk (the problem is with the "auto" or
    CDS disk)


    By all means, post the output of "vxdisk list sda" so that we can see if
    the public path and private path points at a single slice or not, and
    then I will tell you what to do next.




    Tom Korycki wrote:
    > Me wrote:
    >
    >>Tom
    >>
    >>
    >>You say that "vxdisk list" shows the disks online, please post a "vxdisk

    >
    >
    >>-o alldgs list"
    >>

    >
    >
    > Here You go: >>>>>>>>>>>>>>>>> start
    > DEVICE TYPE DISK GROUP STATUS
    > hda auto:none - - online invalid
    > hdd auto:none - - online invalid
    > sda auto:sliced - (GR2) online aliased
    > sdaa auto:sliced - (GR3) online aliased
    > sdab auto:sliced - (GR3) online aliased
    > sdac auto:sliced - (GR3) online aliased
    > sdad auto:sliced - (GR3) online aliased
    > sdae auto:sliced - (GR3) online aliased
    > sdaf auto:sliced - (GR3) online aliased
    > sdag auto:sliced - (GR3) online aliased
    > sdah auto:sliced - (GR2) online aliased
    > sdai auto:sliced - (GR2) online aliased
    > sdaj auto:sliced - (GR2) online aliased
    > sdak auto:sliced - (GR2) online aliased
    > sdal auto:sliced - (GR2) online aliased
    > sdam auto:sliced - (GR2) online aliased
    > sdan auto:sliced - (GR2) online aliased
    > sdao auto:sliced - (GR2) online aliased
    > sdap auto:sliced - (GR2) online aliased
    > sdaq auto:sliced - (GR2) online aliased
    > sdar auto:sliced - (GR2) online aliased
    > sdas auto:sliced - (GR1) online aliased
    > sdat auto:sliced - (GR1) online aliased
    > sdau auto:sliced - (GR1) online aliased
    > sdav auto:sliced - (GR1) online aliased
    > sdaw auto:sliced - (GR1) online aliased
    > sdax auto:sliced - (GR1) online aliased
    > sday auto:sliced - (GR1) online aliased
    > sdaz auto:sliced - (GR1) online aliased
    > sdb auto:sliced - (GR2) online aliased
    > sdba auto:sliced - (GR1) online aliased
    > sdbb auto:sliced - (GR1) online aliased
    > sdbc auto:sliced - (GR2) online aliased
    > sdbd auto:sliced - (GR3) online aliased
    > sdbe auto:sliced - (GR3) online aliased
    > sdbf auto:sliced - (GR3) online aliased
    > sdbg auto:sliced - (GR3) online aliased
    > sdbh auto:sliced - (GR3) online aliased
    > sdbi auto:sliced - (GR3) online aliased
    > sdbj auto:sliced - (GR3) online aliased
    > sdbk auto:sliced - (GR3) online aliased
    > sdbl auto:sliced - (GR3) online aliased
    > sdbm auto:sliced - (GR3) online aliased
    > sdbn auto:sliced - (GR3) online aliased
    > sdc auto:sliced - (GR2) online aliased
    > sdd auto:sliced - (GR2) online aliased
    > sde auto:sliced - (GR2) online aliased
    > sdf auto:sliced - (GR2) online aliased
    > sdg auto:sliced - (GR2) online aliased
    > sdh auto:sliced - (GR2) online aliased
    > sdi auto:sliced - (GR2) online aliased
    > sdj auto:sliced - (GR2) online aliased
    > sdk auto:sliced - (GR2) online aliased
    > sdl auto:sliced - (GR1) online aliased
    > sdm auto:sliced - (GR1) online aliased
    > sdn auto:sliced - (GR1) online aliased
    > sdo auto:sliced - (GR1) online aliased
    > sdp auto:sliced - (GR1) online aliased
    > sdq auto:sliced - (GR1) online aliased
    > sdr auto:sliced - (GR1) online aliased
    > sds auto:sliced - (GR1) online aliased
    > sdt auto:sliced - (GR1) online aliased
    > sdu auto:sliced - (GR1) online aliased
    > sdv auto:sliced - (GR1) online aliased
    > sdw auto:sliced - (GR3) online aliased
    > sdx auto:sliced - (GR3) online aliased
    > sdy auto:sliced - (GR3) online aliased
    > sdz auto:sliced - (GR3) online aliased
    > <<<<<<<<<<<<<<<<<<<<<<<<<<< end
    > Do not worry about hd?, they are obviously not under VxVM control.
    >
    > And here's an excerpt from `vxdisk -s list`:
    >
    >>>>>>>>>>>>>>>>>>>>>>>>>>>>start

    >
    > Disk: sdz
    > type: auto
    > flags: online ready private autoconfig autoimport aliased
    > diskid: 1045501646.3090.helix
    > dgname: GR3
    > dgid: 1045503446.3170.helix
    > hostid: helix
    > info: format=sliced,privoffset=1,pubslice=5,privslice=4
    > <<<<<<<<<<<<<<<<<<<<<<<<<<<<< end
    >
    > What bothes me about that is that the disk has no name... And it did. They
    > all did, in fact. Now none of them do.
    >
    >
    >>See if you can see the disks that should belong to the diskgroup in
    >>question.
    >>

    >
    >
    > All three of them (GR[1-3]) fail to import, exactly the same way. GR3 is
    > smallest, so I'm playing with it first. Plus, it's the only one I am confident
    > I have a backup for - since I took it myself...
    >
    >
    >>If you can see all the disks, then try a "vxdg -f import"
    >>

    >
    >
    > I see all disks, but import fails with:
    > [root@helix root]# vxdg -f import GR3
    > VxVM vxdg ERROR V-5-1-587 Disk group GR3: import failed: No valid disk found
    > containing disk group
    > Now, after I do the import (and fail), all disks show error status - I clear
    > it with `vxdctl enable` - usually...
    >
    >
    >>If, not .......
    >>
    >>Then (the part where you have to do a bit of work), you have to look at

    >
    >
    >>all the disks that belong to the diskgroup.
    >>
    >>Do a /etc/vx/diag.d/vxprivutil dumpconfig /dev/sd?? on the disks
    >>belonging to the diskgroup. We need a disk with configuration copies
    >>enabled. (You need to specify the slice where the private information is

    >
    >
    >>stored on - so a "fdisk -l" might help to identify the private region)
    >>

    >
    >
    > It's slice 4 on all of them, but trying to dump from any one errors out all
    > of them - `vxdctl enable` does not fix that, only full reboot does...
    > [[[[[after a while]]]]
    > got one!
    >
    >
    >>Once you can get a good dump (thus one where you can "read" the
    >>configuration) where all the records can be seen, then you need to pipe

    >
    >
    >>the output to vxprint, to see if this is the diskgroup that you want
    >>(say that the slice with the private info on is /dev/sdh3 --> then do

    >
    >
    >>"/etc/vx/diag.d/vxprinvutil dumpconfig /dev/sdh3 | vxprint -D -th -")
    >>

    >
    >
    > Hmmm... When I did `-D -th -`, it complained it didn't know anythng about
    > -th database format, so I did:
    > [root@helix root]# /etc/vx/diag.d/vxprivutil dumpconfig /dev/sdbd4 |vxprint
    > -thD -
    > VxVM vxprint ERROR V-5-1-326 unrecognized value for variable, context: last_platform=0x0
    > #bad
    >
    >
    >
    >>If you're happy that you can see the correct config, then you need to
    >>figure out if you have all the disks (compare the vxprint output at the

    >
    >
    >>top, with the vxdisk list output), then you need to do some magic.

    >
    >
    > I obviously can't see squat... Anyway, I am beginning to feel like I'm ready
    > for a _really big mistake_ - I guess I need some zeez, at laeast 2-3 hours...
    >
    >
    > Thanks a lot! And I will continue, it's just... I begin to feel like I do
    > not care about errors - and that is dangerous.
    >
    >
    >>Again, dump the config from this good disk ( something like:
    >>"/etc/vx/diag.d/vxprinvutil dumpconfig /dev/sdh3 | vxprint -D -mqvpd - >

    >
    >
    >>/tmp/keep-config"
    >>
    >>Now, you need to init all the disks again in the correct order. So look

    >
    >
    >>at the vxprint again, make sure you know which disk was which, and then

    >
    > do
    >
    >>vxdisk -f init
    >>
    >>(where the disk is sd?)
    >>
    >>Now, we need to re-create the private area on the disks and put them
    >>back into the diskgroup in the correct order
    >>
    >>So, say the name of the diskgroup was datadg, and the disks should be in

    >
    >
    >>the order sdh,sdj,sdi,sdd,sde ; then the next command will re-create the

    >
    >
    >>diskgroup:
    >>
    >>
    >>vxdg init datadg disk01=sdh,disk02=sdj,disk03=sdi,disk04=sdd,disk05 =sde
    >>
    >>
    >>Once you've got that going, we need to build the diskgroup from the
    >>bottom up,
    >>
    >>vxmake -g datadg -d /tmp/kee-config
    >>
    >>
    >>And that should be it !!!
    >>
    >>
    >>Biggest question at this point will be what next ??? If the data was on

    >
    >
    >>Solaris, what are you going to do with the data now ??? Linux works with

    >
    >
    >>the "Big Indian" conversion on all data (least significant bit first)
    >>while Solaris works with "Little Indian" (leats significant bit last).
    >>In short, this means that your data will be useless !!!!
    >>
    >>You might be lucky in the sense that the diskgroup was created on VxVM
    >>4.0 on Solaris, in which case you will have to do a conversion on the
    >>data. (All documented in the CDS doco)
    >>
    >>Best would be to get a spare SUN box to set this up, or to get Veritas
    >>Support on the line.
    >>
    >>
    >>
    >>GOOD LUCK !!!!
    >>
    >>
    >>Tom Korycki wrote:
    >>
    >>>old config:
    >>>Sun box sitting on top of a bunch of A5200. It died. We were waiting for
    >>>replacement, but there seems to be some prob with it -and I have management
    >>>
    >>>breathing down my neck - so I took a spare PC, installed RHAS 3.0 and

    >
    > VxVM
    >
    >>>4.0
    >>>(got the temp key), moved the HBAs. I can see the disks - vxdisk list

    >
    > shows
    >
    >>>them all online, ready and all that. If I do -s list it shows proper volume
    >>>group names they belonged to. But vxdg import dies with the infamous V-5-1-587.
    >>>Tried to release the locks, tried to rename the dg on import - to no avail.
    >>> Perhaps I've been at it too long. I hope I'm missing something obvious
    >>>- can someone tell me what? No, of course the group was not deported...
    >>>TIA!

    >
    >


  5. Re: vxdg fails to import - "No valid disk found containing disk


    Me wrote:
    >Tom
    >
    >The solution might be easier than all this.
    >
    >If you look at any of the disks in question, you see that it is "onlined


    >aliased"
    >
    >This means that somehow (long story about the new CDS with version 4.0
    >and the old layout with the private region and public regions), Volume
    >Manager thinks that this disk is a sliced disk (as can be seen from the


    >vxdisk list you posted), but the private region (where all the volume
    >manager config is kept), says that it is a simple disk (a simple disk is


    >a disk where the public and private regions sit on the same slice).
    >
    >To check, please do "vxdisk list sda"
    >
    >You should see that the private region points to the same slice as the
    >public region (post it here and I will point it out if you want)
    >



    >>>>>>>>>>>>>>>>>>>>> start

    [root@helix root]# vxdisk list sda
    Device: sda
    devicetag: sda
    type: auto
    hostid: helix
    disk: name= id=1045501542.3004.helix
    group: name=GR2 id=1045504279.3173.helix
    info: format=sliced,privoffset=1,pubslice=5,privslice=4
    flags: online ready private autoconfig autoimport aliased
    pubpaths: block=/dev/vx/dmp/sda5 char=/dev/vx/rdmp/sda5
    privpaths: block=/dev/vx/dmp/sda4 char=/dev/vx/rdmp/sda4
    version: 2.2
    iosize: min=512 (bytes) max=256 (blocks)
    public: slice=4 offset=0 len=143328960 disk_offset=20352
    private: slice=3 offset=1 len=10175 disk_offset=0
    update: time=1108557533 seqno=0.183
    ssb: actual_seqno=0.0
    headers: 0 248
    configs: count=1 len=7489
    logs: count=1 len=1134
    Multipathing information:
    numpaths: 1
    sda state=enabled
    <<<<<<<<<<<<<<<<<<<<<<< end

    So, it seems to see public in slice 5 and private in 4. On all disks _different_
    paths

    >
    >OK, so that is the problem, now the fix.
    >
    >You say you want to start with GR3, so let's do it !!
    >
    >The first thing we have to do, is tell volume Manager to forget about
    >the sliced disks. After that, we will tell volume manager to look at
    >them agani, but to look at them as simple disks.
    >
    >So the steps are:
    >
    >vxdisk rm sdab
    >vxdisk define sdab type=simple
    >
    >...
    >...
    >
    >
    >
    >Once you've done all the disks, then look at them again through a
    >"vxdisk list"
    >
    >
    >It should not show the "aliased" anymore and the TYPE should show "simple"
    >
    >
    >
    >If the "vxdisk list sda" does not show the public and private regions on


    >the same slice, all we need to do, is to remove the disk (vxdisk rm) and


    >define it again as a "sliced" disk (the problem is with the "auto" or
    >CDS disk)
    >


    Yes, it is a CDS disk: created under Solaris8, now trying to read it under
    Linux. As I said, we are geting a replacement Slaris box, but in th meantime
    we need access to data - and I do _not_, I repeat: I do NOT, trust the backups
    of most of it.
    >>>>>>>>>>>>>>>>>>>>>>>> snip! <<<<<<<<<<<<<<<<<<<<<<<


  6. Re: vxdg fails to import - "No valid disk found containing disk

    Tom



    From the vxdisk list output:


    > pubpaths: block=/dev/vx/dmp/sda5 char=/dev/vx/rdmp/sda5
    > privpaths: block=/dev/vx/dmp/sda4 char=/dev/vx/rdmp/sda4




    This is a "normal" sliced disk created with an older version of Volume
    Manager (Like 3.11 --> 3.5). On Solaris, this means that it used to be
    slices 3 and 4. There might have been a cylinder left for the CDS, but
    this is not a disk created in version 4.0.


    Version 4.0 does it a bit differently. It will create only slice 7 (on
    Solaris) and will put the disk format down as auto:cds

    Here, Volume Manager picked up the private region, and put the the disk
    format as "auto:sliced"

    What you need to do, is get the format just as "sliced"


    Thus, you need to remove the current disk from Volume Manager

    vxdisk rm sda


    And then specify the disktype as sliced (not auto)

    vxdisk define sda type=sliced


    NOW, when you look at the "vxdisk -o alldgs list" output, you should see
    the disk again, but the entry should look like:

    DEVICE TYPE DISK GROUP STATUS
    sda sliced - (GR2) online



    (Notice that the TYPE should change from "auto:sliced" to "sliced" and
    the STATUS should change frmo "online aliased" to "online")


    Once you do that to all the disks, you will be able to import the
    diskgroups.


    Tom Korycki wrote:
    > Me wrote:
    >
    >>Tom
    >>
    >>The solution might be easier than all this.
    >>
    >>If you look at any of the disks in question, you see that it is "onlined

    >
    >
    >>aliased"
    >>
    >>This means that somehow (long story about the new CDS with version 4.0
    >>and the old layout with the private region and public regions), Volume
    >>Manager thinks that this disk is a sliced disk (as can be seen from the

    >
    >
    >>vxdisk list you posted), but the private region (where all the volume
    >>manager config is kept), says that it is a simple disk (a simple disk is

    >
    >
    >>a disk where the public and private regions sit on the same slice).
    >>
    >>To check, please do "vxdisk list sda"
    >>
    >>You should see that the private region points to the same slice as the
    >>public region (post it here and I will point it out if you want)
    >>

    >
    >
    >
    >>>>>>>>>>>>>>>>>>>>>>start

    >
    > [root@helix root]# vxdisk list sda
    > Device: sda
    > devicetag: sda
    > type: auto
    > hostid: helix
    > disk: name= id=1045501542.3004.helix
    > group: name=GR2 id=1045504279.3173.helix
    > info: format=sliced,privoffset=1,pubslice=5,privslice=4
    > flags: online ready private autoconfig autoimport aliased
    > pubpaths: block=/dev/vx/dmp/sda5 char=/dev/vx/rdmp/sda5
    > privpaths: block=/dev/vx/dmp/sda4 char=/dev/vx/rdmp/sda4
    > version: 2.2
    > iosize: min=512 (bytes) max=256 (blocks)
    > public: slice=4 offset=0 len=143328960 disk_offset=20352
    > private: slice=3 offset=1 len=10175 disk_offset=0
    > update: time=1108557533 seqno=0.183
    > ssb: actual_seqno=0.0
    > headers: 0 248
    > configs: count=1 len=7489
    > logs: count=1 len=1134
    > Multipathing information:
    > numpaths: 1
    > sda state=enabled
    > <<<<<<<<<<<<<<<<<<<<<<< end
    >
    > So, it seems to see public in slice 5 and private in 4. On all disks _different_
    > paths
    >
    >
    >>OK, so that is the problem, now the fix.
    >>
    >>You say you want to start with GR3, so let's do it !!
    >>
    >>The first thing we have to do, is tell volume Manager to forget about
    >>the sliced disks. After that, we will tell volume manager to look at
    >>them agani, but to look at them as simple disks.
    >>
    >>So the steps are:
    >>
    >>vxdisk rm sdab
    >>vxdisk define sdab type=simple
    >>
    >>...
    >>...
    >>
    >>
    >>
    >>Once you've done all the disks, then look at them again through a
    >>"vxdisk list"
    >>
    >>
    >>It should not show the "aliased" anymore and the TYPE should show "simple"
    >>
    >>
    >>
    >>If the "vxdisk list sda" does not show the public and private regions on

    >
    >
    >>the same slice, all we need to do, is to remove the disk (vxdisk rm) and

    >
    >
    >>define it again as a "sliced" disk (the problem is with the "auto" or
    >>CDS disk)
    >>

    >
    >
    > Yes, it is a CDS disk: created under Solaris8, now trying to read it under
    > Linux. As I said, we are geting a replacement Slaris box, but in th meantime
    > we need access to data - and I do _not_, I repeat: I do NOT, trust the backups
    > of most of it.
    >
    >>>>>>>>>>>>>>>>>>>>>>>>>snip! <<<<<<<<<<<<<<<<<<<<<<<


  7. Re: vxdg fails to import - "No valid disk found containing disk

    Tom


    no problems.


    There was smoething else that we could have tried (never tested it
    myself, but will as soon as I can).

    The "vxcdsconvert" utility might have worked as well. (Biggest issue is
    that it will only work on diskgroups in a "perfect" state - any problems
    on the diskgroup, and you're stuffed)


    Hope you get it going



    Tom Korycki wrote:
    > Me wrote:
    >
    >>Tom
    >>
    >>From the vxdisk list output:
    >>
    >>
    >>>pubpaths: block=/dev/vx/dmp/sda5 char=/dev/vx/rdmp/sda5
    >>>privpaths: block=/dev/vx/dmp/sda4 char=/dev/vx/rdmp/sda4

    >>
    >>This is a "normal" sliced disk created with an older version of Volume
    >>Manager (Like 3.11 --> 3.5). On Solaris, this means that it used to be
    >>slices 3 and 4. There might have been a cylinder left for the CDS, but
    >>this is not a disk created in version 4.0.
    >>
    >>
    >>Version 4.0 does it a bit differently. It will create only slice 7 (on
    >>Solaris) and will put the disk format down as auto:cds
    >>
    >>Here, Volume Manager picked up the private region, and put the the disk

    >
    >
    >>format as "auto:sliced"
    >>
    >>What you need to do, is get the format just as "sliced"
    >>
    >>
    >>Thus, you need to remove the current disk from Volume Manager
    >>
    >>vxdisk rm sda
    >>
    >>
    >>And then specify the disktype as sliced (not auto)
    >>
    >>vxdisk define sda type=sliced
    >>
    >>
    >>NOW, when you look at the "vxdisk -o alldgs list" output, you should see

    >
    >
    >>the disk again, but the entry should look like:
    >>
    >>DEVICE TYPE DISK GROUP STATUS
    >>sda sliced - (GR2) online
    >>
    >>
    >>
    >>(Notice that the TYPE should change from "auto:sliced" to "sliced" and
    >>the STATUS should change frmo "online aliased" to "online")
    >>
    >>
    >>Once you do that to all the disks, you will be able to import the
    >>diskgroups.
    >>

    >
    >
    > Well, it (IT?) ws getting down to the wire, so I "liberated" a Sun box from
    > someone (Blade1k), moved the QLogics to it and started that way: after all,
    > there is the endianness issue You have mentioned in (I think) Your first
    > reply... So now I have a whole new set of probs: HBAs only show up after
    > reboot,probe-scsi-all,reset-all,probe-scsi-all sequence and never show up
    > in Solaris, not even to qlogic utilities. But that's a whole new set of nntp
    > headers that doesn't belong here...
    >
    > Me , Thank You so much, I wish I had time to see it through to resolution
    > (and show Linux as a viable tool), but time grew too short. Thanks again
    > for all the calm advice! And who knows - maybe I'll b able to repay the favour
    > - some day.
    >
    > Tom. (who's glad NGs are still as great a tool as they used to be!)
    >
    >>>>>>>>>>>>>>>>>>>>>>>snip! <<<<<<<<<<<<<<<<<<<<<<<


  8. Re: vxdg fails to import - "No valid disk found containing disk


    Me wrote:
    >Tom
    >
    > From the vxdisk list output:
    >
    > > pubpaths: block=/dev/vx/dmp/sda5 char=/dev/vx/rdmp/sda5
    > > privpaths: block=/dev/vx/dmp/sda4 char=/dev/vx/rdmp/sda4

    >
    >This is a "normal" sliced disk created with an older version of Volume
    >Manager (Like 3.11 --> 3.5). On Solaris, this means that it used to be
    >slices 3 and 4. There might have been a cylinder left for the CDS, but
    >this is not a disk created in version 4.0.
    >
    >
    >Version 4.0 does it a bit differently. It will create only slice 7 (on
    >Solaris) and will put the disk format down as auto:cds
    >
    >Here, Volume Manager picked up the private region, and put the the disk


    >format as "auto:sliced"
    >
    >What you need to do, is get the format just as "sliced"
    >
    >
    >Thus, you need to remove the current disk from Volume Manager
    >
    >vxdisk rm sda
    >
    >
    >And then specify the disktype as sliced (not auto)
    >
    >vxdisk define sda type=sliced
    >
    >
    >NOW, when you look at the "vxdisk -o alldgs list" output, you should see


    >the disk again, but the entry should look like:
    >
    >DEVICE TYPE DISK GROUP STATUS
    >sda sliced - (GR2) online
    >
    >
    >
    >(Notice that the TYPE should change from "auto:sliced" to "sliced" and
    >the STATUS should change frmo "online aliased" to "online")
    >
    >
    >Once you do that to all the disks, you will be able to import the
    >diskgroups.
    >


    Well, it (IT?) ws getting down to the wire, so I "liberated" a Sun box from
    someone (Blade1k), moved the QLogics to it and started that way: after all,
    there is the endianness issue You have mentioned in (I think) Your first
    reply... So now I have a whole new set of probs: HBAs only show up after
    reboot,probe-scsi-all,reset-all,probe-scsi-all sequence and never show up
    in Solaris, not even to qlogic utilities. But that's a whole new set of nntp
    headers that doesn't belong here...

    Me , Thank You so much, I wish I had time to see it through to resolution
    (and show Linux as a viable tool), but time grew too short. Thanks again
    for all the calm advice! And who knows - maybe I'll b able to repay the favour
    - some day.

    Tom. (who's glad NGs are still as great a tool as they used to be!)
    >>>>>>>>>>>>>>>>>>>>>> snip! <<<<<<<<<<<<<<<<<<<<<<<


+ Reply to Thread