{"id":2643,"date":"2013-11-12T08:50:08","date_gmt":"2013-11-12T00:50:08","guid":{"rendered":"http:\/\/rmohan.com\/?p=2643"},"modified":"2013-11-12T08:50:08","modified_gmt":"2013-11-12T00:50:08","slug":"veritas-cluster","status":"publish","type":"post","link":"https:\/\/mohan.sg\/?p=2643","title":{"rendered":"veritas cluster"},"content":{"rendered":"

Comands\t\tLVM\t\t\t\t VXVM
\n1\t\tFdisk,vxdctl\t\t Fdisk -l\t\t\t vxdctl enable
\n2\t\tpvcreate,vxdisksetup\t\tpvcreate \/dev\/sdb*\t\t\t vxdisksetup -I \/etc\/vx\/bin\/vxdisksetup -i disk_0 \/etc\/vx\/vxdisksetup -i disk_1
\n3\t\tvgcreate,vxdg\t\t vgcreate oravg \/dev\/sdb*\t\t\t vxdg init oradg disk_0 disk_1
\n4\t\tlvcreate,vxassist\t\tlvcreate -L +3G oravg ora_lv\t\t\tvxassist -g make vol vxassist -g oradg make oravol 4g disk_0 disk_1
\n5\t\tmkfs.ext3,mkfs.vxfs\t\tmkfs.ext3 \/dev\/oravg\/ora_lv\t\t\t mkfs.vxfs \/dev\/vx\/rdsk\/webdg\/webvol
\n6\t\tmount\t\t mount -t ext3 \/dev\/oravg\/ora_lv \/oravol\t mount -t vxfs \/dev\/vx\/dsk\/oradg\/oravol \/oravol\/<\/p>\n

lvm veritas<\/p>\n

fdisk vxdctl enable
\npvcreate vxdisksetup -i lun
\nvgcreate vxdg -g adddisk device=lun
\nlvcreate vxassit -g make vol size
\nmkfs mkfs -F vxfs
\nmount mount
\n\/etc\/fstab \/etc\/fstab<\/p>\n

Linux = native multipathing
\nsolaris = native multpathing
\nveritas = veritas dynamic multipathing<\/p>\n

Veritas cluster Server<\/p>\n

or the end of the week, we’re going to continue with the theme of sparse-but-hopefully useful information. Quick little “crib sheets” (preceding by paragraphs and paragraphs of stilted ramblings by the lunatic who pens this blog’s content \ud83d\ude09 For this Friday, we’re going to come back around and take a look at Veritas Cluster Server (VCS) troubleshooting. If you’re interested in more specific examples of problems, solutions and suggestions, with regards to VCS, check out all the VCS related posts from the past year or so. Hopefully you’ll be able to find something useful in our archives, as well. These simple suggestions should work equally well for Unix as well as Linux, if you choose to go the VCS route rather than some less costly one \ud83d\ude42<\/p>\n

And, here we go again; quick, pointed bullets of info. Bite-sized bits of troubleshooting advice that focus on solving the problem, rather than understanding it. That sounds awful, I know, but, sometimes, you have to get things done and, let’s face it, if it’s the job or your arse, who cares about the why? Leave that for philosophers and academics. Plus, since you fix problems so fast, you’ll have plenty of time to read up on the ramifications of your actions later \ud83d\ude09<\/p>\n

The setup: Your site is down. It’s a small cluster configuration with only two nodes and redundant nic’s, attached network disk, etc. All you know is that the problem is with VCS (although it’s probably indirectly due to a hardware issue). Something has gone wrong with VCS and it’s, obviously, not responding correctly to whatever terrible accident of nature has occurred. You don’t have much more to go on than that. The person you receive your briefing from thinks the entire clustered server set up (hardware, software, cabling, power, etc) is a bookmark in IE \ud83d\ude09<\/p>\n

Now, one by one, in a fashion that zigs on purpose, but has a tendency to zag, here are a few things to look at right off the bat when assessing a situation like this one. Perhaps next week, we’ll look into more advanced troubleshooting (and, of course, you can find lots of specific “weird VCS problem” solutions in our VCS archives)<\/p>\n

1. Check if the cluster is working at all. <\/p>\n

Log into one of the cluster nodes as root (or a user with equivalent privilege – who shouldn’t exist \ud83d\ude09 and run<\/p>\n

host1 # hastatus \u2013summary<\/p>\n

or<\/p>\n

host1 # hasum <-- both do the same thing, basically\n\n\nEx:\n\nhost1 # hastatus -summary\n\n-- SYSTEM STATE\n-- System State Frozen\n\nA host1 RUNNING 0\nA host2 RUNNING 0\n\n-- GROUP STATE\n-- Group System Probed AutoDisabled State\n\nB ClusterService host1 Y N OFFLINE\nB ClusterService host2 Y N ONLINE\nB SG_NIC host1 Y N ONLINE\nB SG_NIC host2 Y N OFFLINE\nB SG_ONE host1 Y N ONLINE\nB SG_ONE host2 Y N OFFLINE\nB SG_TWO host1 Y N OFFLINE\nB SG_TWO host2 Y N OFFLINE\n\n\nClearly, your situation is bad: A normal VCS status should indicate that all nodes in the cluster are \u201cRUNNING\u201d (which these are). However, it should also show all service groups as being ONLINE on at least one of the nodes, which isn't the case above with SG_TWO (Service Group 2).\n\n2. Check for cluster communication problems. Here we want to determine if a service group is failing because of any heartbeat failure (The VCS cluster, that is, not another administrator \ud83d\ude09\n\nCheck on GAB first, by running:\n\nhost1 # gabconfig -a\n\nEx:\n\nhost1 # gabconfig -a\nGAB Port Memberships\n===============================================================\nPort a gen 3a1501 membership 01\nPort h gen 3a1505 membership 01\n\n\nThis output is okay. You would know you had a problem at this point if any of the following conditions were true:\n\nif no port \u201ca\u201d memberships were present (0 and 1 above), this could indicate a problem with gab or llt (Looked at next)\n\nIf no port \"h\" memberships were present (0 and 1 above), this could indicate a problem with had.\n\nIf starting llt causes it to stop immediately, check your heartbeat cabling and llt setup.\n\nTry starting gab, if it's down, with:\n\nhost1 # \/etc\/init.d\/gab start\n\nIf you're running the command on a node that isn't operational, gab won't be seeded, which means you'll need to force it, like so:\n\nhost1 # \/sbin\/gabconfig -x\n\n3. Check on LLT, now, since there may be something wrong there (even though it wasn't indicated above)\n\nLLT will most obviously present as a crucial part of the problem if your \"hastatus -summary\" gives you a message that it \"can't connect to the server.\" This will prompt you to check all cluster communication mechanisms (some of which we've already covered).\n\nFirst, bang out a quick:\n\nhost1 # lltconfig\n\non the command line to see if llt is running at all.\n\nIf llt isn't running, be sure to check your console, system messages file (syslog, possibly messages and any logs in \/var\/log\/VRTSvcs\/... - usually the \"engine log\" is worth a quick look) As a rule, I usually do\n\nhost1 # ls -tr \n\nwhen I'm in the VCS log directory to see which log got written to last, and work backward from there. This puts the most recently updated file last in the listing. My assumption is that any pertinent errors got written to one of the fresher log files \ud83d\ude42 Look in these logs for any messages about bad llt configurations or files, such as \/etc\/llttab, \/etc\/llthost and \/etc\/VRTSvcs\/conf\/sysname. Also, make sure those three files contain valid entries that \"match\" <-- This is very important. If you refer to the same facility by 3 different names, even though they all point back to the same IP, VCS can become addled and drop-the-ball.\n\nExamples of invalid entries in LLT config files would include \"node numbers\" outside the range of 0 to 31 and \"cluster numbers\" outside the range of 0 to 255.\n\nNow, if LLT \"is\" running, check its status, like so:\n\nhost # lltstat -wn <-- This will let you know if llt on the separate nodes within the cluster can communicate with one another. \n\nOf course, verify physical connections, as well. Also, see our previous post on dlpiping for more low-level-connection VCS troubleshooting tips.\n\nEx:\n\nhost1 # lltstat -vvn\nLLT node information:\n Node State Link Status Address\n 0 prsbn012 OPEN\n ce0 DOWN\n ce1 DOWN\n HB172.1 UP 00:03:BA:9D:57:91\n HB172.2 UP 00:03:BA:0E:F1:DE\n HB173.1 UP 00:03:BA:9D:57:92\n HB173.2 UP 00:03:BA:0E:D0:BE\n 1 prsbn015 OPEN\n ce3 UP 00:03:BA:0E:CE:09\n ce5 UP 00:03:BA:0E:F4:6B\n HB172.1 UP 00:03:BA:9D:5C:69\n HB172.2 UP 00:03:BA:0E:CE:08\n HB173.1 UP 00:03:BA:0E:F4:6A\n HB173.2 UP 00:03:BA:9D:5C:6A\n\n\nhost1 # cat \/etc\/llttab <-- pardon the lack of low-pri links. We had to build this cluster on the cheap \ud83d\ude09\n\nset-node \/etc\/VRTSvcs\/conf\/sysname\nset-cluster 100\nlink ce0 \/dev\/ce:0 - ether 0x1051 -\nlink ce1 \/dev\/ce:1 - ether 0x1052 -\nexclude 7-31\nhost1 # cat \/etc\/llthosts\n0 host1\n1 host2\nhost1 # cat \/etc\/VRTSvcs\/conf\/sysname\nhost1\n\nIf llt is down, or you think it might be the problem, either start it or restart it with:\n\nhost1 # \/etc\/init.d\/llt.rc start\n\nor\n\nhost1 # \/etc\/init.d\/llt.rc stop\nhost1 # \/etc\/init.d\/llt.rc start\n\nAnd, that's where we'll end it today. There's still a lot more to cover (we haven't even given the logs more than their minimum due), but that's for next week.\n\nUntil then, have a pleasant and relaxing weekend \ud83d\ude42\n\n\n\nVeritas Cluster Server (VCS) Command line\n\n\nVCS has can be divided into two important parts\n\nCluster Communication:\nLow Latency Transport (LLT) and Global Atomic Broadcast (GAB) are responsible for heartbeat and cluster communication.\n\nLLT status\nlltconfig -a list \u2013 List all the MAC addresses in cluster\nlltstat -l \u2013 Lists information about each configured LLT link\nlltstat [-nvv|-n] \u2013 Verify status of links in cluster\n\nStarting and stopping LLT\nlltconfig -c \u2013 Start the LLT service\nlltconfig -U \u2013 stop the LLT running\n\nGAB status\ngabconfig -a \u2013 List Membership, Verify id GAB is operating\ngabdiskhb -l \u2013 Check the disk heartbeat status\ngabdiskx -l \u2013 lists all the exclusive GAB disks and their membership information\n\nStarting and stopping GAB\ngabconfig -c -n seed_number \u2013 Start the GAB\ngabconfig -U \u2013 Stop the GAB\n\nHAD:\nStands for High Availability daemon. HAD is responsible for all the cluster functionality.\nThe commands for Veritas start with \u201cha\u201d meaning high availability. For example, \u2018hastart\u2019, \u2018hastop\u2019, \u2018hares\u2019 etc. Listed below are commands sorted by category which are used for most day to day operation\/management of VCS.\n\nCluster Status\nhastatus -summary \u2013 Outputs the status of cluster\nhasys -display \u2013 Displays the cluster operation status\n\nStart or Stop services\nhastart [-force|-stale] \u2013 \u2018force\u2019 is used to load local configuration\nhasys -force 'system' \u2013 start the cluster using config file from the mentioned \u201csystem\u201d\nhastop -local [-force|-evacuate] \u2013 \u2018local\u2019 option will stop the service only on the system you type the command\nhastop -sys 'system' [-force|-evacuate] \u2013 \u2018sys\u2019 stops had on the system you specify\nhastop -all [-force] \u2013 \u2018all\u2019 stops had on all systems in the cluster\n\nChange VCS Configuration online\nhaconf -makerw \u2013 makes VCS configuration in read\/write mode\nhaconf -dump -makero \u2013 Dumps the configuration changes\n\nAgent Operations\nhaagent -start agent_name -sys system \u2013 Starts an agent\nhaagent -stop agent_name -sys system \u2013 Stops an agent\n\nCluster Operations\nhaclus -display \u2013 Displays cluster information and status\nhaclus -enable LinkMonitoring \u2013 Enables heartbeat link monitoring in the GUI\nhaclus -disable LinkMonitoring \u2013 Disables heartbeat link monitoring in the GUI\n\nAdd and Delete Users\nhauser -add user_name \u2013 Adds a user with read\/write access\nhauser -add VCSGuest \u2013 Adds a user with read-only access\nhauser -modify user_name \u2013 Modifies a users password\nhauser -delete user_name \u2013 Deletes a user\nhauser -display [user_name] \u2013 Displays all users if username is not specified\n\nSystem Operations\nhasys -list \u2013 List systems in the cluster\nhasys -display \u2013 Get detailed information about each system\nhasys -add system \u2013 Add a system to cluster\nhasys -delete system \u2013 Delete a system from cluster\n\nResource Types\n\nhatype -list \u2013 List resource types\nhatype -display [type_name] \u2013 Get detailed information about a resource type\nhatype -resources type_name \u2013 List all resources of a particular type\nhatype -add resource_type \u2013 Add a resource type\nhatype -modify .... \u2013 Set the value of static attributes\nhatype -delete resource_type \u2013 Delete a resource type\n\nResource Operations\n\nhares -list \u2013 List all resources\nhares -dep [resource] \u2013 List a resource\u2019s dependencies\nhares -display [resource] \u2013 Get detailed information about a resource\nhares -add resource_type service_group \u2013 Add a resource\nhares -modify resource attribute_name value \u2013 Modify the attributes of the new resource\nhares -delete resource \u2013 Delete a resource type\nhares -online resource -sys systemname \u2013 Online a resource, type\nhares -offline resource -sys systemname \u2013 Offline a resource, type\nhares -probe resource -sys system \u2013 Cause a resource\u2019s agent to immediately monitor the resource on a particular system\nhares -clear resource [-sys system] \u2013 Clear a faulted resource\nhares -local resource attribute_name value \u2013 Make a resource\u2019s attribute value local\nhares -global resource attribute_name value \u2013 Make a resource\u2019s attribute value global\nhares -link parent_res child_res \u2013 Specify a dependency between two resources\nhares -unlink parent_res child_res \u2013 Remove the dependency relationship between two resources\n\nService Group Operations\n\nhagrp -list \u2013 List all service groups\nhagrp -resources [service_group] \u2013 List a service group\u2019s resources\nhagrp -dep [service_group] \u2013 List a service group\u2019s dependencies\nhagrp -display [service_group] \u2013 Get detailed information about a service group\nhagrp -online groupname -sys systemname \u2013 Start a service group and bring it resources\nhagrp -offline groupname -sys systemname \u2013 Stop a service group and take it resources offline\nhagrp -switch groupname -to systemname \u2013 Switch a service group from one system to another\nhagrp -freeze -sys -persistent \u2013 Gets into Maintenance Mode. Freeze a service group. This will disable online and offline operations\nhagrp -unfreeze -sys -persistent] \u2013 Take the servicegroup out of maintenance mode\nhagrp -enable service_group [-sys system] \u2013 Enable a service group\nhagrp -disable service_group [-sys system] \u2013 Disable a service group\nhagrp -enableresources service_group \u2013 Enable all the resources in a service group\nhagrp -disableresources service_group \u2013 Disable all the resources in a service group\nhagrp -link parent_group child_group relationship \u2013 Specify the dependency relationship between two service groups\nhagrp -unlink parent_group child_group \u2013 Remove the dependency between two service groups\n\n\n\n\n\n VCS Startup Process\n\nPlease verify that the Cables are setup for heartbeat network. You can tcpdump from one server NIC\u2019s MAC Address to another to verify the connectivity\nStep 1:\nLLT (Low latency Transport) should be startup first using the \u201clltstat -c\u201d command. It reads \/etc\/llttab and \/etc\/llthosts files and establishes heartbeat network. Heartbeat network is a private network where VCS status information is exchanged by all systems within a VCS cluster. These networks require each system in the cluster to have a dedicated NIC, connected to a private hub. VCS requires a minimum of two dedicated communication channels between each system in a cluster. LLT is a low overhead networking protocol that runs in the kernel. Because it runs in the kernel, it is capable of handling kernel to kernel communications.\n\nExamples of files are as below:\n\n #cat \/etc\/llthosts\n 0
\n 1
\n .
\n .
\n n
\nIn the Example below, the linux systems will have interface names such as \u201ceth0\/1?. If using any device, then replace \u201cce\u201d with \u201cqfe0\/1? etc..
\n#cat \/etc\/llttab
\n set-node
\n set-cluster
\n link ce2 \/dev\/ce:0 – ether – –
\n link ce3 \/dev\/ce:3 – ether – –
\n link-lowpri ce4 \/dev\/ce:4 – ether – –
\n start
\nVerification for startup can be done using lltstat -n command. \u201c*\u201d represents firstnode (master) in the cluster<\/p>\n

#lltstat -n
\n Node State Links
\n * 0 OPEN 3
\n 1 OPEN 3
\n 2 OPEN 3
\n .
\n .
\n n OPEN 3
\nStep 2:
\nGAB (Group Atomic Board) starts next. It executes \/etc\/gabtab and checks for other GABs to establish a cluster membership. GAB runs over Low Latency Transport (LLT) and uses broadcasts to distribute cluster configuration information and ensure that each system has a synchronized view of the cluster, including the state of each system, service group, and resource.<\/p>\n

# cat \/etc\/gabtab
\n \/sbin\/gabconfig -c -n5 # for a 5 node cluster
\nGAB can be started using \u201cgabconfig -c\u201d and verified by using \u201cgabconfig -a\u201d. Below is the example output for a 5 node cluster. Port \u2018a\u2019 runs GAB service and port \u2018h\u2019 runs VCS Deamon<\/p>\n

# gabconfig -a
\n GAB Port Memberships
\n =========================================
\n Port a gen 11ff05 membership 012345
\n Port h gen 11ff09 membership 012345
\nStep 3:<\/p>\n

After both LLT and GAB are loaded, hashadow starts which will load HAD (High Availability Deamon). HAD reads \/etc\/VRTSvcs\/conf\/config\/main.cf, types.cf and all include.cf\u2019s mentioned in main.cf file.<\/p>\n

HAD checks if there are other HADs avaible and registers them with GAB. If there are no other HADs, it loads the main.cf again into HAD memory.Same process will happen when HAD starts on<\/p>\n

other nodes. The HAD on the first node will load the main.cf and other include.cf files from the local system and all other HADs will load configuration from the first HAD.
\nAfter starting up, HAD will know all the service groups and resources from main.cf. It will call the respective agents to check if the resources are currently online or offline. Based on<\/p>\n

main.cf, HAD will online\/offline the Service group on the respective nodes.<\/p>\n

Cluster is started up with \u201chastart\u201d command. The status can be verified using \u201chastatus -sum\u201d<\/p>\n

VCS Logfile: \/var\/\/log\/engine_A.log<\/p>\n

Setup SAN disk for use in a Linux Veritas cluster<\/p>\n

For this particular exercise we\u2019re going to go through the entire process of provisioning disk for use in a VCS cluster.<\/p>\n

We will use EMC Symmetrix disk zoned and masked to a RHEL 4u6 host as the foundation.<\/p>\n

Get the disk(s) presented to the host observing that it\u2019s visible down multiple paths.<\/p>\n

# inq -showvol
\nInquiry utility, Version V7.3-771 (Rev 0.0) (SIL Version V6.3.0.0 (Edit Level 771)
\nCopyright (C) by EMC Corporation, all rights reserved.
\nFor help type inq -h.<\/p>\n

—————————————————————————–
\nDEVICE :VEND :PROD :REV :SER NUM :Volume :CAP(kb)
\n—————————————————————————–
\n\/dev\/sda :EMC :SYMMETRIX :5771 :0123456789 : 00617: 2880
\n\/dev\/sdb :EMC :SYMMETRIX :5771 :0123456789 : 00204: 35654400
\n\/dev\/sdc :EMC :SYMMETRIX :5771 :0123456789 : 00206: 35654400
\n\/dev\/sdd :EMC :SYMMETRIX :5771 :0123456789 : 00208: 35654400
\n\/dev\/sde :EMC :SYMMETRIX :5771 :0123456789 : 0020A: 35654400
\n\/dev\/sdf :EMC :SYMMETRIX :5771 :0123456789 : 0020C: 35654400
\n\/dev\/sdg :EMC :SYMMETRIX :5771 :0123456789 : 0020E: 35654400
\n\/dev\/sdh :EMC :SYMMETRIX :5771 :0123456789 : 00210: 35654400
\n\/dev\/sdi :EMC :SYMMETRIX :5771 :0123456789 : 00212: 35654400
\n\/dev\/sdj :EMC :SYMMETRIX :5771 :0123456789 : 00214: 35654400
\n\/dev\/sdk :EMC :SYMMETRIX :5771 :0123456789 : 00263: 35654400
\n\/dev\/sdl :EMC :SYMMETRIX :5771 :0123456789 : 00265: 35654400
\n\/dev\/sdm :EMC :SYMMETRIX :5771 :0123456789 : 00267: 35654400
\n\/dev\/sdn :EMC :SYMMETRIX :5771 :0123456789 : 00269: 35654400
\n\/dev\/sdo :EMC :SYMMETRIX :5771 :0123456789 : 0026B: 35654400
\n\/dev\/sdp :EMC :SYMMETRIX :5771 :0123456789 : 00617: 2880
\n\/dev\/sdq :EMC :SYMMETRIX :5771 :0123456789 : 00204: 35654400
\n\/dev\/sdr :EMC :SYMMETRIX :5771 :0123456789 : 00206: 35654400
\n\/dev\/sds :EMC :SYMMETRIX :5771 :0123456789 : 00208: 35654400
\n\/dev\/sdt :EMC :SYMMETRIX :5771 :0123456789 : 0020A: 35654400
\n\/dev\/sdu :EMC :SYMMETRIX :5771 :0123456789 : 0020C: 35654400
\n\/dev\/sdv :EMC :SYMMETRIX :5771 :0123456789 : 0020E: 35654400
\n\/dev\/sdw :EMC :SYMMETRIX :5771 :0123456789 : 00210: 35654400
\n\/dev\/sdx :EMC :SYMMETRIX :5771 :0123456789 : 00212: 35654400
\n\/dev\/sdy :EMC :SYMMETRIX :5771 :0123456789 : 00214: 35654400
\n\/dev\/sdz :EMC :SYMMETRIX :5771 :0123456789 : 00263: 35654400
\n\/dev\/sdaa :EMC :SYMMETRIX :5771 :0123456789 : 00265: 35654400
\n\/dev\/sdab :EMC :SYMMETRIX :5771 :0123456789 : 00267: 35654400
\n\/dev\/sdac :EMC :SYMMETRIX :5771 :0123456789 : 00269: 35654400
\n\/dev\/sdad :EMC :SYMMETRIX :5771 :0123456789 : 0026B: 35654400<\/p>\n

See what disks Veritas can see.
\nvxdisk -o alldgs list<\/p>\n

Initialize the disk for the first time. This needs to be repeated for each individual disk.
\n\/etc\/vx\/bin\/vxdisksetup -i DEVICE format=cdsdisk<\/p>\n

See if the intialize worked correctly. <\/p>\n

# vxdisk -o alldgs list
\nDEVICE TYPE DISK GROUP STATUS
\nEMC0_0 auto:cdsdisk – (dg_grp) online
\nEMC0_1 auto:cdsdisk – (dg_grp) online
\nEMC0_2 auto:cdsdisk – (dg_grp) online
\nEMC0_3 auto:cdsdisk – (dg_grp) online
\nEMC0_4 auto:cdsdisk – (dg_grp) online
\nEMC0_5 auto:cdsdisk – (dg_grp) online
\nEMC0_6 auto:cdsdisk – (dg_grp) online
\nEMC0_7 auto:cdsdisk – (dg_grp) online
\nEMC0_8 auto:cdsdisk – (dg_grp) online
\nEMC0_9 auto:cdsdisk – (dg_grp) online
\nEMC0_10 auto:cdsdisk – (dg_grp) online
\nEMC0_11 auto:cdsdisk – (dg_grp) online<\/p>\n

EMC0_12 auto:cdsdisk – (dg_grp) online
\nEMC0_13 auto:cdsdisk – (dg_grp) online
\ncciss\/c0d0 auto:none – – online invalid<\/p>\n

All device(s) (e.g. EMC0_n) now show as online.<\/p>\n

Create the disk group.
\nvxdg init dg_name dg_internal_name01=DEVICE
\nThe dg_name is the name of your disk group while dg_internal_name01 is the name of the first disk. In our case dg_internal_name01=EMC0_0.<\/p>\n

Add any additional disk to the disk group.
\nvxdg -g dg_name adddisk dg_internal_name02=EMC0_n+1<\/p>\n

Note that EMC0_n+1 is the next free disk that you are attempting to add. So dg_internal_name02=EMC0_1 (remember we started with EMC0_0).
\nTo create the volume
\nvxassist -g dg_name make lv_name [size] dg_internal_nameN<\/p>\n

Repeat as necessary.
\nFinally, create the file system
\nmkfs -t vxfs \/dev\/vx\/rdsk\/dg_name\/lv_name
\nAt this point the volumes are now available to be defined as a mount resource in VCS.<\/p>\n","protected":false},"excerpt":{"rendered":"

Comands LVM VXVM 1 Fdisk,vxdctl Fdisk -l vxdctl enable 2 pvcreate,vxdisksetup pvcreate \/dev\/sdb* vxdisksetup -I \/etc\/vx\/bin\/vxdisksetup -i disk_0 \/etc\/vx\/vxdisksetup -i disk_1 3 vgcreate,vxdg vgcreate oravg \/dev\/sdb* vxdg init oradg disk_0 disk_1 4 lvcreate,vxassist lvcreate -L +3G oravg ora_lv vxassist -g make vol vxassist -g oradg make oravol 4g disk_0 disk_1 5 mkfs.ext3,mkfs.vxfs mkfs.ext3 \/dev\/oravg\/ora_lv mkfs.vxfs […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[38],"tags":[],"_links":{"self":[{"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/posts\/2643"}],"collection":[{"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/mohan.sg\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=2643"}],"version-history":[{"count":2,"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/posts\/2643\/revisions"}],"predecessor-version":[{"id":2645,"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/posts\/2643\/revisions\/2645"}],"wp:attachment":[{"href":"https:\/\/mohan.sg\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=2643"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mohan.sg\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=2643"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mohan.sg\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=2643"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}