VxVM v3.5, unencapsulation and no rootdg

Hello
I would appreciate some help please.
Using VxVM & VxFS v3.5 on Solaris 9.
The root disks were encapsulated with two extra volumes on non root disks.
There are two data volumes within the cdrdg disk group.
I have unencapsulated the root disk and re-booted with the view to:
1. install Disksuite/SVM
2. Deport the data diskgroup located on data disks
3. Remove Veritas VxVM & VxFS v3.5
4. Install Veritas VxVM & VxFS v4.1
5. Import the data diskgroup.
However, on booting after unencapsulating the root disks I get the following errors:
Starting VxVM restore daemon...
VxVM starting in boot mode...
Sep 5 08:37:28 vxvm:vxconfigd: enable failed: Error in disk group configuration copies
Sep 5 08:37:28 vxvm:vxconfigd: No valid disk found containing disk group; transactions are disabled.
Sep 5 08:37:28 vxvm:vxconfigd: Rootdg cannot be imported during boot
VxVM general startup...
vxvm:vxconfigd: ERROR: enable failed: Error in disk group configuration copies
No valid disk found containing disk group; transactions are disabled.
vxvm: Vold is not enabled for transactions
No volumes started
vxvm:vxrecover: ERROR: IPC failure: Configuration daemon is not accessible
Starting VxVM Diskgroup Configuration Log Daemon...
I think that this is due to there now not being a rootdg disk group.
The contents of /etc/vfstab are:
fd - /dev/fd fd - no -
/proc - /proc proc - no -
/dev/md/dsk/d1 - - swap - no -
/dev/md/dsk/d0 /dev/md/rdsk/d0 / ufs 1 no logging
/dev/md/dsk/d3 /dev/md/rdsk/d3 /var ufs 1 no logging
swap - /tmp tmpfs - yes size=512m
#/dev/vx/dsk/cdrdg/cdrt01vol /dev/vx/rdsk/cdrdg/cdrt01vol /cdrt vxfs 1 yes log
#/dev/vx/dsk/cdrdg/cdrc01vol /dev/vx/rdsk/cdrdg/cdrc01vol /cdrc vxfs 1 yes log
Does anyone have any idea what I can do?
I have removed the two Veritas file systems out of /etc/vfstab and the system boots OK but
I can nolonger mount the Veritas volumes.
I have now added DiskSuite/SVM to the root disks and mirrored.
I have not touched the slices 3 & 4, just added a slice 7 from unused disk space.
Should I add the DiskSuite root disks to rootdg, mount the veritas file systems, deport them,
remove Veritas v3.5 and then install V4.1 and import the disk group.
or
just continue with the removal of v3.5 and import the disk group when v4.1 is installed.
Many thanks.

Starting VxVM restore daemon...
VxVM starting in boot mode...
Sep 5 08:37:28 vxvm:vxconfigd: enable failed: Error
in disk group configuration copies
Sep 5 08:37:28 vxvm:vxconfigd: No valid disk found
containing disk group; transactions are disabled.
Sep 5 08:37:28 vxvm:vxconfigd: Rootdg cannot be
imported during boot
VxVM general startup...
vxvm:vxconfigd: ERROR: enable failed: Error in disk
group configuration copies
No valid disk found containing disk group;
transactions are disabled.
vxvm: Vold is not enabled for transactions
No volumes started
vxvm:vxrecover: ERROR: IPC failure: Configuration
daemon is not accessible
Starting VxVM Diskgroup Configuration Log Daemon...
think that this is due to there now not being a
rootdg disk group.Yes.
The contents of /etc/vfstab are:
fd - /dev/fd fd - no -
/proc - /proc proc - no -
/dev/md/dsk/d1 - - swap - no
md/dsk/d0 /dev/md/rdsk/d0 / ufs 1 no
logging
md/dsk/d3 /dev/md/rdsk/d3 /var ufs 1 no
logging
- /tmp tmpfs - yes size=512m
ev/vx/dsk/cdrdg/cdrt01vol
/dev/vx/rdsk/cdrdg/cdrt01vol /cdrt vxfs 1 yes log
/dev/vx/dsk/cdrdg/cdrc01vol
/dev/vx/rdsk/cdrdg/cdrc01vol /cdrc vxfs 1 yes log
Does anyone have any idea what I can do?You could create a new rootdg, or you could ignore it. I'd probably ignore it.
I have removed the two Veritas file systems out of
/etc/vfstab and the system boots OK but
I can nolonger mount the Veritas volumes.Correct. VxVM 3.x (and lower) requires a 'rootdg' group be present.
have now added DiskSuite/SVM to the root disks and
mirrored.
have not touched the slices 3 & 4, just added a
slice 7 from unused disk space.
Should I add the DiskSuite root disks to rootdg,
mount the veritas file systems, deport them,
remove Veritas v3.5 and then install V4.1 and import
the disk group.That would work.
or
just continue with the removal of v3.5 and import the
disk group when v4.1 is installed.That would work as well.
Darren

Similar Messages

VxVM Root disk encapsulation and ufs logging - is it valid?

Hi,
Is it valid to use the UFS mount option "logging" for an encapsulated root disk under VxVM ?
I searched through sunsolve and saw some info about older VxVM releases.
I use 5.0
Thanks
Edited by: AssafL on Nov 11, 2007 1:12 PM

There are some versions of VxVM where that combination is not recommended. I don't recall if all interactions are corrected in 5.0. You might want to search on the Symantec support site.
Darren

Proper procedure for patching from Single User mode

Typically when I install a patch cluster from Sun, I do a sanity reboot from the console of the server using:
shutdown -y -g0 -i6
When the system comes back online, I log into the console again and then do:
shutdown -y -g0 -i0 (to go into OBP)
then
boot -s (to go into single user mode)
The procedure above was given to me from a Sun technician.
Then I install the patch cluster and reboot. It has come to my attention that Sun recommends breaking any mirrors between your disks before patching. I wanted to know what is the best way to do this for both Veritas Volume Manager and Solaris Volume Manager. For Veritas Volume Manager, I was thinking of going into the vxdiskadm menu driven utility and choosing the option to "Remove a disk for replacement" for the rootmirror disk and then after a reboot to check that the patches did not cause a problem, go back into vxdiskadm and choose the option "Replace a failed or removed disk" and select the rootmirror which should then begin to automatically resync itself to the primary rootdisk. Any comments on if this is a proper way to do this or if someone has a better method, I would love to hear it. I am assuming a system with just two internal disks: c1t0d0s2 and c1t1d0s2
Also, if anyone can comment on how to do this with Solaris Volume Manager or if it is required would be great also.
Thanks much for any advice.

Typically when I install a patch cluster from Sun, I
do a sanity reboot from the console of the server
using:
shutdown -y -g0 -i6
When the system comes back online, I log into the
console again and then do:
shutdown -y -g0 -i0 (to go into OBP)
then
boot -s (to go into single user mode)
The procedure above was given to me from a Sun
technician.Not a bad thing to check reboot before patching, but I don't think it's in any official documentation that I'm aware of.
Then I install the patch cluster and reboot. It has
come to my attention that Sun recommends breaking any
mirrors between your disks before patching.Again, I don't know if it's "official", but if you have a backup copy that you could boot from, it does reduce the possibilities of critical problems from a bad patch.
I wanted
to know what is the best way to do this for both
Veritas Volume Manager and Solaris Volume Manager.
For Veritas Volume Manager, I was thinking of going
into the vxdiskadm menu driven utility and choosing
the option to "Remove a disk for replacement" for the
rootmirror disk and then after a reboot to check that
the patches did not cause a problem, go back into
vxdiskadm and choose the option "Replace a failed or
removed disk" and select the rootmirror which should
then begin to automatically resync itself to the
primary rootdisk. Any comments on if this is a proper
way to do this or if someone has a better method, I
would love to hear it. I am assuming a system with
just two internal disks: c1t0d0s2 and c1t1d0s2
Also, if anyone can comment on how to do this with
Solaris Volume Manager or if it is required would be
great also.Well, it'll work as you've described, but what if the patches fail? The disconnected mirror is not bootable. You'd have to go through an unencapsulation and other things from a CD.
I've often simply pulled one side of the mirror while the machine was shutdown. Since the mirror was valid prior to pulling, it will boot. If there's a problem, I shut down, swap disks, and boot from the untouched mirror. If no problem, I re-insert, reattach the disk to the diskgroup, then recover the volumes.
I don't know of any nice supported method of booting from an offline VxVM mirror that doesn't involve a very long series of steps. My method isn't supported, but it does work. If you have both disks in the machine at the same time though, it'll update the private regions. Don't do that until you're ready to sync up one way or the other. Test before doing it in production.
In any event, you should have a backup ready to go.
Darren

Upgrade Solaris 8 from 10/01 to 02/02

Hi all, I need to upgrade some systems from Solaris 8 10/01 to 02/02. I use VxVM 3.2 and VxFS 3.4. I don't need to upgrade Veritas Software. I want use Live Upgrade and in all example I find (2.6 ==> 8) I have to reinstall VxVM. In my situation, is Veritas products reinstallaton mandatory?? Can I use unencapsulation and encapsulation??

Hi,
You have to get volume manager out of the way before you upgrade solaris. You can un-encapsulate the root disk, upgrade then re-encapsulate if you want.
The way I do is as follows:
boot up normally from the vxroot disk.
touch /etc/vx/reconfig.d/state.d/install-db
#This will stop volume manager from starting up in a normal mode. Basically stops all the volume management stuff from interferring
remove the root entries in /etc/system for veritas (e.g. rootdev:/psuedo/vxio@0:0 and set vxio:vol_rootdev_is_volume=1)
#this line tells solaris that the root volume is a veritas device. Without this removed Solaris will try to mount up the root disk as a veritas volume and fail.
cp /etc/vfstab /etc/vfstab.old
cp /etc/vfstab.prevm /etc/vfstab
#replaces the /etc/vfstab file with the pre-volume-manager one
reboot the system.
It will now reboot without volume manager. Boot it all up to make sure there are no problems / errors, the do an init 0, then a boot cdrom - install or whatever to install solaris. upgrade solaris.
Machine will then reboot after Solaris has been upgraded. Re-install volume manager (might not be required if you're on the same solaris version) and re-encapsulate the root disk. Initalise the root-mirror, and mirror the root disk to the mirror (after the 2 reboots that volume manager needs)
Much easier to do the upgrade this way ;)
There are some infodocs on this procedure on the support.veritas.com knowledge base as well, if you want the `preferred veritas endorsed` method..

VPN tunnel between 2 RRAS servers, both performing NAT with 2 network connections

I have a need to configure an IPSEC policy between 2 networks. Both servers are located at separate offices, are virtual, are 2008 R2 standard, and only perform the function of NAT between a public IP and the LAN. They each have 1 network
adapter with a public address and 1 adapter with an internal LAN address. I would like to setup an IPSEC policy between these 2 RRAS so that both LAN's can communicate.
My question's; would this be the best method to get this accomplished? If not, what are best practices? Does anyone have documentation for this type of setup?
I can create a policy between 2 servers, each behind each RRAS vm, but I'd like to keep domain controllers, AD, etc. out of this and not exposed - just have RRAS handle it.

What you need to do is look for a guide to site to site VPN which you can follow. There are plenty out there of varying degrees of clarity and accuracy.
The situation briefly is that each site operates normally using its router as a NAT device to provide Internet access for the LAN. In addition, each router is configured to provide a router to router VPN link. Each router has a static route to forward
traffic for the subnet of the other site through the VPN tunnel.
The net result is that a client wanting Internet access uses NAT to give it an Internet connection. If instead the client wants to access the other site, the request is sent through the VPN tunnel. There is no confusion because Internet addresses must be
public and the site addresses are private. This is all transparent to the client because it is all handled by the routers. The client simply sends the packet to the default gateway.
The private traffic between sites is encrypted and encapsulated while it is crossing the Internet. The Internet routers see only the public address on the wrapper. The other site sees only the private IP of the packet after it has been unencapsulated
and decrypted. The two sites behave as if they were linked by an IP router, but the operation is slow because of the delay in getting the packets from site to site.
Sorry about the link. http://www.youtube.com/watch?v=m-sakEbVDQ4
Bill

Setting up Veritas DMP with a 6140...

Hello!
I'm somewhat experienced with StoreEdge 3510 Arrays and can set them up in my sleep, but I'm having no luck when it comes to setting up Veritas DMP with a 6140 I've somehow become responsible for configuring. Does anyone have any information on ensuring the 6140 array is configured properly so vxvm DMP functions? I've got the luns configured, the host all cabled up, and the luns under vxvm control on a Sun V440 with Solaris 10. I can see the luns, write data to them, but I can't seem to collect the information needed in order to have DMP function. As such, the vxdmpadm command only shows one path to the array despite having four physical FC connections between the 6140 and the V440 server.
Any help is greatly appreciated! I'm sure I'm just "missing something" since this is new hardware to me, but I can't seen to find out what.

All the 6140 setup documentations are on www.sun.com/documentation/.
There is no special step as long as you have a qualified version (for 6140) of VxVM and you install the correct ASL.
At this point, you will need to create the initiators using CAM, with the right host type. In CAM you can select different host type, this defines how the 6140 f/w has to behave when there is failover.
If you use VxVM on the host and DMP, you have to use the host type Solaris DMP for your initiators, at this point the 6140 f/w will not that AVT (Automatic Volume Transfer) has to be turned ON.
Regards

VCS to Sun Cluster migration

I am planning to migrate a 2-node cluster from VCS to Sun Cluster. how much downtime does this involve? is there any documentation that i can reference?

Hi all,
In the following I outlined the principle steps how to migrate a cluster in place. Tis will be one of the subtopics of an upcoming blog about VCS to SC migration.
Pavel, you should revisit SC 3.2 definitely and explicitly the bui. We had various VCS admins on different projects who told us, the gap became that small, that VCS is not worth the additional costs.
Bear in mind that migrating in place is the most complex scenario, and doing it on a complete alternative platform is a much simpler process. But lets proceed with the assumptions and process:
Let us assume a two node cluster where you want to migrate from VCS with VXVM to Solaris Cluster and Solaris Volume Manager. I assume as well that your data is mirrored. The steps below are a principle outline of the migration process, to get the necessary cluster administration commands you need to consult the appropriate documentation.
1.Reduce the VCS cluster to a one node cluster and disconnect the interconnect. The interconnect has to be disconnected to allow a Solaris Cluster installation on the other node. Solaris Cluster check the interconnect for unwanted traffic
2.Split the storage in two halfs, and disallow the access from the VCS cluster to the future Solaris cluster part. This can be achieved in example by modifying the switch zoning, or lun masking. At this point in time your application is still running, but you have no high availability and no data redundancy any more.
3.Install a single node Solaris Cluster on the second host, it is advisable to start with a fresh Solaris install.
4.Configure the full Solaris Cluster topology with a temporary copy of your date. The data has to be installed by backup/restore, because you are changing the volume manager as well. It is important here, that you use different IP addresses for the logical hosts to avoid duplicate addresses. Now the new single node Solaris Cluster is ready to take the actual data.
5.When you are ready for an application downtime, transfer the actual data from the Veritas Cluster again to the Solaris Cluster, and shut down the remaining VCS single node cluster.
6.Change the IP Addresses of the logical host in the Solaris Cluster to the final value and enable all relevant resources. From now on your application will be running on the new Solaris Cluster.
7.Reestablish the interconnect, destroy the VCS cluster and install Solaris Cluster packages on the old VCS node, but do not configure the node yet.
8.Allow data access to the storage for both nodes with appropriate methods.
9.Add the second node to the Solaris Cluster including the Solaris Cluster device groups, this step will take an other short application downtime.
10.Mirror your data. From this point you have full redundancy and full high availability again.
Cheers
Detlef

Co-existence of HDLM and VxVM DMP 5.0

Can HDLM and VxVM DMP 5.0 can exist in same host ?

Hi,
You definitely want to install into a different folder so you
don't overwrite things like the jdeveloper.ini files.
If you have 2.0 installed in a directory like 'C:\JDeveloper',
installe 3.0 in 'C:\JDeveloper 3.0'. You should not have any
problems with a space in the directory name.
Laura
Raphael Roale (guest) wrote:
: John,
: I am now using both JDev 2 and 3, and I did not have any
: problems. Try to install in different folder.
: Raphael
: John Salvo (guest) wrote:
: : I already have JDeveloper 2.0 on my machine, and I recently
: : downloaded JDeveloper 3.0.
: : However, I would like to be able to keep both until such time
I
: : am satisfied with JDeveloper 3.0.
: : Can these two versions co-exist safely on a single machine???
: : Thanks,
: : John Salvo
null

Sun Cluster 3.0 and VxVM 3.2 problems at boot

i 've a little problem with a two node cluster (2 x 480r + 2 x 3310 with a single raid ctl.)
Every 3310 has 3 (raid5) luns .
I've mirrored these 3 luns with VxVM, and i've mirror also the 2 internal (o.s.) disks.
One of the disk of the first 3310 is the quorum disk.
Every time i boot the nodes , i read an error at "block 0" of the quorum disk and then starts a fastidious synchronization of the mirrors. (sometimes also of the os mirror..)
Why does it happen?
Thanks.
Regards,
Mauro.

We did another test today and again the resource group went into a STOP_FAILED state. On this occasion, the export for the corresponding ZFS pool timed-out. We were able to successfully bring the resource group online on the desired cluster node. Subsequent failovers worked fine. There's something strange happening when the zpool is being exported (eg error correction?). Once the zpool is exported, further imports of it seem to work fine.
When we first had the problem, we were able to manually export and import the zpools, though they did take quite some time to export/import.
"zpool list" shows we have a total of 7 zpools.
"zfs list" shows we have a total of 27 zfs file systems.
Is there any specific Sun or otherwise links to any problems with Sun Cluster and ZFS?

Which versin of Vxvm and LOM compatible on Solaris 10?

I want to install two packages onSolaris 10.
1. Veritas Volume Manager
2. Lights out Management
on Netra 210 Box.
Can you please let me know the correct version?
Regards,
Manabendra

1. - Volume manager v 4.1 or later
2. - looks like this is more of an ALOM / OBP versioning question
you can use ALOM 1.0 and 1.1 if your OBP is 4.8.2 or greater
and ALOM 1.2,1.3,1.4,1.5.x,1.6.x if your OBP is at 4.11.4 or greater
please reference infodoc 72255 on sunsolve.sun.com
- jeff

Updating Veritas Vxvm and Veritas foundation

Hi Guys, I would like to upgrade Veritas Volume Manger 4.1 to the most current 5.1. I will also upgrade Veritas foundation at the same time. I am running Solaris 8 on these Servers. Having to do this upgrade for the first time, are there any docs out there or a clear step by step procedure that can help me accomplish this without any Errors. I will also be downloading the Software instead of using a software CD. How do I go about this without creating a mess for myself , what is the safest way of doing this? Thanks for your ideas and your assistance.

Case closed.
I was sort of on the right track. After deleting the .vxlic file one has to init the daemon for the new license.
1, Delete or Move the license key file in /etc/vx/licenses/lic/*.vxlic
2, Then issue: vxdctl license init [enter]
vxdctl license init forces vxconfigd to rescan the licenses and make the new licenses available.
Regards,
Pierre

Sun cluster with vxvm encapsulated rootdisk

Hi,
Can I install vxvm and encasulate rootdisk before installing sun cluster?
Any help is greatly appreciated.
Thanks.

Its suggested to install vxvm and encapsulation using the scvxinstall script which is provided with SunCluster.
This script will do all the job which you have to do manually like reminoring the rootdg etc.

How to setup a RAID-0 disk over 2TB on VxVM.

I am running a 3510FC and VxVM 4.1 on V490 with Solaris 10.
I got a problem when I try to add a RAID-5 LUN to rootdg. I always got a error message "Error V5-2-213".
It said " It is not possible to encapsulate c1t40d1, for the following reason:
<VxVM vxslicer ERROR v-5-1-6922 Unsupported disk layout.
Encapsulation requires at least 0 sectors of unused space either at the beginning or end of the disk drive.>"
The format command is shown as below.
Current partition table (original):
Total disk sectors available: 2341636062 + 16384 (reserved sectors)
Part Tag Flag First Sector Size Last Sector
0 root wm 34 128.00MB 262177
1 swap wu 262178 128.00MB 524321
2 unassigned wm 0 0 0
3 unassigned wm 0 0 0
4 unassigned wm 0 0 0
5 unassigned wm 0 0 0
6 usr wm 524322 1.09TB 2341636061
8 reserved wm 2341636062 8.00MB 2341652445
The LD begins at 34th sector and reserved at the end of disks.
What can I do for this case?
Jeff.

I am running a 3510FC and VxVM 4.1 on V490 with Solaris 10.
I got a problem when I try to add a RAID-5 LUN to rootdg. I always got a error message "Error V5-2-213".
It said " It is not possible to encapsulate c1t40d1, for the following reason:
<VxVM vxslicer ERROR v-5-1-6922 Unsupported disk layout.
Encapsulation requires at least 0 sectors of unused space either at the beginning or end of the disk drive.>"
The format command is shown as below.
Current partition table (original):
Total disk sectors available: 2341636062 + 16384 (reserved sectors)
Part Tag Flag First Sector Size Last Sector
0 root wm 34 128.00MB 262177
1 swap wu 262178 128.00MB 524321
2 unassigned wm 0 0 0
3 unassigned wm 0 0 0
4 unassigned wm 0 0 0
5 unassigned wm 0 0 0
6 usr wm 524322 1.09TB 2341636061
8 reserved wm 2341636062 8.00MB 2341652445
The LD begins at 34th sector and reserved at the end of disks.
What can I do for this case?
Jeff.

What is difference between SUNW,UltraSPARC-IIIi and US-III+

Hi All,
I am trying to finalise a VxVM version for a Solaris 8 version. On the Solaris machine I see,
System Configuration: Sun Microsystems sun4u Sun Fire 280R (UltraSPARC-III+)
System clock frequency: 150 MHz
Memory size: 4096 Megabytes
========================= CPUs ===============================================
Run E$ CPU CPU
Brd CPU MHz MB Impl. Mask
A 0 1200 8.0 US-III+ 11.0
On the compatibility matrix I see only Ultra Sparc IIIi and no III+ . Are they both same or hugely diffrent?
Please help.
Regards,
Anand

Google
["SPARC IIIi versus SPARC III"|http://www.google.com/search?hl=en&q=SPARC+iiii+versus+sparc+iii&btnG=Google+Search&aq=f&oq=]
Find Ben Rockford's blog comparing Sun's cpu architectures.
[http://www.cuddletech.com/blog/pivot/entry.php?id=332|http://www.cuddletech.com/blog/pivot/entry.php?id=332]

'Cannot open mirrored root device' -- after dd and h/w swap

Hi All,
i needed to clone the server (netra440, sol10)so i took a sector copy (dd) of two mirrored hard disks
and tried to start from them on another netra440 server , i've got an error listed below,
is there any way to bring this mirror to life if given that original server is unavailable anymore?
thanks for any hint
Cannot open mirrored root device, error 19
Cannot remount root on /pseudo/md@0:0,35,blk fstype ufs
panic[cpu3]/thread=180e000: vfs_mountroot: cannot remount root
000000000180b950 genunix:vfs_mountroot+310 (8025, 1882fa0, 185d400, 18621c0, 1883000, 185d770)
%l0-3: 0000060001843a40 0000000000000003 0000000000000002 00000000011e6800
%l4-7: 00000000018362c0 000000000183b400 000000000185d400 0000000000000001
000000000180ba10 genunix:main+98 (18141a0, 1013800, 18362c0, 18ab800, 180e000, 1814000)
%l0-3: 0000000070002000 0000000000000001 000000000180c000 000000000180e000
%l4-7: 0000000000000001 0000000001074800 0000000000000060 0000000000000000
syncing file systems... done

System can be brought up in this way; however do you have any idea if the root disk has been encapsulated by VxVM before this panic during the reboot?
I`ve encapsulated the root & its mirror under veritas volume manager and rebooted the machine and landed upon
panic[cpu3]/thread=180e000: vfs_mountroot: cannot remount root
000000000180b950 genunix:vfs_mountroot+354 (2021, 21, 60002c5a080, 1878688, 183bc00, 1873148)
%l0-3: 0000000001872c00 0000000000000001 0000000000008025 0000000001206800
%l4-7: 000000000189c8d8 0000000001872f00 000000000189c8d8 000000000189c8d8
000000000180ba10 genunix:main+98 (1814380, 1015000, 18366a0, 18c3400, 70002000, 1814000)
%l0-3: 0000000070002000 0000000000000001 000000000180c000 000000000180e000
%l4-7: 0000000000000001 000000000180c000 0000000000000060 0000000000000000
I could manage to bring up the system but the disks cant be uninitialized now and i think it requires rebuild......

VxVM v3.5, unencapsulation and no rootdg

Similar Messages

Maybe you are looking for