Lesson 3: Install and Configure - Creating a Volume and File System - Text

Page 1 of 6

LESSON 3: INSTALL AND CONFIGURE - CREATING A VOLUME AND FILE SYSTEM

PRINT DOCUMENT

Lesson 3 Creating a Volume and File System

BOB LUCAS: Hello and welcome to Lesson 3, Creating a Volume and File System.

Lesson topics and objectives

In this lesson we'll discuss preparing disks and diskgroups for volume creation, creating a volume and file system, displaying
diskgroup information, displaying volume configuration information including Volume Manager objects such as disks, subdisks, plexes,
and volumes,
Preparing disks and disk groups for volume creation
and how to maintain a current configuration database in your diskgroup.
Selecting a disk naming scheme
One of the things you are going to be asked during installation of the product is whether you want to use enclosure-based naming or
traditional OS-based naming. And we identify these as ebn for enclosure-based, or osn for operating system based. In the past, the
operating system-based naming was the default, but in Version 5.1, we now have enclosure-based naming as the default. So don't be
surprised that if you pick all the defaults, you end up with sometimes strange looking names on LUNs or disks after the installation is
over. Those are just simply based on the enclosure that the disks are connected to. Now the enclosure-based name can be changed.
You can also toggle between operating system-based and enclosure-based naming by typing in vxdiskadm, running that menu-based
option and selecting Option 20 for Change the Disk Naming Scheme. And you can do that without any downtime at all to applications
or file systems. But again, enclosure-based naming is now the default with Version 5.1. And the enclosure-based name will show up
as a result of how Volume Manager reads the ASL, or the Array Support Library, from the hardware vendor. If Volume Manager has a
problem reading the ASL or there is no ASL, it will treat the enclosure as jbod, just a bunch of disks. In that particular case, if you
choose enclosure-based naming, the disk may be named as the word disk and an underscore and then an enumeration number, so
Disk_0, Disk_1, and so on, which doesn't really help you figure out what's inside the enclosure. So if that's the case, if you do not
have an ASL for your particular Array that you're connected to or you know that it's an outdated ASL, you might want to not select
enclosure-based naming but rather select operating system-based naming until you can get a more updated ASL and then change
back.
Disk configuration stages
We talked a little bit about earlier initialization, encapsulation, adding disks to a diskgroup, and then making volumes on those disks
in the diskgroup. I'd like to take you through some of the evolution of a disk and the stages in that evolution as we go through these
tasks. The first stage is to start with a physical disk from the OS, regardless of whether you're using ebn or osn, the disk is not yet a
Volume Manager disk, so it doesn't have a private region and it does not have a public region either. And those are the first things
you need to put on the disk for Volume Manager to control it. So the first thing that has to happen is you have to either initialize the
disk or encapsulate that disk. In this example we're going to initialize the disk which, as we said before, means we restructure the
VTOC of the disk and we create the private region and the public region. If this disk is a CDS disk, we have the public and private
regions inside one physical partition of the disk. If not, if it's a traditional sliced disk, then the public and private regions would have
their own partitions on the disk. Either way, the disk is now a Volume Manager disk. Now for that disk to gain a disk media name,
which is again a name related to the diskgroup that houses that disk, you will have to add it to a diskgroup and put it in the house.
So we are going to put this diskgroup in the datadg house or the datadg diskgroup, and by default, the disk will be named as
datadg01. Now you can change that name if you like, but again, we recommend not to change the name to something that doesn't
relate to its house or its mother object, datadg. So datadg01 is probably a good choice to leave as is. So we'll leave it as is, and now
you have what's known as a Volume Manager device node to that actual disk datadg01. You're also going to have a dmp device
node. If you look at the bottom of the slide there, you'll see disk access name dev/vx and dmp or rdmp and then something called
the access name. The access name is the physical name for that disk so that would be if you're using osn, it will be something like ctd
on Solaris operating system, or maybe sda on Linux for example, or if using an enclosure-based naming, it will have the name of the
enclosure itself with an underscore and an enumeration after the enclosure name. So that disk access name is going to also be
created when you bring that disk into a diskgroup. And then the last stage is to actually put volumes on those disks that you just
added to the diskgroup. And again, you can create any type of volume that Volume Manager supports if you have the disks or space
in those disks to do it. So for example, for a mirrored volume you need at least two disks in that diskgroup. For a striped volume, you
need at least two disks in the diskgroup. For a RAID-5 volume, you need at least three disks, for a RAID-5 volume and we'll talk
about that a little bit later in the lessons. But the type of volume you want to create depends on the number of disks and the space
on those disks inside that diskgroup.
Disk group purposes

http://symantecpartners.vportal.net/media/symantecpartners/media/_generated/transcripts/t... 8/23/2011

Lesson 3: Install and Configure - Creating a Volume and File System - Text

Page 2 of 6

With that said, let's go into diskgroups in a little bit more detail. There are really two reasons to have disks groups. The first is fault
tolerance and high availability. The idea being that if you lose a server or a system connected to many, many disks, you don't want to
have to go to a second server even in a failover environment and try to have to import each individual disk one at a time. You may
have to do that 100, maybe even 1,000 times, especially in a SAN environment, depending on how many disks you have. It's a lot
easier to do a one single command vxdg import and give it a diskgroup name. And remember the diskgroup knows about all of its
own disks because the disk media name is imprinted in the private region of those disks as well. That's how the diskgroup identifies
its disks. So all you have to do is a single command called vxdg import and then the name of the diskgroup, and it picks up all the
disks at the same time. So that's fault tolerance high availability. The other reason to have diskgroups is to have an orderly, ease-ofadministration or management and create boundaries around those disks, especially for applications or maybe even departments in a
company who want to use those applications and only those disks and not others. For example, if you look in the slide there, maybe
your accounting diskgroup would be for your accounting team that uses a particular application for accounting. Maybe your
engineering people use release code and source control software. You want to have maybe an engineering diskgroup that has a disk
that can perform faster and do a lot of some specific types of caching. So IO would be faster in one way versus another, because
they use a lot of the same type of (inaudible) applications.
System-wide reserved disk groups
So these are other reasons to have diskgroups. Now as of Version 4.0 we started to reserve certain diskgroup names for certain
purposes. For example, as of Version 4.0 when you wanted to encapsulate your boot disk, remember encapsulation means maintain
data on that disk, rearranges the partition table, not the data, when you did that, now in Version 4.0 and later, you will get an option
to create what's called a bootdg. A bootdg is going to be the diskgroup that's going to house your boot disk and any other disks that
you want to add to it maybe to make a mirror of your boot disk, which is also a good idea if you encapsulate your boot disk. That
diskgroup needs to have a name, but the name cannot be bootdg, it has to be something like sysdg. It can be rootdg, for those of
you who are familiar with earlier product versions, you may already have a rootdg if you've encapsulated your boot disk in the past.
You can keep that boot disk encapsulation right where it is and only change your data diskgroups at this point, that's fine. But this
assumes you don't have an encapsulated boot disk yet, so you will have to give it a name, and the name cannot be a reserved name.
Another reserved name is defaultdg. Now the defaultdg is a little bit different. The defaultdg allows you to create and manage
commands with diskgroups without having to add an option called -g diskgroup_name, every time you want to do a command.
Volume Manager assumes that you do not have a default diskgroup, that every time you want to do a command such as make a
volume, mirror a volume, remove a volume, or do things within a volume, just say -g diskgroup_name in the command. However, if
you put in your defaultdg and you give the defaultdg a diskgroup name, that name will be used in place of the -g diskgroup name
option. So it will assume that you want to do operations on your defaultdg diskgroup name. Now you cannot name a diskgroup
defaultdg, but you can name it anything except for those three reserved names in that diskgroup, if you set it to the defaultdg, that
will be used as your default diskgroup. So think of the bootdg and the defaultdg as variables, not disk names, but rather environment
variables. You cannot set your bootdg to bootdg. You cannot set something to defaultdg. You set some name to bootdg and you set
some name to defaultdg and those names are your constants or your variables that you create, and those will be used in your
commands. If you don't do either one of those things, then the name associated with your variables will be nodg, and that is also a
reserve name. So if you look at System B in the slide, that particular engineer did not encapsulate their boot disk and they did not set
a default diskgroup; therefore, the nodg value is set to each one of those variables. That means that person will have to do a -g
diskgroup name to all the commands when they want to operate on volumes and it will also not assume that there is an encapsulated
boot disk there as well. Now if you want to change or display what's being set, you can see the commands at the bottom of the slide
that allow you to do that. If you want to change one of these variables, you can only change your defaultdg. You cannot do a vxdctl
bootdg, because that would be an encapsulation or an unencapsulation. We have different commands to encapsulate and
unencapsulate your boot disk. The only thing you can change is your defaultdg, it's an immediate change and it is a system-wide
change. So it affects all operations to volume objects on that system when you change it.
Creating a disk group
Let's talk about creating a diskgroup. Diskgroups are meant to be management boundaries, for instance, you cannot do RAID
operations across from one diskgroup to the other. If you create a volume and you want to mirror that volume, that volume must be
mirrored on another disk or disks inside the same diskgroup. You can't do cross-diskgroup operations. In addition to that, your disk
media names have to be unique in that diskgroup, which kind of makes sense. You don't want to have two disk01s for example in the
same diskgroup or two accounting dg02s in the same diskgroup. You can have two of the same media names in different diskgroups,
but that also isn't really a best practice. The best practice is to keep the disk media names unique in the diskgroup and across
diskgroups but also have them reflect their mother ship, the diskgroup name itself, to tell you what they're used for.
Creating a disk group: CLI and vxdiskadm
To do these commands we can do them in a few different ways. One of the most popular ways to create a new diskgroup is to do
this through vxdiskadm. And the option for this, the first step anyway, would be add or initialize one or more disks. And then once
you initialize the disk, it'll ask you for a diskgroup name. If you don't have a name it will create one for you. You give it that name, it'll
ask you if you want to add any additional disks to that diskgroup, you could say yes or no, and once you're done, you have disks in
the diskgroup that you can now create volumes with. You can also go low level and you can do the command line command such as
vxdisksetup to initialize the disk, vxdg init to create the diskgroup, and vxdg can also add disks at the same time to that diskgroup in
addition to creating it. Or if you've already created a diskgroup, you can add disks one at a time with a similar format and syntax in
that vxdg command at the bottom of the slide. So these are all the commands that both vxdiskadm and the VEA will call under the
hood if you do those commands through those interfaces as well. So let's talk about that, let's talk about the VEA.

http://symantecpartners.vportal.net/media/symantecpartners/media/_generated/transcripts/t... 8/23/2011

Lesson 3: Install and Configure - Creating a Volume and File System - Text

Page 3 of 6

Creating a disk group: VEA

I want to make a new diskgroup from the VEA, connect to a server, identify one disk or several disks. Or you don't even need to
identify disks; you can just hit the button at the top of the VEA window that says New Disk Group. And this will bring up this dialog
box right here. And then you type in a diskgroup name, in this case we have datadg. Enable cross-platform data sharing should be
enabled by default. That would be your cdsdisk, so this option will initialize the disks as cdsdisks and add them to the diskgroup in
the same session. You don't have to put in anything for the disk names field at the bottom of the slide. It will default name the disks
based on the diskgroup name, which is datadg above it, so it'll say datadg01, datadg02, and so on and so forth, by default.
Creating a volume
Once you have disks in the diskgroup, you can now create a volume for those disks.
Creating a volume: CLI
The best way to create a volume, at least from the command line, I think, is to do vxassist -g diskgroup_name make volume_name,
and then you give it a size and then you have all kinds of attributes that you can add onto the end of that command. Let me just give
you a quick primer on vxassist, because I mentioned earlier that vxassist was a very extensive command that you probably need to
get a little bit of help before you use it. The best way to understand this is the defaults, what does vxassist want to do by default?
Vxassist wants to create a concatenated volume on the first disk it can find in the diskgroup without any special attributes or typed
definitions on that volume. Concatenated volume is always the default and the disk it finds is always the first free disk in the
diskgroup. So maybe the first disk it finds already has a volume or a subdisk on the disk. If that's the case vxassist will look towards
the second disk in the diskgroup and it'll keep going until it finds a disk that's free and has no volumes on it, so it'll choose that disk.
You're going to have to give the items in blue, except for attributes, you need to give it those first three items in blue or the
command won't work. You have to give it a diskgroup name, you have to give it a volume name, and you have to give it a length.
And the length can be specified in megabytes, gigabytes, terabytes even pedabytes. You also have to give it a vxassist -g diskgroup
name unless you've set your defaultdg variable, in which case you don't need the -g diskgroup name and the diskgroup name that
will be picked up is what's set to your defaultdg. So here's an example, and when you run that example, it creates your device paths
underneath that, so you can see the block device and the character device paths are automatically created for that volume. And
here's the command I was referring to earlier, vxassist help, and then the show attributes is one of the categories that you can get
help on with vxassist. So if you just type vxassist help, you can get all the categories listed one after the other.
Creating a volume: VEA: Assigning disks
The equivalent task in the GUI is as follows. Hit the button that says new volume or you can go to the menu and select actions, and
then new volume. Select the disk on the left-hand side, and then you hit the greater than button right at the top in the middle of the
slide there, to get to datadg01, 02.
Creating a volume: VEA: Setting volume attributes
Give it a volume name, in this case we have datavol01, give it a size, in this case we have one gigabyte. If you hit the maxsize
button, something interesting happens. What happens is Volume Manager will go out to that diskgroup where this disk or disks live
and it will analyze all the free space for all the disks in that diskgroup, not just on one or two disks, but all the free space everywhere.
So if you hit maxsize, you'll get a very large number that appears inside the size field. Probably not a good thing to do would be to go
ahead with the task at this point, because what you're doing is, you're eating up all the space that you have on that diskgroup. And
you won't be able to do anything else in the diskgroup if you make a volume that's that huge. My recommendation is for maxsize is to
use maxsize as just a query command and see how much space you actually have. Maybe you have plenty of space, maybe again
that you don't. Maybe there's volumes already made and you don't know they're there, so what you can do is use the maxsize, show
the value in the window and then only take enough of that value that you need to create the volume you need. So you do that, and
then you can see in the bottom area you have choices of concatenated striped, concatenated mirrored. We also have an option to
select a mirrored volume, which will again require more than one disk at least and you can do things like enable fast re-sync and
initialize zero. If you decide you want to enable fast re-sync, that speeds up resynchronization operations if this volume is going to be
mirrored and mirrored as a snapshot if you want to re-use a snapshot time and time again, for instance for backup operations. The
initialize zero option will actually write zeros to all the free space on that disk in the volume before it gives it up as free space in the
volume. So that's more of a security measure than anything. That actually writes zeros to the space before you're allowed to use it.
Creating a volume: VEA: Adding a file system during volume creation
You also have another option to create a file system, or not, as the case may be. If you decide you want to create a file system, it
can be the native file system from that operating system. So for instance, UFS on Solaris or it could be our Veritas file system or
VxFS, and you can choose the block size for that file system. The block size has a great effect on performance characteristics for that
file system and the application that uses it. If you have any special options you want to add in this task, you can add them by clicking
on the buttons that say mount file system details or new file systems details; you can give it a mount point as you see there. And if
you click add to file system table, it will add it to the /etc/vfstab or on Linux the /etc/fstab file. That allows the system to boot, and
when it runs with the boot process, it will mount the file system automatically as part of the boot process.
Adding a file system after volume creation

http://symantecpartners.vportal.net/media/symantecpartners/media/_generated/transcripts/t... 8/23/2011

Lesson 3: Install and Configure - Creating a Volume and File System - Text

Page 4 of 6

Here we have a table that kind of details the tasks for creating a file system from the command line and compares those tasks
creating a file system through the VEA. There's really two steps, there's just making the file system and mounting the file system.
And there's all kinds of options that you can add on the command line or even in the VEA
Mounting a file system at boot
depending on what kind of performance you want out of that file system for certain types of IO. This is a deeper view into the
command line and VEA versions of adding a file system to the /etc/vfstab or fstab. You can see it's going to populate that file as you
normally would if you decided you wanted to edit the vfstab yourself. So it'll put in the block and raw devices, the mount point, the
file system type, the fsck pass indicator and the mount at boot, yes or no.
Displaying disk and disk group information
As far as disk and diskgroup operations go, most of the time the command line is the way to go for disk and diskgroup operations.
Viewing basic disk information: CLI
The Veritas Enterprise Administrator is the way to go for volume and plex operations, and that's not necessarily a standard that you'll
find in any books or any documentation. That's just something that I know from using the product for many, many years and
teaching this course for many years, is that it's easier to do disk operations from the command line because there's more operations
that you can do from the command line that you may not be able to do from the GUIs. That includes switches, parameters, options
to things like vxassist, vxprint, vxdisk, and here we have an option called -o alldgs list, for vxdisk. This is going to show you the status
of your disks. And if you look at the disk column, these are the disk media names that this host system can see right now, and you
can see they're both in the diskgroup called datadg. If you look on the bottom of that output, the last device in the list is c1t17d0s2.
That disk has a diskgroup name that's in parenthesis, hrdg. The reason for that is this particular host server can see the private
region of that disk, but it notices that the private region does not have its own host ID or host name imprinted on it, it has a different
host ID or host name. In fact, it has the host ID or host name of a system and it shows hrdg as the actual name for that disk. So
anything in parenthesis in the diskgroup column indicates something that it sees in the private region of the disk, but it can't get
control of, usually because either another host has control of it, or because that hrdg diskgroup was deported and no host has control
of it. One of those two things should apply there. You also see that there's several disks that do not have diskgroup designations. And
this one that's being outlined right now with the label called Free Disk, that's a disk that has been initialized but is not yet part of any
diskgroup. How do we know it has been initialized? Is because the invalid tag is not there next to it and the CDS tag is right next to
the word auto, which tells us it has to have a private region and that therefore it has to have initialization at this point, and it also is a
CDS disk. So it has to have a slice seven, and it has to have that reserve region that we talked about earlier on a CDS disk. Whereas
the other four disks in the output have auto none and online invalid. If you see none and invalid, that means those disks have not
been initialized yet by Volume Manager and they don't have a private region.
Viewing basic disk information: CLI
We can also get detailed information by typing vxdisk list with the -p option. This will show you discovered properties of a disk such
as vendor ID, worldwide numbers, and anything else that you wouldn't normally see in just a regular vxdisk list output.
Viewing all disks: VEA
The VEA can show you some of this information but not always all of the information. So you don't see any worldwide numbers under
there or anything like that, you see some things, but not all. One thing that the VEA is very good at though is showing you usage. If
you look at this slide in the dialog box you'll see at the bottom left... You can indicate if disks are getting normal, high or even critical
usage based on the amount of space that's being used on that disk by the different colorings and the icon, that's something that's
been in the product for awhile.
Viewing disk properties: VEA
You can also right click a disk and select properties and you can drill down to a certain extent to see the capacity, unallocated space
in the disk, type of disk that it is. Whether it's a CDS disk or not, whether it's an EFI or extended firmware interface disk or not.
That's an Intel spec for certain disks that want to represent a lot of space, and whether it's a spare or reserved or hot-use disk or not.
Viewing disk group information: CLI
This command just shows you the diskgroups, whether they're enabled, disabled or not available, and then the ID for the diskgroup.
Now the ID is a unique number that's created when the diskgroup itself is created so that we don't confuse two different physical
diskgroups. Even if somebody tries to name two diskgroups the same name, the ID will never, ever be the same because it's a unique
ID based on several time-based factors. Even if these two diskgroups were named datadg, the ID would be different. Best practice of
course is not to name your diskgroups the same name and to keep them separate names at all times. If you want to see how much
free space there is available on the disk, kind of like a maxsize parameter, you can do your vxdg free command and that will show
you how much free space is available and on which disk in that diskgroup it's available.
Viewing disk group information: VEA

http://symantecpartners.vportal.net/media/symantecpartners/media/_generated/transcripts/t... 8/23/2011

Lesson 3: Install and Configure - Creating a Volume and File System - Text

Page 5 of 6

Another important thing about the diskgroup is the version of the diskgroup. If you look at this slide, the middle of this properties
window shows this diskgroup as Version 150. The versioning for the diskgroup indicates the feature set, the things that can be done
in the disk, in volumes that are in this diskgroup with respect to what version of product you have. So when the version of the
product revises... For example if you upgrade from Storage Foundation 4.1 to Storage Foundation 5.0 or 5.1, you will have the
capability to do more things in the product, you'll be able to do a lot of new features in the product. To do that, however, you have to
have an upgraded diskgroup as well as an upgraded product version. So the diskgroup upgrade is a separate task and even a
separate command than the act of installing or upgrading a new version of the product. And I'll show you a little bit more about
upgrading the diskgroup a little bit later.
Displaying volume configuration information
Let's talk about volume information.
Displaying volume information: CLI
This command, vxprint, is probably the single most useful and informative command in Volume Manager from the command line.
Because there's several different options to it, but it allows you to see volumes and all the associated Volume Manager objects in
many different formats and different ways.
Displaying volume information: CLI
Here is an example, a very common vxprint output. This is vxprint -ht -- H stands for hierarchy and T stands for tabular. Hierarchy
means that the first thing you see in the slide at the top here are all in capital letters. These are actually headers, these are not actual
values, these are headers. Headers for diskgroup, disk media, volumes, plexes, subdisks, disks, and things like that. Underneath that
where you see the lower case you have dg, datadg. That's where the actual values start in the diskgroup. It tells you what diskgroup
you're dealing with. The minor numbers for that diskgroup that are available for usage. The ID for the diskgroup. It tells you how
many disks are in the diskgroup. In this case there's four, datadg01 through 04. And it tells you the LUNs, the disk they're associated
with, c1t10, 11, 14, and 15. And it also tells you the private region length and public region length of each of the disks themselves.
So you can see how big the disks are, how big the LUNs are that are representing those disks. Underneath the disk output you'll see
the volume. And in this case the volume only has one plex and one subdisk, so you might want to ask yourself what type of a volume
does this look like to you? Does this look like a mirrored volume, does this look like a striped volume, or does it look like a
concatenated volume? If you guess concatenated volume, you're correct, because this only has one plex and therefore it cannot be a
mirrored volume just by definition. Also, it only has one subdisk, so therefore it cannot be a striped volume by definition because
striped volumes are going to be across multiple physical disks and therefore they're going to have multiple subdisks as well. So you're
looking at a concatenated volume that is 2097152 sectors long which is effectively one gigabyte, and it happens to be on a physical
disk c1t10d0, single disk, single subdisk, single volume.
Object views in the main window
Now this you can't always get in one command or option from the VEA, from the GUI. However you can get a lot more information if
you drill down just a little bit further. Like for example in the volumes you can see we can drill down from datavol02 into the disk
views. We can look at its mirrors; we can even look at its subdisks, and do what we need to do through the VEA.
Removing volumes, disks, and disk groups
Let's talk about removing these things, removing volumes, disks and diskgroups.
Removing a volume
The first thing that you want to remember about removing a volume is that if you remove a volume, the user data goes with it. You
cannot remove a volume and get your user data back, because when you remove a volume, you remove all the reservations and
volume objects that house that data. The data can't stay there if there's no reservations for it, so the data goes with the removal. So
you've got to be sure you want to do this before you do it. When the volume is removed, however, the space can be reclaimed and it
can be freed up and used elsewhere. Volumes cannot be removed until you unmount an active file system if there is an active file
system that's using it. So whether you choose the VEA or the command line, if you have an active open file system, you'll get a
prompt to say you have to unmount the file system before you remove the volume that's underneath it. Here are your commands
right here. There are actually two different command line commands to remove a volume and they're both equally as effective. It just
so happens that the vxedit command can remove more than just volume objects themselves. The vxedit command can also remove
plex, subdisks, and components of the volume, in addition to the volume itself. By default, if you say vxedit -rf, that stands for
recursive and force. So if you remove a volume with -rf, you're also going to be removing all the mirrors in that volume, if you have
mirrors, and all the subdisks inside that volume and therefore the data goes with it. Same with the vxassist remove; you're also
removing everything inside the volume including its component objects.
Evacuating a disk
Maybe you don't want to delete the data permanently. Maybe you just want to move the data from one disk to another. You just
want to remove all the volumes from that disk, but you want to save the data on another disk or set of disks inside the same

http://symantecpartners.vportal.net/media/symantecpartners/media/_generated/transcripts/t... 8/23/2011

Lesson 3: Install and Configure - Creating a Volume and File System - Text

Page 6 of 6

diskgroup. Then in that case you want do an evacuation of the disk. This is what this option does here. You can use the VEA for
actions evacuate disk. You can use vxdiskadm where the command is move volumes from a disk, or you can use the CLI where you
run a command called vxevac. You give it the first disk which is where you're moving the volumes from and the second disk which is
where you're moving the volumes to. So you always evacuate source to target, source to target. The VEA, the vxdiskadm and the CLI
will always copy the data and paste it. It will never cut the data and paste it, so if something happens in the middle of evac. If your
system crashes or a disk fails, you don't have to worry; the original data is still in the same place as it was when you started the
command. So when you evacuate, it doesn't matter how you evacuate, it copies block to block to the second set of disks, and only
when that set of disks is available and finished copied, does it remove the original from the first set of disks.
Removing a disk from a disk group
You cannot remove disks from a diskgroup permanently unless they have been evacuated. So in other words, a disk can only have no
volumes on it, meaning it has to be a free disk, before you remove it from a diskgroup. If you try to remove a disk from a diskgroup
and it has volumes on it, you're going to get an error indicating that you need to remove all the volumes from the disk and delete
them or evacuate the disk to another set of disks in the same diskgroup. This is removing a disk from a diskgroup. And each one of
these options will check and see if there are any volumes in the disk before it removes the disk. And if there are, you'll get that type
of a prompt and you have to follow it through. Notice the very last command in this slide, vxdiskunsetup. The vxdiskunsetup is a
command to uninitialize a disk. What it does is it removes the public and private regions from the disk after all the volumes have
been removed from that disk. You don't have to remove private and public regions from a disk if you're going to still use that disk
somewhere else in Volume Manager. Usually the only reason you do an unsetup is to completely remove Volume Manager off of that
disk and use it in another completely different environment. So if you're only moving disks from one diskgroup to the other, and you
want to evacuate volumes in the process, you do all the commands here but you don't need to do the vxdiskunsetup. You need to VX
evacuate the disk and take care of your data as well.
Destroying a disk group
If and when you want to destroy a diskgroup, think of destroying a diskgroup as deleting all volumes from all disks inside the
diskgroup and finally destroying the diskgroup itself. The diskgroup is kind of a chicken and egg problem. The diskgroup is not itself a
volume object. The diskgroup is a figment in the imagination of each one of the disks, and what I mean by that is, it only exists in the
private region of the disk. Inside the private region of the disk there is a field that has the diskgroup name imprinted on it. If that
field doesn't have that diskgroup name inside it, the disk doesn't know that it's part of a diskgroup and nothing else in Volume
Manager knows that that disk is part of a diskgroup either. So when we destroy a diskgroup, we have to blank out that little field with
that diskgroup name, and we also have to blank out another field called the host ID which indicates ownership of that diskgroup to
that particular host. So destroying a diskgroup, the diskgroup will no longer exist, your volumes will be all gone, and your data inside
those volumes will be all gone. You cannot evacuate things from one diskgroup to the other. You can only destroy a diskgroup or
maybe move the data and maybe snapshot it to another diskgroup. You can split a diskgroup, but you cannot move things between
diskgroups unless you have splits going on. So what this slide indicates is, we had an old dg with maybe some disks and volumes. We
destroyed old dg and now what it's done is it's removed all the volumes from the diskgroup, blanked out that little field that has the
diskgroup name in the private region of the disks, and now the disks are left in what we call the free disk pool. The free disk pool has
disks with private and public regions but none of these disks are owned by any host nor any diskgroup. Now we can use these disks
to add or form a new diskgroup if we wanted to.
Lesson summary
And that concludes Lesson 3. Thank you very much.

http://symantecpartners.vportal.net/media/symantecpartners/media/_generated/transcripts/t... 8/23/2011