Discussion:
[Veritas-vx] Weird problem in VCS
alok tiwari
2010-04-27 13:54:53 UTC
Permalink
All,

I just noticed a weird problem with the VCS. I have placed few of my Solaris
Non global zones as a part of cluster service group. The issue is when i
shutdown a zone manually ( zlogin shutdown <zone-name> init 0 ) , the state
of the zone is changed to " INSTALED " . When i try to reboot the zone, it
fails complaining that the zones should be installed before booting, which
is confusing.

Below is the error message.


*root# zoneadm -z zonename boot*

*zoneadm: zone 'zonename': must be installed before boot.*

The zoneadm list -cv shows the zone as INSTALLED.

I tried to verify the zone config and it failes with the below error.


*root# zoneadm -z zonename verify Cannot verify detached zone.*

*Use attach or remove /zones/zonename/zonename-source.11436*

*directory.*
*could not verify zonepath /zones/zonename/zonename-source.11436*
***because of the above errors.*
zoneadm: zone zonename failed to verify on < Global zone name >


Can anyone please help.
--
With Regards:-
Alok Tiwari
Tony Griffiths
2010-04-27 13:58:31 UTC
Permalink
One explanation is that you manually shut them down the zones whilst
they are being monitored by VCS

VCS could interpret that as a fault and start taking action.



Try checking the resource states within VCS



Cheers

tony



From: veritas-vx-***@mailman.eng.auburn.edu
[mailto:veritas-vx-***@mailman.eng.auburn.edu] On Behalf Of alok
tiwari
Sent: 27 April 2010 14:55
To: Veritas-***@mailman.eng.auburn.edu
Cc: ***@gmail.com
Subject: [Veritas-vx] Weird problem in VCS



All,



I just noticed a weird problem with the VCS. I have placed few of my
Solaris Non global zones as a part of cluster service group. The issue
is when i shutdown a zone manually ( zlogin shutdown <zone-name> init 0
) , the state of the zone is changed to " INSTALED " . When i try to
reboot the zone, it fails complaining that the zones should be installed
before booting, which is confusing.



Below is the error message.



root# zoneadm -z zonename boot

zoneadm: zone 'zonename': must be installed before boot.


The zoneadm list -cv shows the zone as INSTALLED.



I tried to verify the zone config and it failes with the below error.



root# zoneadm -z zonename verify Cannot verify detached zone.

Use attach or remove /zones/zonename/zonename-source.11436

directory.

could not verify zonepath /zones/zonename/zonename-source.11436

because of the above errors.

zoneadm: zone zonename failed to verify on < Global zone name >





Can anyone please help.
--
With Regards:-
Alok Tiwari
alok tiwari
2010-04-27 14:24:25 UTC
Permalink
Hi Tony,

Thanks for the reply. I agree that VCS sees that the zone resources are
going offline and the cluster can take corrective action. But in my case, i
have sett he zone resources not to be critical, intentionaly to avoid the
failover of the whole service group. What i understand is that the
corrective actions taken by VCS should be bringing the resource up or
something like that.

Correct me, if i am wrong but, How can VCS change the state of the zone. The
zone was in running state, if i shutdown a resource ( zone in my case ), it
should go in configured state. The VCS say should no way change the state
of the zone. Otherwise it is very much confusing.

Thanks
Alok

On Tue, Apr 27, 2010 at 2:58 PM,
Send Veritas-vx mailing list submissions to
To subscribe or unsubscribe via the World Wide Web, visit
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
or, via email, send a message with subject or body 'help' to
You can reach the person managing the list at
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Veritas-vx digest..."
1. Re: Can I increse /opt partition under veritas (Hudes, Dana)
2. Veritas SF Basic Licensing Keys (Sengor)
3. Weird problem in VCS (alok tiwari)
4. Re: Weird problem in VCS (Tony Griffiths)
----------------------------------------------------------------------
Message: 1
Date: Wed, 7 Apr 2010 11:17:56 -0400
Subject: Re: [Veritas-vx] Can I increse /opt partition under veritas
Content-Type: text/plain; charset="us-ascii"
yes, the boot failure was for a zone which inherited pieces of /opt
(/opt/csw, /opt/netbeans...). don't inherit-pkg-dir /opt though, then you
can't ever add your own directories to /opt in the zone.
Nonetheless as I said /opt on a separate filesystem is not supported by
Sun. It will make lucreate fail among other things.
________________________________
Sent: Sunday, April 04, 2010 10:43 AM
To: Hudes, Dana
Cc: milind phanse; VeritasUsers
Subject: Re: [Veritas-vx] Can I increse /opt partition under veritas
Was the issue with /opt being an inherited directory in a Zone? That is
documented in the Install Guide for SF 5.0 MP3
having /opt as a separate filesystem isn't supported by Solaris. You can
have stuff under /opt (e.g. /opt/coolstack) as a separate filesystem but
putting /opt separate will cause problems.
This isn't theoretical. I tried the same thing and it worked for awhile
then it didn't and the system was in single user mode for agonizing time
while I frantically remounted /opt as /a and moved it's contents back to the
root filesystem.
/var as a separate filesystem is well-supported. There was a bug for awhile
but it's fixed.
________________________________
Sent: Saturday, April 03, 2010 4:21 AM
To: VeritasUsers
Subject: [Veritas-vx] Can I increse /opt partition under veritas
Hi,
Can I increse /opt partition under veritas
Disk group: rootdg
TY NAME ASSOC KSTATE LENGTH PLOFFS STATE TUTIL0
PUTIL0
v opt fsgen ENABLED 8395200 - ACTIVE - -
pl opt-01 opt ENABLED 8395200 - ACTIVE - -
sd rootdisk-03 opt-01 ENABLED 8395200 0 - - -
pl opt-02 opt ENABLED 8395200 - ACTIVE - -
sd rootmirror-05 opt-02 ENABLED 8395200 0 - - -
Maximum volume size: 38952960 (19020Mb)
Volume opt can be extended by 19476480 to: 27871680 (13609Mb+448 sectors)
/opt is mounted on s5 of rootdsik & rootmirror.
_______________________________________________
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
-------------- next part --------------
An HTML attachment was scrubbed...
http://mailman.eng.auburn.edu/pipermail/veritas-vx/attachments/20100407/bf9d9d16/attachment-0001.htm
------------------------------
Message: 2
Date: Tue, 13 Apr 2010 00:36:43 +1000
Subject: [Veritas-vx] Veritas SF Basic Licensing Keys
Content-Type: text/plain; charset=ISO-8859-1
Hi,
I cannot seem to find a straight answer as to why installer keeps
prompting for a valid license when installing SF Basic 5.1 (Solaris
x64 running within VMware - VRTS_SF_Basic_5.1_Solaris_x64.tar.gz).
According to official docs installer is meant to automatically handle
licensing on 2 CPU systems.
bash-3.00# cd storage_foundation_basic/
bash-3.00# ls -la
......
-rwxr-xr-x 1 root root 34 Jun 9 2006 .key
.....
bash-3.00# cat .key
IEZH-I6ZX-KDYE-6PA6-J3PP-TOCP-NCP
bash-3.00# /opt/VRTS/bin/vxlicinst
Symantec License Manager vxlicinst utility version 3.02.34.0
Copyright (C) 1996-2008 Symantec Corporation. All rights reserved.
Enter your license key : IEZH-I6ZX-KDYE-6PA6-J3PP-TOCP-NCP
vxlicinst ERROR V-21-1-65 Invalid Operating System. Input license key
is not valid for this Operating System
bash-3.00# isainfo -vk
64-bit amd64 kernel modules
bash-3.00# psrinfo
0 on-line since 04/12/2010 23:17:07
1 on-line since 04/12/2010 23:17:11
bash-3.00# psrinfo -v
Status of virtual processor 0 as of: 04/12/2010 23:47:12
on-line since 04/12/2010 23:28:12.
The i386 processor operates at 3780 MHz,
and has an i387 compatible floating point processor.
Status of virtual processor 1 as of: 04/12/2010 23:47:12
on-line since 04/12/2010 23:28:14.
The i386 processor operates at 3780 MHz,
and has an i387 compatible floating point processor.
bash-3.00# uname -a
SunOS node1 5.10 Generic_141445-09 i86pc i386 i86pc
Any tips?
--
sengork
------------------------------
Message: 3
Date: Tue, 27 Apr 2010 14:54:53 +0100
Subject: [Veritas-vx] Weird problem in VCS
Content-Type: text/plain; charset="iso-8859-1"
All,
I just noticed a weird problem with the VCS. I have placed few of my
Solaris
Non global zones as a part of cluster service group. The issue is when i
shutdown a zone manually ( zlogin shutdown <zone-name> init 0 ) , the state
of the zone is changed to " INSTALED " . When i try to reboot the zone, it
fails complaining that the zones should be installed before booting, which
is confusing.
Below is the error message.
*root# zoneadm -z zonename boot*
*zoneadm: zone 'zonename': must be installed before boot.*
The zoneadm list -cv shows the zone as INSTALLED.
I tried to verify the zone config and it failes with the below error.
*root# zoneadm -z zonename verify Cannot verify detached zone.*
*Use attach or remove /zones/zonename/zonename-source.11436*
*directory.*
*could not verify zonepath /zones/zonename/zonename-source.11436*
***because of the above errors.*
zoneadm: zone zonename failed to verify on < Global zone name >
Can anyone please help.
--
With Regards:-
Alok Tiwari
-------------- next part --------------
An HTML attachment was scrubbed...
http://mailman.eng.auburn.edu/pipermail/veritas-vx/attachments/20100427/37323de5/attachment-0001.htm
------------------------------
Message: 4
Date: Tue, 27 Apr 2010 14:58:31 +0100
Subject: Re: [Veritas-vx] Weird problem in VCS
<
Content-Type: text/plain; charset="us-ascii"
One explanation is that you manually shut them down the zones whilst
they are being monitored by VCS
VCS could interpret that as a fault and start taking action.
Try checking the resource states within VCS
Cheers
tony
tiwari
Sent: 27 April 2010 14:55
Subject: [Veritas-vx] Weird problem in VCS
All,
I just noticed a weird problem with the VCS. I have placed few of my
Solaris Non global zones as a part of cluster service group. The issue
is when i shutdown a zone manually ( zlogin shutdown <zone-name> init 0
) , the state of the zone is changed to " INSTALED " . When i try to
reboot the zone, it fails complaining that the zones should be installed
before booting, which is confusing.
Below is the error message.
root# zoneadm -z zonename boot
zoneadm: zone 'zonename': must be installed before boot.
The zoneadm list -cv shows the zone as INSTALLED.
I tried to verify the zone config and it failes with the below error.
root# zoneadm -z zonename verify Cannot verify detached zone.
Use attach or remove /zones/zonename/zonename-source.11436
directory.
could not verify zonepath /zones/zonename/zonename-source.11436
because of the above errors.
zoneadm: zone zonename failed to verify on < Global zone name >
Can anyone please help.
--
With Regards:-
Alok Tiwari
-------------- next part --------------
An HTML attachment was scrubbed...
http://mailman.eng.auburn.edu/pipermail/veritas-vx/attachments/20100427/aec42e37/attachment.htm
------------------------------
_______________________________________________
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
End of Veritas-vx Digest, Vol 47, Issue 3
*****************************************
--
With Regards:-
Alok Tiwari
09819733350
Tony Griffiths
2010-04-27 14:32:22 UTC
Permalink
Hi Alok

Agreed. Could you check the state of the VCS resource that make up the
zone.

Cheers

tony



From: veritas-vx-***@mailman.eng.auburn.edu
[mailto:veritas-vx-***@mailman.eng.auburn.edu] On Behalf Of alok
tiwari
Sent: 27 April 2010 15:24
To: Veritas-***@mailman.eng.auburn.edu; Tony Griffiths
Subject: Re: [Veritas-vx] Weird problem in VCS



Hi Tony,



Thanks for the reply. I agree that VCS sees that the zone resources are
going offline and the cluster can take corrective action. But in my
case, i have sett he zone resources not to be critical, intentionaly to
avoid the failover of the whole service group. What i understand is that
the corrective actions taken by VCS should be bringing the resource up
or something like that.



Correct me, if i am wrong but, How can VCS change the state of the zone.
The zone was in running state, if i shutdown a resource ( zone in my
case ), it should go in configured state. The VCS say should no way
change the state of the zone. Otherwise it is very much confusing.



Thanks

Alok

On Tue, Apr 27, 2010 at 2:58 PM,
<veritas-vx-***@mailman.eng.auburn.edu> wrote:

Send Veritas-vx mailing list submissions to
veritas-***@mailman.eng.auburn.edu

To subscribe or unsubscribe via the World Wide Web, visit
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
or, via email, send a message with subject or body 'help' to
veritas-vx-***@mailman.eng.auburn.edu

You can reach the person managing the list at
veritas-vx-***@mailman.eng.auburn.edu

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Veritas-vx digest..."


Today's Topics:

1. Re: Can I increse /opt partition under veritas (Hudes, Dana)
2. Veritas SF Basic Licensing Keys (Sengor)
3. Weird problem in VCS (alok tiwari)
4. Re: Weird problem in VCS (Tony Griffiths)


----------------------------------------------------------------------

Message: 1
Date: Wed, 7 Apr 2010 11:17:56 -0400
From: "Hudes, Dana" <***@hra.nyc.gov>
Subject: Re: [Veritas-vx] Can I increse /opt partition under veritas
To: William Havey <***@gmail.com>
Cc: VeritasUsers <veritas-***@mailman.eng.auburn.edu>, milind phanse
<***@yahoo.com>
Message-ID:

<***@XCH2.windows.nyc.hra.nycnet>

Content-Type: text/plain; charset="us-ascii"

yes, the boot failure was for a zone which inherited pieces of /opt
(/opt/csw, /opt/netbeans...). don't inherit-pkg-dir /opt though, then
you can't ever add your own directories to /opt in the zone.
Nonetheless as I said /opt on a separate filesystem is not supported by
Sun. It will make lucreate fail among other things.


________________________________
From: William Havey [mailto:***@gmail.com]
Sent: Sunday, April 04, 2010 10:43 AM
To: Hudes, Dana
Cc: milind phanse; VeritasUsers
Subject: Re: [Veritas-vx] Can I increse /opt partition under veritas

Was the issue with /opt being an inherited directory in a Zone? That is
documented in the Install Guide for SF 5.0 MP3

On Sat, Apr 3, 2010 at 9:15 PM, Hudes, Dana
<***@hra.nyc.gov<mailto:***@hra.nyc.gov>> wrote:
having /opt as a separate filesystem isn't supported by Solaris. You can
have stuff under /opt (e.g. /opt/coolstack) as a separate filesystem but
putting /opt separate will cause problems.
This isn't theoretical. I tried the same thing and it worked for awhile
then it didn't and the system was in single user mode for agonizing time
while I frantically remounted /opt as /a and moved it's contents back to
the root filesystem.

/var as a separate filesystem is well-supported. There was a bug for
awhile but it's fixed.


________________________________
From:
veritas-vx-***@mailman.eng.auburn.edu<mailto:veritas-vx-***@mail
man.eng.auburn.edu>
[mailto:veritas-vx-***@mailman.eng.auburn.edu<mailto:veritas-vx-boun
***@mailman.eng.auburn.edu>] On Behalf Of milind phanse
Sent: Saturday, April 03, 2010 4:21 AM
To: VeritasUsers
Subject: [Veritas-vx] Can I increse /opt partition under veritas

Hi,

Can I increse /opt partition under veritas

***@backup02<mailto:***@backup02> # vxprint opt
Disk group: rootdg
TY NAME ASSOC KSTATE LENGTH PLOFFS STATE TUTIL0
PUTIL0
v opt fsgen ENABLED 8395200 - ACTIVE -
-
pl opt-01 opt ENABLED 8395200 - ACTIVE -
-
sd rootdisk-03 opt-01 ENABLED 8395200 0 - -
-
pl opt-02 opt ENABLED 8395200 - ACTIVE -
-
sd rootmirror-05 opt-02 ENABLED 8395200 0 - -
-
***@backup02<mailto:***@backup02> # vxassist -g rootdg maxsize
Maximum volume size: 38952960 (19020Mb)

***@backup02<mailto:***@backup02> # vxassist -g rootdg maxgrow opt
Volume opt can be extended by 19476480 to: 27871680 (13609Mb+448
sectors)

/opt is mounted on s5 of rootdsik & rootmirror.



_______________________________________________
Veritas-vx maillist -
Veritas-***@mailman.eng.auburn.edu<mailto:Veritas-***@mailman.eng.auburn.e
du>
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://mailman.eng.auburn.edu/pipermail/veritas-vx/attachments/20100407/
bf9d9d16/attachment-0001.htm

------------------------------

Message: 2
Date: Tue, 13 Apr 2010 00:36:43 +1000
From: Sengor <***@gmail.com>
Subject: [Veritas-vx] Veritas SF Basic Licensing Keys
To: veritas-***@mailman.eng.auburn.edu
Message-ID:
<***@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Hi,

I cannot seem to find a straight answer as to why installer keeps
prompting for a valid license when installing SF Basic 5.1 (Solaris
x64 running within VMware - VRTS_SF_Basic_5.1_Solaris_x64.tar.gz).
According to official docs installer is meant to automatically handle
licensing on 2 CPU systems.

Bundled key doesn't seem to work either:

bash-3.00# cd storage_foundation_basic/
bash-3.00# ls -la
......
-rwxr-xr-x 1 root root 34 Jun 9 2006 .key
.....
bash-3.00# cat .key
IEZH-I6ZX-KDYE-6PA6-J3PP-TOCP-NCP

bash-3.00# /opt/VRTS/bin/vxlicinst
Symantec License Manager vxlicinst utility version 3.02.34.0
Copyright (C) 1996-2008 Symantec Corporation. All rights reserved.
Enter your license key : IEZH-I6ZX-KDYE-6PA6-J3PP-TOCP-NCP
vxlicinst ERROR V-21-1-65 Invalid Operating System. Input license key
is not valid for this Operating System

bash-3.00# isainfo -vk
64-bit amd64 kernel modules
bash-3.00# psrinfo
0 on-line since 04/12/2010 23:17:07
1 on-line since 04/12/2010 23:17:11

bash-3.00# psrinfo -v
Status of virtual processor 0 as of: 04/12/2010 23:47:12
on-line since 04/12/2010 23:28:12.
The i386 processor operates at 3780 MHz,
and has an i387 compatible floating point processor.
Status of virtual processor 1 as of: 04/12/2010 23:47:12
on-line since 04/12/2010 23:28:14.
The i386 processor operates at 3780 MHz,
and has an i387 compatible floating point processor.

bash-3.00# uname -a
SunOS node1 5.10 Generic_141445-09 i86pc i386 i86pc


Any tips?

--
sengork


------------------------------

Message: 3
Date: Tue, 27 Apr 2010 14:54:53 +0100
From: alok tiwari <***@gmail.com>
Subject: [Veritas-vx] Weird problem in VCS
To: Veritas-***@mailman.eng.auburn.edu
Cc: ***@gmail.com
Message-ID:
<***@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

All,

I just noticed a weird problem with the VCS. I have placed few of my
Solaris
Non global zones as a part of cluster service group. The issue is when i
shutdown a zone manually ( zlogin shutdown <zone-name> init 0 ) , the
state
of the zone is changed to " INSTALED " . When i try to reboot the zone,
it
fails complaining that the zones should be installed before booting,
which
is confusing.

Below is the error message.


*root# zoneadm -z zonename boot*

*zoneadm: zone 'zonename': must be installed before boot.*

The zoneadm list -cv shows the zone as INSTALLED.

I tried to verify the zone config and it failes with the below error.


*root# zoneadm -z zonename verify Cannot verify detached zone.*

*Use attach or remove /zones/zonename/zonename-source.11436*

*directory.*
*could not verify zonepath /zones/zonename/zonename-source.11436*
***because of the above errors.*
zoneadm: zone zonename failed to verify on < Global zone name >


Can anyone please help.

--
With Regards:-
Alok Tiwari
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://mailman.eng.auburn.edu/pipermail/veritas-vx/attachments/20100427/
37323de5/attachment-0001.htm

------------------------------

Message: 4
Date: Tue, 27 Apr 2010 14:58:31 +0100
From: "Tony Griffiths" <***@symantec.com>
Subject: Re: [Veritas-vx] Weird problem in VCS
To: "alok tiwari" <***@gmail.com>,
<Veritas-***@mailman.eng.auburn.edu>
Message-ID:

<***@DUB2XCHCLUPIN03.enterprise.ver
itas.com>

Content-Type: text/plain; charset="us-ascii"

One explanation is that you manually shut them down the zones whilst
they are being monitored by VCS

VCS could interpret that as a fault and start taking action.



Try checking the resource states within VCS



Cheers

tony



From: veritas-vx-***@mailman.eng.auburn.edu
[mailto:veritas-vx-***@mailman.eng.auburn.edu] On Behalf Of alok
tiwari
Sent: 27 April 2010 14:55
To: Veritas-***@mailman.eng.auburn.edu
Cc: ***@gmail.com
Subject: [Veritas-vx] Weird problem in VCS



All,



I just noticed a weird problem with the VCS. I have placed few of my
Solaris Non global zones as a part of cluster service group. The issue
is when i shutdown a zone manually ( zlogin shutdown <zone-name> init 0
) , the state of the zone is changed to " INSTALED " . When i try to
reboot the zone, it fails complaining that the zones should be installed
before booting, which is confusing.



Below is the error message.



root# zoneadm -z zonename boot

zoneadm: zone 'zonename': must be installed before boot.


The zoneadm list -cv shows the zone as INSTALLED.



I tried to verify the zone config and it failes with the below error.



root# zoneadm -z zonename verify Cannot verify detached zone.

Use attach or remove /zones/zonename/zonename-source.11436

directory.

could not verify zonepath /zones/zonename/zonename-source.11436

because of the above errors.

zoneadm: zone zonename failed to verify on < Global zone name >





Can anyone please help.


--
With Regards:-
Alok Tiwari

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://mailman.eng.auburn.edu/pipermail/veritas-vx/attachments/20100427/
aec42e37/attachment.htm

------------------------------

_______________________________________________
Veritas-vx maillist - Veritas-***@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx


End of Veritas-vx Digest, Vol 47, Issue 3
*****************************************
--
With Regards:-
Alok Tiwari
09819733350
alok tiwari
2010-04-27 16:05:12 UTC
Permalink
Tony,

As this is a production box, I can not take it down. But as the SG is
parallel service group, but the zone resources were not critical, hence
the cluster resource would have gone in error and the SG partial online.
Also, I am sure that this is not a one off case. The same happened with 6
zones ( 3 each on both the cluster nodes ) and all of them went into
installed state when shutdown. And I am sure VCS is the cluprit. I need to
find out why. :D And i will surely moniter the cluster resources status next
time, i reboot the zone.

Any suggestions will be welcome ?

Thanks
Alok
Post by Tony Griffiths
Hi Alok
Agreed. Could you check the state of the VCS resource that make up the
zone.
Cheers
tony
*Sent:* 27 April 2010 15:24
*Subject:* Re: [Veritas-vx] Weird problem in VCS
Hi Tony,
Thanks for the reply. I agree that VCS sees that the zone resources are
going offline and the cluster can take corrective action. But in my case, i
have sett he zone resources not to be critical, intentionaly to avoid the
failover of the whole service group. What i understand is that the
corrective actions taken by VCS should be bringing the resource up or
something like that.
Correct me, if i am wrong but, How can VCS change the state of the zone.
The zone was in running state, if i shutdown a resource ( zone in my case ),
it should go in configured state. The VCS say should no way change the
state of the zone. Otherwise it is very much confusing.
Thanks
Alok
On Tue, Apr 27, 2010 at 2:58 PM, <
Send Veritas-vx mailing list submissions to
To subscribe or unsubscribe via the World Wide Web, visit
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
or, via email, send a message with subject or body 'help' to
You can reach the person managing the list at
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Veritas-vx digest..."
1. Re: Can I increse /opt partition under veritas (Hudes, Dana)
2. Veritas SF Basic Licensing Keys (Sengor)
3. Weird problem in VCS (alok tiwari)
4. Re: Weird problem in VCS (Tony Griffiths)
----------------------------------------------------------------------
Message: 1
Date: Wed, 7 Apr 2010 11:17:56 -0400
Subject: Re: [Veritas-vx] Can I increse /opt partition under veritas
Content-Type: text/plain; charset="us-ascii"
yes, the boot failure was for a zone which inherited pieces of /opt
(/opt/csw, /opt/netbeans...). don't inherit-pkg-dir /opt though, then you
can't ever add your own directories to /opt in the zone.
Nonetheless as I said /opt on a separate filesystem is not supported by
Sun. It will make lucreate fail among other things.
________________________________
Sent: Sunday, April 04, 2010 10:43 AM
To: Hudes, Dana
Cc: milind phanse; VeritasUsers
Subject: Re: [Veritas-vx] Can I increse /opt partition under veritas
Was the issue with /opt being an inherited directory in a Zone? That is
documented in the Install Guide for SF 5.0 MP3
having /opt as a separate filesystem isn't supported by Solaris. You can
have stuff under /opt (e.g. /opt/coolstack) as a separate filesystem but
putting /opt separate will cause problems.
This isn't theoretical. I tried the same thing and it worked for awhile
then it didn't and the system was in single user mode for agonizing time
while I frantically remounted /opt as /a and moved it's contents back to the
root filesystem.
/var as a separate filesystem is well-supported. There was a bug for awhile
but it's fixed.
________________________________
Sent: Saturday, April 03, 2010 4:21 AM
To: VeritasUsers
Subject: [Veritas-vx] Can I increse /opt partition under veritas
Hi,
Can I increse /opt partition under veritas
Disk group: rootdg
TY NAME ASSOC KSTATE LENGTH PLOFFS STATE TUTIL0
PUTIL0
v opt fsgen ENABLED 8395200 - ACTIVE - -
pl opt-01 opt ENABLED 8395200 - ACTIVE - -
sd rootdisk-03 opt-01 ENABLED 8395200 0 - - -
pl opt-02 opt ENABLED 8395200 - ACTIVE - -
sd rootmirror-05 opt-02 ENABLED 8395200 0 - - -
Maximum volume size: 38952960 (19020Mb)
Volume opt can be extended by 19476480 to: 27871680 (13609Mb+448 sectors)
/opt is mounted on s5 of rootdsik & rootmirror.
_______________________________________________
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
-------------- next part --------------
An HTML attachment was scrubbed...
http://mailman.eng.auburn.edu/pipermail/veritas-vx/attachments/20100407/bf9d9d16/attachment-0001.htm
------------------------------
Message: 2
Date: Tue, 13 Apr 2010 00:36:43 +1000
Subject: [Veritas-vx] Veritas SF Basic Licensing Keys
Content-Type: text/plain; charset=ISO-8859-1
Hi,
I cannot seem to find a straight answer as to why installer keeps
prompting for a valid license when installing SF Basic 5.1 (Solaris
x64 running within VMware - VRTS_SF_Basic_5.1_Solaris_x64.tar.gz).
According to official docs installer is meant to automatically handle
licensing on 2 CPU systems.
bash-3.00# cd storage_foundation_basic/
bash-3.00# ls -la
......
-rwxr-xr-x 1 root root 34 Jun 9 2006 .key
.....
bash-3.00# cat .key
IEZH-I6ZX-KDYE-6PA6-J3PP-TOCP-NCP
bash-3.00# /opt/VRTS/bin/vxlicinst
Symantec License Manager vxlicinst utility version 3.02.34.0
Copyright (C) 1996-2008 Symantec Corporation. All rights reserved.
Enter your license key : IEZH-I6ZX-KDYE-6PA6-J3PP-TOCP-NCP
vxlicinst ERROR V-21-1-65 Invalid Operating System. Input license key
is not valid for this Operating System
bash-3.00# isainfo -vk
64-bit amd64 kernel modules
bash-3.00# psrinfo
0 on-line since 04/12/2010 23:17:07
1 on-line since 04/12/2010 23:17:11
bash-3.00# psrinfo -v
Status of virtual processor 0 as of: 04/12/2010 23:47:12
on-line since 04/12/2010 23:28:12.
The i386 processor operates at 3780 MHz,
and has an i387 compatible floating point processor.
Status of virtual processor 1 as of: 04/12/2010 23:47:12
on-line since 04/12/2010 23:28:14.
The i386 processor operates at 3780 MHz,
and has an i387 compatible floating point processor.
bash-3.00# uname -a
SunOS node1 5.10 Generic_141445-09 i86pc i386 i86pc
Any tips?
--
sengork
------------------------------
Message: 3
Date: Tue, 27 Apr 2010 14:54:53 +0100
Subject: [Veritas-vx] Weird problem in VCS
Content-Type: text/plain; charset="iso-8859-1"
All,
I just noticed a weird problem with the VCS. I have placed few of my
Solaris
Non global zones as a part of cluster service group. The issue is when i
shutdown a zone manually ( zlogin shutdown <zone-name> init 0 ) , the state
of the zone is changed to " INSTALED " . When i try to reboot the zone, it
fails complaining that the zones should be installed before booting, which
is confusing.
Below is the error message.
*root# zoneadm -z zonename boot*
*zoneadm: zone 'zonename': must be installed before boot.*
The zoneadm list -cv shows the zone as INSTALLED.
I tried to verify the zone config and it failes with the below error.
*root# zoneadm -z zonename verify Cannot verify detached zone.*
*Use attach or remove /zones/zonename/zonename-source.11436*
*directory.*
*could not verify zonepath /zones/zonename/zonename-source.11436*
***because of the above errors.*
zoneadm: zone zonename failed to verify on < Global zone name >
Can anyone please help.
--
With Regards:-
Alok Tiwari
-------------- next part --------------
An HTML attachment was scrubbed...
http://mailman.eng.auburn.edu/pipermail/veritas-vx/attachments/20100427/37323de5/attachment-0001.htm
------------------------------
Message: 4
Date: Tue, 27 Apr 2010 14:58:31 +0100
Subject: Re: [Veritas-vx] Weird problem in VCS
<
Content-Type: text/plain; charset="us-ascii"
One explanation is that you manually shut them down the zones whilst
they are being monitored by VCS
VCS could interpret that as a fault and start taking action.
Try checking the resource states within VCS
Cheers
tony
tiwari
Sent: 27 April 2010 14:55
Subject: [Veritas-vx] Weird problem in VCS
All,
I just noticed a weird problem with the VCS. I have placed few of my
Solaris Non global zones as a part of cluster service group. The issue
is when i shutdown a zone manually ( zlogin shutdown <zone-name> init 0
) , the state of the zone is changed to " INSTALED " . When i try to
reboot the zone, it fails complaining that the zones should be installed
before booting, which is confusing.
Below is the error message.
root# zoneadm -z zonename boot
zoneadm: zone 'zonename': must be installed before boot.
The zoneadm list -cv shows the zone as INSTALLED.
I tried to verify the zone config and it failes with the below error.
root# zoneadm -z zonename verify Cannot verify detached zone.
Use attach or remove /zones/zonename/zonename-source.11436
directory.
could not verify zonepath /zones/zonename/zonename-source.11436
because of the above errors.
zoneadm: zone zonename failed to verify on < Global zone name >
Can anyone please help.
--
With Regards:-
Alok Tiwari
-------------- next part --------------
An HTML attachment was scrubbed...
http://mailman.eng.auburn.edu/pipermail/veritas-vx/attachments/20100427/aec42e37/attachment.htm
------------------------------
_______________________________________________
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
End of Veritas-vx Digest, Vol 47, Issue 3
*****************************************
--
With Regards:-
Alok Tiwari
09819733350
--
With Regards:-
Alok Tiwari
09819733350
John Cronin
2010-04-27 20:41:55 UTC
Permalink
VCS detaches a zone when it goes OFFLINE (e.g. when either the offline or
clean entry points for the Zone agent run); at least it does this for zones
that fail over from one node to another in certain versions, I am not sure
which version of VCS you are using, or whether there is code to avoid the
detach if you are running the zones in parallel. The detach is done to
allow the zone to fail over to another node if necessary, and then attach
cleanly on the new node.

However, since your zone shows up in the installed state rather than the
configured state should indicate the zone is not detached. On the other
hand, the error messages you mentioned do seem to indicate the zone is
detached. That is a bit confusing; have you tried manually attaching the
zones before booting or verifying? You might have to freeze the resources
first, as VCS might try to run clean when they start to go partially online
outside of VCS control.

Sorry I am not more precise, but I just don't have any Solaris systems to
test test on right now, and I don't feel like booting up two nodes under
VMware on my 2GB laptop, as that is just horribly slow.
--
John Cronin
Post by alok tiwari
Tony,
As this is a production box, I can not take it down. But as the SG is
parallel service group, but the zone resources were not critical, hence
the cluster resource would have gone in error and the SG partial online.
Also, I am sure that this is not a one off case. The same happened with 6
zones ( 3 each on both the cluster nodes ) and all of them went into
installed state when shutdown. And I am sure VCS is the cluprit. I need to
find out why. :D And i will surely moniter the cluster resources status next
time, i reboot the zone.
Any suggestions will be welcome ?
Thanks
Alok
On Tue, Apr 27, 2010 at 3:32 PM, Tony Griffiths <
Post by Tony Griffiths
Hi Alok
Agreed. Could you check the state of the VCS resource that make up the
zone.
Cheers
tony
*Sent:* 27 April 2010 15:24
*Subject:* Re: [Veritas-vx] Weird problem in VCS
Hi Tony,
Thanks for the reply. I agree that VCS sees that the zone resources are
going offline and the cluster can take corrective action. But in my case, i
have sett he zone resources not to be critical, intentionaly to avoid the
failover of the whole service group. What i understand is that the
corrective actions taken by VCS should be bringing the resource up or
something like that.
Correct me, if i am wrong but, How can VCS change the state of the zone.
The zone was in running state, if i shutdown a resource ( zone in my case ),
it should go in configured state. The VCS say should no way change the
state of the zone. Otherwise it is very much confusing.
Thanks
Alok
--
With Regards:-
Alok Tiwari
09819733350
_______________________________________________
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
alok tiwari
2010-04-28 08:38:01 UTC
Permalink
John,

I am manually shutting down the zone. We run on VCS 5.0 MP3 RP1. Let me see
if I will surely try to follow the steps as suggested by you and Tony and
will let you know what I see.

But what i am thinking is, if I manually set shutdown the zone and the zone
resource beingno critical, VCS should not detach it. VCS should only detach
it only when I ask the service group containing the zone resource to
failover.
Thanks to you all, who spared your precious time to help me out.

I will surely get back to you as soon as I execute the suggestions in my
next downtime window.

Thanks
Alok
Post by John Cronin
VCS detaches a zone when it goes OFFLINE (e.g. when either the offline or
clean entry points for the Zone agent run); at least it does this for zones
that fail over from one node to another in certain versions, I am not sure
which version of VCS you are using, or whether there is code to avoid the
detach if you are running the zones in parallel. The detach is done to
allow the zone to fail over to another node if necessary, and then attach
cleanly on the new node.
However, since your zone shows up in the installed state rather than the
configured state should indicate the zone is not detached. On the other
hand, the error messages you mentioned do seem to indicate the zone is
detached. That is a bit confusing; have you tried manually attaching the
zones before booting or verifying? You might have to freeze the resources
first, as VCS might try to run clean when they start to go partially online
outside of VCS control.
Sorry I am not more precise, but I just don't have any Solaris systems to
test test on right now, and I don't feel like booting up two nodes under
VMware on my 2GB laptop, as that is just horribly slow.
--
John Cronin
Post by alok tiwari
Tony,
As this is a production box, I can not take it down. But as the SG is
parallel service group, but the zone resources were not critical, hence
the cluster resource would have gone in error and the SG partial online.
Also, I am sure that this is not a one off case. The same happened with 6
zones ( 3 each on both the cluster nodes ) and all of them went into
installed state when shutdown. And I am sure VCS is the cluprit. I need to
find out why. :D And i will surely moniter the cluster resources status next
time, i reboot the zone.
Any suggestions will be welcome ?
Thanks
Alok
On Tue, Apr 27, 2010 at 3:32 PM, Tony Griffiths <
Post by Tony Griffiths
Hi Alok
Agreed. Could you check the state of the VCS resource that make up the
zone.
Cheers
tony
*Sent:* 27 April 2010 15:24
*Subject:* Re: [Veritas-vx] Weird problem in VCS
Hi Tony,
Thanks for the reply. I agree that VCS sees that the zone resources are
going offline and the cluster can take corrective action. But in my case, i
have sett he zone resources not to be critical, intentionaly to avoid the
failover of the whole service group. What i understand is that the
corrective actions taken by VCS should be bringing the resource up or
something like that.
Correct me, if i am wrong but, How can VCS change the state of the zone.
The zone was in running state, if i shutdown a resource ( zone in my case ),
it should go in configured state. The VCS say should no way change the
state of the zone. Otherwise it is very much confusing.
Thanks
Alok
--
With Regards:-
Alok Tiwari
09819733350
_______________________________________________
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
--
With Regards:-
Alok Tiwari
09819733350
John Cronin
2010-04-28 12:43:05 UTC
Permalink
When you manually shut down the zone, VCS will notice an "unexpected offline
not initiated by VCS" and run the clean entry point, which will detach the
zone. Because it is non-critical, VCS will not fail the service group over,
but it will "clean" the resource (move it to a full offline state, as VCS
defines "offline").

As an alternative to manually rebooting the zone, did you try clearing the
fault on the Zone resource in VCS and then bringing the Zone resource online
in VCS? That should work.

I just noticed you have been sending this to the veritas-vx mailing list -
the veritas-ha mailing list is more specifically for VCS.
Post by alok tiwari
John,
I am manually shutting down the zone. We run on VCS 5.0 MP3 RP1. Let me see
if I will surely try to follow the steps as suggested by you and Tony and
will let you know what I see.
But what i am thinking is, if I manually set shutdown the zone and the zone
resource beingno critical, VCS should not detach it. VCS should only detach
it only when I ask the service group containing the zone resource to
failover.
Thanks to you all, who spared your precious time to help me out.
I will surely get back to you as soon as I execute the suggestions in my
next downtime window.
Thanks
Alok
Post by John Cronin
VCS detaches a zone when it goes OFFLINE (e.g. when either the offline or
clean entry points for the Zone agent run); at least it does this for zones
that fail over from one node to another in certain versions, I am not sure
which version of VCS you are using, or whether there is code to avoid the
detach if you are running the zones in parallel. The detach is done to
allow the zone to fail over to another node if necessary, and then attach
cleanly on the new node.
However, since your zone shows up in the installed state rather than the
configured state should indicate the zone is not detached. On the other
hand, the error messages you mentioned do seem to indicate the zone is
detached. That is a bit confusing; have you tried manually attaching the
zones before booting or verifying? You might have to freeze the resources
first, as VCS might try to run clean when they start to go partially online
outside of VCS control.
Sorry I am not more precise, but I just don't have any Solaris systems to
test test on right now, and I don't feel like booting up two nodes under
VMware on my 2GB laptop, as that is just horribly slow.
--
John Cronin
Post by alok tiwari
Tony,
As this is a production box, I can not take it down. But as the SG is
parallel service group, but the zone resources were not critical, hence
the cluster resource would have gone in error and the SG partial online.
Also, I am sure that this is not a one off case. The same happened with
6 zones ( 3 each on both the cluster nodes ) and all of them went into
installed state when shutdown. And I am sure VCS is the cluprit. I need to
find out why. :D And i will surely moniter the cluster resources status next
time, i reboot the zone.
Any suggestions will be welcome ?
Thanks
Alok
On Tue, Apr 27, 2010 at 3:32 PM, Tony Griffiths <
Post by Tony Griffiths
Hi Alok
Agreed. Could you check the state of the VCS resource that make up the
zone.
Cheers
tony
*Sent:* 27 April 2010 15:24
*Subject:* Re: [Veritas-vx] Weird problem in VCS
Hi Tony,
Thanks for the reply. I agree that VCS sees that the zone resources are
going offline and the cluster can take corrective action. But in my case, i
have sett he zone resources not to be critical, intentionaly to avoid the
failover of the whole service group. What i understand is that the
corrective actions taken by VCS should be bringing the resource up or
something like that.
Correct me, if i am wrong but, How can VCS change the state of the zone.
The zone was in running state, if i shutdown a resource ( zone in my case ),
it should go in configured state. The VCS say should no way change the
state of the zone. Otherwise it is very much confusing.
Thanks
Alok
--
With Regards:-
Alok Tiwari
09819733350
_______________________________________________
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
--
With Regards:-
Alok Tiwari
09819733350
Loading...