veritas vxvm storage (sun)

8/14/2019 Veritas VxVM Storage (SUN)

1/15

Sun Mi crosystems , Inc.901 San A ntonio Road

Palo Alto, CA 94303 USA650 960-1300 fax 650 969-9131

Veritas VxVM StorageManagement Softw are

By Gene Trantham - EnterpriseEngineering

Sun BluePrints OnLine - May 2000

http://www.sun.com/blueprints

Part No .: 806-5596-10Revision 01, May 2000


2/15

PleaseRecycle

Copyright 2000 Sun Microsystems, Inc. 901San Antonio Road, Palo Alto, California 94303 U.S.A. All rights reserved.

This prod uct or docum ent is protected by copyrigh t and distributed und er licenses restricting its use, copying, distribution, and d ecompilation.No part of this produ ct or documen t may be reprod uced in any form by any means without pr ior written authorization of Sun and its licensors,if any.Third -party software, including font technology,is copyrigh ted and licensed from Sun sup pliers.

Parts of the prod uct may be derived from Berkeley BSD systems, licensed from the University of California. UNIXis a registered tradem ark inthe U.S. and other countries, exclusively licensed through X/ Open Comp any,Ltd .

Sun, Sun Microsystems, the Sun logo, The Network Is The Computer, Solstice DiskSuite, Jum pstart, Sun BluePrints and Solaris are tradem arks,registered trademark s, or service marks ofSun Microsystems, Inc. in the U.S. and oth er coun tries. All SPARC tradem arks are used und er licenseand are tradem arks or registered tradem arks of SPARC International, Inc.in the U.S. and other countr ies.P rodu cts bearing SPARC tradem arksare based upon an architecture developed by Sun Microsystems, Inc.

The OPEN LOOK and Sun Graph ical User Interface was developed by Sun Microsystems,Inc. for its users and licensees.Sun acknow ledgesthe pioneering efforts ofXerox in researching and d eveloping the concept of visual or graphical user interfaces for the compu ter industry. Sunhold s a non -exclusive license from Xerox to the Xerox Graph ical User Interface, wh ich license also covers Sun s licensees who imp lemen t OPENLOOK GUIs and oth erwise comply with Suns written license agreements.

RESTRICTED RIGHTS : Use, du plication, or disclosu re by the U.S. Govern men t is subject to restrictions of FAR 52.227-14(g)(2)(6/ 87)a ndFAR 52.227-19(6/ 87), or D FAR 252.227-7015(b)(6/ 95) an d D FAR 227.7202-3(a).

DOCUMENTATION IS PROVIDED AS IS AND ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES,INCLUD ING AN Y IMPLIED WARRANTY OF MERCHAN TABILITY, FITNESS FOR A PARTICULAR PURPO SE OR NON -INFRINGEMENT, ARE DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD TO BE LEGALLY INVALID.

Copyright 2000 Sun Microsystems, Inc.,901 San Antonio Road, Palo Alto, Californie 94303Etats-Unis. Tous droits rservs.

Ce produit ou docum ent est protg par un copyrigh t et distribu avec des licences qui en restreignent lutilisation, la copie, la distribution, et ladcomp ilation.Au cune partie de ce produit ou documen t ne peu t tre reprod uite sous aucun e forme, par quelqu e moyen que ce soit, sanslautorisation p ralable et crite de Sun et de ses bailleurs de licence, sil y en a. Le logicield tenu p ar des tiers, et qui compren d la technologierelative aux polices de caractres,est p rotg par u n copyright et licenci par d es fournisseurs de Sun .

Des parties de ce produ it pourron t tre drives des systmes Berkeley BSD licencis par lUniversit de Californie.UN IXest une m arquedp ose aux Etats-Unis et dans dautres pays et licencie exclusivemen t par X/ Open Comp any,Ltd .

Sun, Sun Microsystems, le logo Sun , The Network Is The Computer, Solstice DiskSuite, Jum pstart, Sun BluePrints, et Solaris sont des marquesde fabrique ou des marques dposes, ou marqu es de service,d e Sun Microsystems, Inc.a ux Etats-Unis et dan s dautres pays. Toutes lesmarqu es SPARC sont utilises sous licence et sont des marq ues de fabriqu e ou des m arques d poses de SPARC Internation al, Inc.a ux Etats-Unis et dans dautres pays. Les produ its portant les marques SPARC sont bass sur un e architecture dvelop pe par Sun Microsystems, Inc.

Linterface dutilisation graphiqu e OPEN LOOKet Sun a t dveloppe pa r Sun Microsystems, Inc.p our ses utilisateurs et licencis. Sunreconnat les efforts de pionn iers de Xerox pour la recherche et le dveloppem ent du concept des interfaces dutilisation visuelle ou grap hiquepou r lindu strie de linformatiqu e. Sun dtient u ne licence non exclusive d e Xerox sur linterface dutilisation grap hique Xerox,cette licencecouvran t galement les licencis de Sun qu i mettent en place linterface dutilisation grap hique OPEN LOOK et qui en outre se conforment auxlicences crites de Sun.

CETTE PUBLICATION EST FOURN IE "EN LETAT" ET AUCUN E GARANTIE, EXPRESSE OU IMPLICITE, NEST ACCO RDEE, YCOMP RISDES GARANTIES CONC ERNANT LA VALEUR MARCHANDE, LAPTITUDE DE LA PUBLICATION A REPON DRE A UNE UTILISATIONPARTICULIERE, OU LE FAIT QUELLE NE SOIT PAS CONTREFAISANTE DE P RODUIT DE TIERS. CE DENI DE GARAN TIE NESAPPLIQUERAIT PAS, DANS LA MESURE OU IL SERAIT TENU JURIDIQUEMENT NUL ET NON AVENU.


3/15

1

Veritas VxVM Storage Managem entSoftware

AbstractMost mission critical systems can benefit from storage man agemen t software wh ichcan mirror, and thereby protect their data against hard ware failure. A comm onstorage man agement tool used on Sun systems is produ ced by Veritas SoftwareCorporation an d is sold un der th e nam es VxVM and SEVM.

VxVM has a repu tation amon g some system adm inistrators for its complexity inmanaging storage, and boot devices. The boot disk, and operating system data isperhap s the most critical data that is required to be kept a vailable on a h ost system.This data is often neglected or imp roperly protected becau se of the perceived

difficulty involved in the adm inistration process.This paper explains the u nd erlying actions of VxVM du ring boot disk encapsu lation,and details the mechanism by wh ich it seizes and m anages a boot device. A num berof best practices will be presented to assist system ad ministrators stand ardizeinstallations. The direction this paper is focused on availability, serviceability, andadministration of data on a boot disk.

IntroductionMost system managers agree that backing up the server data, and even going to thelengths of p roviding off-site media storage, is a necessary requirement. Wh ile this

may preserve the d ata, it does not p reserve the availability of the data. A failed d isk can be easily replaced an d reloaded with the original data from a back up, how ever,wh at about lost processing time d uring rep air and d ata recovery? Also, there is theissue of staleness of the backup and what changes have been made to the datasetbetween the time of the last backup and the time of the hardw are failure.


4/15

2 Veritas VxVM Storage Management Software May 2000

These issues, among others, led to the d evelopment of online d ata p rotectionsoftware u sing various forms of RAID. One of the m ost pop ular an d effective means

of preventing an outage du e to d isk failure is mirroring (RAID_1). However, allmirrors are not created equ al. Just p roviding tw o copies of the d ata is not alwaysenough. In fact, its almost never enough. An understanding of the hardwarecompon ents necessary to access the und erlying d isk drive for each copy of the datais required, and also, an u nd erstanding of the possible interaction between th evarious components.

Two of the m ost pop ular d isk manag ement system s available for the SolarisOperating Environment are: Solstice DiskSuite software (SDS), and VolumeMan ager (VxVM).

VxVM, is frequently u sed on h igh end systems, but has the rep utation of beingdifficult to configure wh en d ealing with boot devices.

Difficulties can arise du ring recovery operations, repairs, or even u pgrad ing to anewer version of VxVM. How ever, this needn t be so. The key to a virtually pain-free and smoothly op erating VxVM system, especially with th e boot d evice, is toadh ere to some gu iding principles that need to be effected at th e time of install.These principles can be derived from an understanding of the underlying workingsof VxVM, especially in th e wa y it man ages a boot disk.

Disk Management OverviewStorage man agement software achieves transparent m irroring of data w ith the use of virtual devices. This is basically an extra layer of abstraction between the disk mediaand the p rocesses above it which need to access and use the d evices. These dev icesare:

App lication vi

FileSy stem u fs d ev ice d r iv er

Virtual Device vxio device driver

D isk Dev ice sd o r s sd device d r iver

In the case of VxVM, the virtual device is called a volume, w ith its device d river isvxio. Volumes are p resented to th e operating system for use as if they w ere disks.These virtual disks are then available for the su pp ort of file systems, swap devices,and raw datafiles.

I/ O directed toward the volum e is captu red by th e vxio device driver, wh ich thenre-issues them to the u nd erlying disk d evices according to the RAID policy for thevolume b eing accessed. A mirrored volum e, for examp le, might take all writerequests, then re-issue multiple writes to the various d isks which supp ort each paneof the mirror (usually only two p anes, but m ore may exist).


5/15

Veritas VxVM Storage Management Software 3

As VxVM is interposed betw een the d evices and the up per layers, it has a measu reof control over those d isks. How ever, its authority over the d isks is not absolute.

Disks are still accessible via th eir norma l device drivers u sing the conventionallogical path nam e:

For examp le, a volume su pp orted by a d isk at address c0t0d0 does not preclude theuse of th at d isk from other processes. Any other p rocess with su fficient file systemperm issions may access this d isk directly.

All volume managers maintain their own internal database of how the virtualdevices should hand le I/ Os. The configuration d atabase keeps track of wh ichvolumes are mirrors, which are RAID-5, what stripe interleave to u se, and similar

details. This metadata must be stored completely independent from the virtualdevices themselves. Both SDS and VxVM store their metad ata in a separate p rivateregion of each m anaged disk. The format in w hich this d ata is stored is specific toeach tool.

The sanctity of the VxVM private regions should not be violated u nd er anycircumstances. The volume m anager can become confused if the p rivate region of any of its disks undergoes unexpected changes.

At startup , the volume m anager w ill read the configura tion information contained inthe private regions of any discovered disks. That d ata is assembled into theconfiguration d atabase file located inside th e vxio dev ice d river. At this p oint, thevolumes are activated an d mad e available to the system for I/ Os. If theconfiguration por tion of this process cannot be comp leted, due to a corrupted

private region, for example, one or m ore volumes may be inaccessible.

Data Protection For A ll Volum esA dataset can be protected from certain kind s of hardw are errors by storing the d ataon a mirrored volu me. How ever, the p rotection is not absolute. A basic definition of mirroring states that there need s to be two or more iden tical copies of the d ata.How ever, there is no requ irement that the tw o copies exist on separate d isk devices.A volume in w hich both copies of the da taset are on the same ph ysical spindle is anexample w hich illustrates that mirrored does not always m ean p rotected.

When configuring m irrored volumes w ith any storage m anager, care must be taken

to ensure comp lete device indep end ence for copies of the d ata. Device ind epend encerefers to the ind ividual d isk devices, but it can a lso extend to the series of devicesnecessary to supp ort the entire data p ath to the d isk. For examp le, if the two d isks

/dev/dsk/c0t0d0s2


6/15


sup porting a m irror are on the same SCSI bus, the mirror is not d evice indep end ent,even though the data is on independent disks. The failure of the common path

element (the bu s itself) will prevent either side of the mirror from being available.

In add ition to the bus transport components w hich m ight include the h ost adaptercard, SCSI cables and connectors, terminators an d the like, the bus also includes anu mber of unrelated d evices which could seriously impact the ability of the bus tocarry data.

Sup pose an un related SCSI device (say, a tap e d rive) on the sam e SCSI bus suffereda hard ware error w hich held the bu s in reset. This wou ld effectively fail the d evicepath to both the mirror disks even though there are no failures in the pathingelements leading to them, or in the disks them selves.

The solution to this problem is not to mov e the tap e drive. A pra ctical solutionwou ld be to move the d isk holding a copy of the mirrored d ataset to a separate SCSI

bus. In this arrangem ent, if either bus experienced a p roblem, the other copy of themirrored d ata wou ld be un affected. This approach could be taken for any accesselement for each copy of the d ata.

Solaris Operating Environm ent provid es a mechanism to d etermine the device pathcompon ents of a d isk (or, for any d evice). The /devices directory tree is a w ay todetermine hardware elements leading to a disk:

The convenience handle of /dev/dsk/c0t0d0s2 (often called the logical devicepath ) is a symbolic link to the p hysical device path found in /devices . Thisph ysical path show s each of the device drivers used to access that d evice. Eachsubd irectory in the path nam e represents a discrete hard ware element. The devicedriver and address is indicated in the form:

This method of representing the hard ware p ath as a d irectory tree is convenient fordeterm ining if two d evices share a comm on p athing element in th e device tree. Inthis arrangement, two devices share a common hardware element if they have acommon parent in the /devices directory tree. The shared parent directoryrepresents the shared element.

# cd /dev/dsk# ls -l c0t0d0s2lrwxrwxrwx 1 rootroot 45 Feb 2 17:12 c0t0d0s2-> /devices/sbus@54,0/SUNW,socal@0,0/sf@0,0/

ssd@w21000020471cb01a,0:a

driver@address


7/15


8/15


Disk A Disk B

SCSIHost Adapter

SCSIHost Adapter

Disk A

SCSIHost Adapter

Disk B

Shared SCSI Bus

Split SCSI Bus

Conguration A

Conguration B

Figure 1 - Shared SCSI Bus vs Split SCSI Bus


9/15


Consider th e relatively simp le mirror illustrated in Figure 2 - Sample StripedMirror

Each element of a stripe (RAID_0) is critical to the integrity of the address spacemap ped by the stripe. If any on e of these disks should fail, the entire stripe isconsidered u nreliable. Therefore, any p ossible failure th at w ould adv ersely affectany one of the disks in STRIPE_A does not affect any of the disks in STRIPE_B.

This device path comparison has illustrated that simple mirrors must be expandedto account for all possible pa irings of d isks between stripes. In the sam pleconfiguration, there are 9 such pairings. Any hardware dependency between thesewill cause th e entire volume to depend on the comm on elements foun d between thosetwo d isks.

As the stripes become wid er, the num ber of combinations to be tested grow s rapid ly.In general, C n combinations are possible (wh ere C represents colum ns in each stripe,and n represents the n um ber of panes in a mirror). For examp le, a mirror consistingof two 5 colum n stripes, contains 25 potential pairings of disk d evices wh ich m ust bedevice indepen den t. Testing all these combinations is a time consuming task.Fortunately, much of the an alysis can be au tomated .

Volume

c1t0d0

c1t1d0

c1t2d0

STRIPE A

c2t0d0

c2t1d0

c2t2d0

Figure 2 - Sample Striped Mirror(2 x 3 column stripes)

STRIPE B


10/15


Boot Disk Mirrored boot volumes have the potential to be easier or harder to work with thangeneral volumes. The boot volum e (referred to a s rootvol ) must not be a stripe orRAID_5 device. It should be comp osed o f simp le, one-d isk copies. This simp lifies thechecks necessary to determine device independence. However, boot devices haveother special requirements, du e to the way the operating system d eals with this keydevice.

Private Regions: The Key To It AllWhen VxVM assumes ow nership of a device, the process is termed initialization.This process involves fencing off a private region on the d isk, thereby red ucing the

space available for data. Private regions typ ically occup y th e first cylind er of thedisk, howev er, this is not a requ irement. The remaining cylind ers are then availablein the public region of the disk for the creation of volumes.

Initialization is generally not an issue on most disks under management.Encapsulation, on the oth er han d, can be difficult. The process of encapsu lating adisk is to preserve data already p resent, while creating one or m ore cylinders for theprivate region.

The boot dev ice can p resent special problems to VxVM if it attemp ts encapsu lation.This is because VxVM is not accustomed to dealing w ith encapsu lation w hen seizingman agement control. For examp le:

If Block 0 is already in use (the boot block and root file system typically begin in

cylinder 0), the private regions cannot install there w ithout m oving the root filesystem.

If data is already on the d evice (which in some cases can consume th e entire disk space).

VxVM has some standard workarounds which will handle the majority of circumstances arising from the tw o examp le conditions. After a boot d isk isencapsulated , remnants of this action may be seen in the rootdisk-Priv an drootdisk-B0 subdisks.

These two subd isks are created in ord er to preserve tw o key regions of the disk frombeing overwritten by volume data.

The two k ey regions are the VTOC (reserved by rootdisk-B0 ), and the privateregion (reserved by rootdisk-Priv ). If a system ad ministrator moved or deletedthese two subdisks, their designed protection would be negated.


11/15


Formalized m anagem ent of the private regions is the key to avoiding trou ble withthe boot device. A best pr actice is outlined below, and is aimed specifically toward

locating the private region on the boot disk in a way that can prevent a m ultitude of problems which can ensue when dealing with an encapsulated boot device.

VxVM Best Practice For Boot Media1. Eliminate a separate /usr volume

There is little need for /usr file system to be separate from the root file system inmost environments. Having the /usr file system on a volu me sep arate fromrootvol can complicate service procedu res if the p rimary boot d isk needs to bereplaced. It wou ld be better to avoid these issues from the ou tset. All the sup portutilities for VxVM are located in the /usr/vxvm directory. If the system is in thesituation where it needs to p erform a VxVM operation, yet cannot mou nt a /usrslice or volum e, corrective action cann ot be taken a s a technician will not hav e accessto the tools required. (They are in the inaccessible /usr directory)

2. Mirror to a clone d isk

The goal of this practice is to duplicate exactly the boot disk to an identical disk. Forthis to work correctly, the med ia mu st be of the sam e size, performan cecharacteristics, and internal geometry as th e original boot d evice. Ideally, the bootdisk and its mirror wou ld be from the same vend or, be the same mod el number, andbe run ning id entical versions of firmw are on the internal controller.

Each volume on the boot disk should be supported by identical copies of the datalocated in identical places on the tw o d isks (the offset add ress for the start of

rootvol mu st be the same on all disks). This will help ensure service and su pp ortun der emergency repair cond itions can be carried out quickly and efficiently.

3. Attach mirrors in geograp hical order, not alph abetical order.

A common way that administrators mirror a boot device is with the vxdiskadmtool. A function w ithin this tool, named "Mirror all volum es on a disk", is aconvenient way to d o this. How ever, the vxdiskadm function generates a list of thevolumes to be m irrored in alphabetical order. Althou gh th is achieves the basic goalof mirroring the d ata, the mirror does not p lace the da ta in the optimu m locations.

In a typical boot disk encapsu lation, the system volu mes are: rootvol , swapvol ,var , and opt (and are gen erally written in this order on the d isk). The vxdiskadmfunction will not mirror these four volumes in the same ord er in which they app ear

on th e boot d isk. First it will attach the volum e opt , followed by swapvol ,rootvol , and var , which is und esirable.

4. Convert the rootdisk from an encapsulated to an initialized disk.


12/15


The use of an encapsulated d evice for the boot disk makes that d isk a special case . Itcould be the on ly encapsulated device in an entire system. This one exception should

be removed in order to simplify ad ministration and service procedu res. This step isnecessary to help en sure the boot d isk and its mirror are exact clones. If one isencapsulated and one is initialized, the private regions of these disks will havedifferent ad dresses. This means tha t the offsets to the beginn ing of each volum e w illbe different. This should be avoided .

In add ition, by replacing the en capsulated boot d isk with an initialized boot disk,the remnants of the encapsulation of rootdisk-B0 , and rootdisk-Priv will beremoved from the configuration as they are no longer requ ired.

An effective means of replacing an encapsulated disk with an initialized one is to failthe encapsu lated d isk and replace it with itself. This procedure w ill initialize(instead of encapsulating) the replacement drive. Common ly, a typical method bywh ich a d isk is failed, and th en replaced, is accomp lished by using the vxdiskadm

function. How ever, as previously d iscussed , this method does not alw ays reattachthe mirrors in an optimu m ord er. An alternate method of replacing an en capsulateddisk with an initialized one without using the vxdiskadm function is discussed inAppendix A or B.

5. Map volum es to d isk slices/ partitions for core operating system file systems.

The major file systems necessary to support the fundamentals of an operatingsystem are root , /var , and /opt . If the /usr file is on a separate v olume, it wou ldalso be included in this list. In times of extreme system distress, access to these filesystems, regardless of w hether VxVM is functioning, is desirable. To ensu re this ispossible, disks mu st be re-partitioned to m atch the volum e definitions.

The VxVM tool comes w ith a u tility nam ed vxmksdpart , which map s a volumes

primary subd isk to a low-level disk slice with the same g eometry offsets and length.With the u nd erlying slice available for mou nt, a technician can u se that han dle toaccess the data in an emergency. Even if VxVM is not available, the vxmksdpartutility can be found in /etc/vx/bin on an y stand ard VxVM installation. Run thecommand with no arguments to get its usage and help information.

6. Increase the number of configuration file copies to "ALL"

To help prevent loss of the configuration database file, configdb, each disk withinthe d isk group should be forced to carry an active copy of the file. The VxVM toolplaces a backup copy of the file within the p rivate regions of man y of its man ageddisks (but n ot all). The Volume Ma nager a ttempts to d istribute th is data forresiliency, however, it does n ot force a copy to each d isk. If each group within th edisk group carried a n active copy of the d atabase configuration file, it would ensure

its recovery, even if only one d isk survived a m ajor system malfunction.


13/15


7. PROM device aliases

Ensure each mirror of the rootvol file is bootable. Also, that a d evice alias exists atthe op en boot p rom (OBP). This will help en sure ease of booting from all suchmirrors. The vxeeprom function is a way to d o this, however, the user-definedaliases can also be edited in th e following w ay:

eeprom nvramrc > file

vi file

eeprom "nvramrc=cat file"

8. Provide a fail-safe boot device with VxVM installed.

The Solaris Operating Environment installation CD-ROM is a boot device that can beused wh en all else fails. Unfortunately, it does not h ave a cop y of the VxVM

software. Therefore, it is not possible to boot from the Solaris OperatingEnvironment CD-ROM and still operate VxVM. This poses a problem in situationswh en the system mu st boot from the CD-ROM to effect a repair, but cannot u se theroot volume. There are workarou nd s for this problem, however, they can be tediousand error prone, except in the most experienced of hands.

An effective m ethod for helping ensu re the ability to operate VxVM w hen all elsefails, is to p rovide a fail-safe boot dev ice w hich has been p repared for VxVM use.The following lists two w ays to d o this:

s Reserve a d isk within the system as a snap shot disk. Set aside a conventional disk which is not under VxVM control. The disk should be updated with systemchanges as they occur to the operating system. This snapshot disk will have theVxVM drivers and utilities, but w ill not dep end up on VxVM to boot.

s Add VxVM to the JumpStart server via MRtools. The JumpStart server providesa CD-ROM image to a ny client w hich attemp ts to boot from it. This image can bemod ified to operate VxVM (and other ad d-on p rodu cts). Any client which bootsfrom the modified image will then have access to the products. In either case, it isessential to have a boot d evice not un der VxVM control, and yet wh ich loads th eVxVM utilities and drivers. This permits the m anipu lation an d repair of VxVMdevices without h aving to comp romise the configuration just to get the system toboot.

App endix A:

Note See the August 2000 edition for the Sun BluePrints article titled Towardsa Reference Configuration for VxVM Managed Boot Disk for a detailed explanation

of the procedu re listed below.


14/15


Mirroring boot disk without using vxdiskadm

# /etc/vx/bin/vxdisksetup -i c1t1d1# vxdg -g rootdg adddisk rootmirror=c1t1d1# /etc/vx/bin/vxrootmir rootmirror# vxassist -g rootdg mirror swapvol rootmirror# vxassist -g rootdg mirror var rootmirror# vxassist -g rootdg mirror opt rootmirror# vxdisk -g rootdg list

Note The rest of this exercise assumes the following bindings:

rootdisk=c0t0d0 and rootmirror=c1t1d1. If your device nam es differ, be sure tosubstitute accordingly.

# vxplex dis rootvol-01# vxplex dis swapvol-01# vxplex dis var-01# vxplex dis opt-01# vxedit -fr rm rootvol-01 swapvol-01 var-01 opt-01# vxedit rm rootdiskPriv

Note rootdiskPriv may or may n ot exist, depending up on how the disk wasencapsulated . Remove it if it does exist. Ignore if it does not.

# vxdg -g rootdg rmdisk rootdisk# /etc/vx/bin/vxdisksetup -i c0t0d0

# vxdg -g rootdg adddisk rootdisk=c0t0d0# /etc/vx/bin/vxrootmir rootvol rootdisk# vxassist -g rootdg mirror swapvol# vxassist -g rootdg mirror var# vxassist -g rootdg mirror opt

General Procedu re

1) Attach mirrors to rootvol , swapvol , var , opt (vxrootmir , vxassistmirror )

2) Detach original mirror copies & remove them from configuration ( vxplex dis

and vxedit rm )3) Re-initialize rootd isk. ( vxdg rmdisk and vxdisksetup )

4) Re-attach mirrors to initialized rootdisk ( vxrootmir, vxassist mirror )


15/15


Author s Bio: Gene Trantham

Gene Trantham is a Staff Engineer for Enterprise Engineering at Sun Microsystems. Prior to joiningSun , he spent eight years as a UN IX system administrator specializing in storage management and disaster recovery. While at Sun, Gene has spent most of his time in the field, servicing storage and high-end servers at some of Suns largest accounts.

veritas vxvm storage (sun)

Documents