You are on page 1of 6

Lesson 9: Manage and Administer - Managing the Boot Disk with Storage Foundation - T...

Page 1 of 6

LESSON 9: MANAGE AND ADMINISTER - MANAGING THE BOOT DISK WITH STORAGE FOUNDATION
PRINT DOCUMENT

Lesson 9 Managing the Boot Disk with Storage Foundation

BOB LUCAS: Welcome to Lesson 9, Managing the Boot Disk with Storage Foundation.

Lesson topics and objectives


So in this lesson we'll learn how to encapsulate the boot disk. We'll learn how to mirror an encapsulated boot disk.
Placing the boot disk under VxVM control
We'll learn how to administer a boot disk and unencapsulate the boot disk, in other words, remove the boot disk from Volume
Manager Control. So first things first, let's start with encapsulation.
Placing disks with data under VxVM control
Earlier in the lessons, at the beginning of these lessons, we learned how to bring a data disk into Volume Manager and put it under
Volume Manager Control. And we had two choices before we brought that disk into Volume Manager, we could either initialize the
disk or we could encapsulate the disk. We chose to initialize the disk if the disk did not have any meaningful data that we needed on
it, or if the data did not have any partitions in its partition table. On the other hand, we chose to encapsulate the data disk if it did
have data partitions that were pre-existing even if there was no data in that partition table. We did it as a best practice just in case
we wanted to save whatever happened to be in there or to put data in there later. Well now we're dealing with a boot disk and of
course, the boot disk should not have any user data on it. It should have administrative data for booting the system and getting it up
and running, and that's pretty much it. So most of the time you do not need to encapsulate the boot disk if your boot disk is mirrored
in hardware or at the LUN level or the OS level, and many times that is the case. So you might be asking yourself this question, why
should I bother encapsulating the boot disk and bringing it under Volume Manager Control. What does that do for me? Well, the
number one thing that it does for you is that it allows you to control the disk with Volume Manager and then mirror that disk using
Volume Manager, Volume Mirroring, such as we've been discussing throughout the entire lessons. So for example, when you
encapsulate the boot disk you want to immediately mirror the boot disk onto an additional disk in your boot disk group. So that if you
ever lose your boot disk or the system ever goes down with the boot disk, you can at least boot off that other boot disk that you just
made a mirror for. Volume Manager is very efficient in mirroring your boot disk to another disk and setting up that second disk with
everything that it needs, even if it's in the partition table or not, to boot that system. It will also add some statements to your ETSI
system file or another operating system, your system file, your EEPROM area and areas that direct hardware, which device they
should boot off of. I will show you commands in this lesson to take care of all of that with one easy command vxdiskadm option 6,
mirror a disk. In this case, it's going to be your boot disk. So on Solaris, encapsulation is the process of converting partitions in the
partition table into something else. In terms of partitions, they convert those into volumes, which you then can mirror with your
familiar Volume Manager vxassist commands. On other operating systems it may be a little bit more complicated depending on
whether those OS use logical Volume Manager tools or not. HP and AIX happened to use a lot of LVM tools and most of the time your
boot disk on those operating systems is already going to be some type of a logical volume disk, or in this case we call them physical
volumes. So on other operating systems, encapsulation is more like conversion. So you convert those LVM volumes into Volume
Manager volumes and then they stay that way. But you can equally mirror those volumes just as you would on the Solaris operating
system.
What is rootability?
So we have to make sure that if we encapsulate our boot disk on any operating system, it also needs to be mirrored. If we
encapsulate our boot disk, almost all the time it's not going to be already mirrored in hardware, if it were, we didn't have to
encapsulate it. So we have to make sure that the boot disk is mirrored either in software or in hardware. We also want to think about
creating an emergency or alternate boot disk as a third boot disk, just in case there's a site disaster or the system blows up and it's
connected to both the original boot disk and the mirrored boot disk, those disks may not be accessible at all right now. But if you
have an alternate boot disk stored at another site or another location, you can pull that out, pop it in another system and bring up
that system on that alternate boot disk and continue your business from there. So we're going to talk about all of those things in
these lessons. Rootability is the ability to place the root file system, swap device or file system, and all the other supporting usr, opt,
var, or whatever other file systems help boot the system to set up your services and demons on that disk under Volume Manager
control during the encapsulation process. So there are three things you need when you want to encapsulate the boot disk, at least on
Solaris. The three things you need on the Solaris operating system boot disk are, you have to have a slice 2 in the partition table to
find that represents the entire disk top to bottom. The second thing is that you need to have two free partition table entries available
in the petition table. In other words, you cannot use all seven partitions in the table, you have to have at least two partitions
available to use. If you don't use all the partitions, Volume Manager tries to use tags 15 and 14 for the private and public region
respectively, and tags four and three for the public and private region, or private and public region, excuse me. So what happens
then is those partitions will be taken up and used for the boot disk for your public and private partitions. Now if you remember from
earlier lessons, we have a Slice disk format that we can use, we also have a CDS disk format that we can use. One of the
characteristics of the CDS disk format was that it can combine the public and private region in the same partition, you don't need to

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

Lesson 9: Manage and Administer - Managing the Boot Disk with Storage Foundation - T... Page 2 of 6

separate partitions. Now, unfortunately, we're not allowed to use CDS disks on our boot disk, or in fact, anywhere in our boot disk
group. So what we're going to have to do is, we're going to have to use sliced disks, and that's the reason why we're going to use
two different partition table entries, one for the part private, one for the public. So we also need 64,000 sectors or 65,536 (64K)
sectors worth of unpartitioned contiguous free space at the beginning of the boot disk or at the end of the boot disk, that's the third
thing we need. So that equates to 32K of space. Now most boot disks will have that, but if a boot disk is completely fully partitioned
and used, you're going to get an error when you try to set up the boot disk with encapsulation. Now there is a workaround to that if
you have a swap file system and partition defined in the partition table. In that case, if the root disk or the boot disk is completely
partitioned and used up, Volume Manager will automatically take the swap file system, carve a couple of cylinders out of the swap file
system and partition and use that for your private region and private area. So basically it will keep all your databases in that area on
that disk. Now that may be good for certain reasons but it may not be good for other reasons. Bottom line is you want to try to have
at least 32K contiguous space, unpartitioned space that is, available either at the beginning or the end of the boot disk so that when
you encapsulate the disk Volume Manager will just use that space for the private region and the rest of the space will be slice 2 for
the public region. So on this particular encapsulated boot disk, and this happens to be a Solaris disk, we're going to use -- we have
space at the beginning of the disk for our private region. We're going to use those partitions and convert them to volumes. And you
can see the color coding that's going on there, each color code on the disk equates to the volume on the right side of your screen. So
we you have rootvol, user, var, and swapvol. If we have an opt file system or an export home file system, those can be mirrored and
encapsulated as well. But the partitions are mapped directly to subdisks that are used to make those volumes, then they're going to
overlay the original partitions. So in other words, we're going to change the partition table in the VTOC of that boot disk. And we're
going to change it to a partition table that has public partition and private partition, or vice versa depending on where the private
space is available. And then the public partition is going to contain subdisks for root, swap, usr, var, opt, and all your other root base
file systems. Now, of course, this is all well and good for the time being but now you've actually decreased the availability,
Why place the boot disk under VxVM control?
and you've actually increased the possible down time potential for this boot disk because now you've added objects to the disk and
you've added objects to a disk group database that you will have created. If you remember from earlier lessons, you cannot have a
Volume Manager disk by itself without a disk group around it. So we had to have created a disk group before we encapsulated this
boot disk. So guess what question the encapsulated procedure is going to ask you about when you choose to encapsulate a boot
disk? It's going to ask you what disk group do you want to put this disk into. Now here's where you can choose something obvious,
like rootdg, or sysdg, or osdg. You can't choose bootdg, that's a reserve keyword, if you remember that from an earlier lesson,
because we use bootdg as a variable to the itse vxvol root file. So what normally people do is they, like I said, choose something
obvious like osdg, we'll use that as an example. So if we choose that, we want to keep an eye on the outputs and prompts for the
encapsulation process, whether you go through a VEA or a vxdiskadm because it's going to want to name the disk osdg01 just like it
would any other datadg disk, datadg01, datadg02, and so on. My recommendation as a best practice is to avoid that, say no, I don't
want to name it that. I want to name it something real obvious, like boot disk, root disk or something like that, or even OS disk
instead of 01, 02, 03, you don't want to enumerate it, just so that you can recognize it as the original boot disk. Then what you have
to do is add a second disk to that same disk group and name that something obvious as well, something like, mirror disk, alt disk, or
alternate. Once you have that other disk in there you can mirror the boot disk in its entirety to that alternate boot disk or mirror boot
disk. So that's the middle bullet on your slide right here, or the middle balloon. We mirror the boot disk to provide availability and
redundancy to the boot disk, in case the boot disk goes down, we can boot up on the other desk. Even if the boot disk doesn't go
down there's a nice benefit that SCSI gives us on that disk, especially for read operations. And that is, when the boot disk is mirrored
in a volume it fixes bad blocks automatically when there's reads coming into the volume and the read finds a bad sector or a bad
block somewhere in the rootvol on that boot disk. You might be wondering how that works. And this is a SCSI protocol, not
necessarily from us. But what happens is on the other mirrored boot disk, if the block is good on the other and it represents directly
to the original boot disk block, remember the volume blocks are the same all the way down, it's going to actually read the mirror
block, write it to the original block, and it will actually fix itself if it can. So it tries to do an internal write to the original corresponding
boot disk block that represents the mirrored block. What happens is you have an updated block on both sides, so it actually remirrors itself as it goes. Now this can only happen a certain amount of times before SCSI starts sending out errors. If it's a really bad
disk and it's failing, you're going to get a disk failure message, and of course, you're going to have a no device state in vxprint then
you have to replace the boot disk. But this is if you have an intermittent disk failure or a once in a while kind of disk failure where
you're getting bad sectors and bad blocks every once in awhile. But this is one nice feature that encapsulation in Volume Manager
and mirroring in Volume Manager gives you that the hardware mirroring may or may not give you. It also improves performance
because now you can do you reads from more than one plex on any one of those boot disk volumes. So that should boost your
performance quite a bit if you tend to access local files a lot. So the bottom line is, don't encapsulate unless you plan to mirror that
boot disk.
Limitations of the VxVM boot disk
Now encapsulating the boot disk and mirroring that boot disk may be quite different depending on the operating system that you run
in your environment. We have a lot of information in the instructor-led companion to this web-based training, which is the Five-day
Storage Foundation 5.1 class. The course manual for that class gives you a lot of detail and all the step by steps you need to see to
be able to do that in your operating system that supports Storage Foundation 5.1. So for purposes of this web-based training, since I
don't know which operating system you're running right now, we're going to try to concentrate on the more common OS independent
commands that you need to know about to be able to encapsulate, mirror, and administer your boot disk. In addition to that, I might
use a few examples from the Solaris file here just because that particular ILT class does its labs, as of the time of this recording, on
Solaris machines. So it might help you, where this is a complement to that class, it might help you understand how to do those labs
better and to retain that knowledge. So limitations of a Volume Manager boot disk, OS installations are supported, placed on the boot
disk gives you steps to OS upgrades. But when you encapsulate your boot disk on any OS and then you want to upgrade our
products storage foundation to a new version, you usually have to unencapsulate the boot disk before you upgrade and then reencapsulate it after you upgrade. I have some slides in the latter section of this lesson that show you how to unencapsulate the boot

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

Lesson 9: Manage and Administer - Managing the Boot Disk with Storage Foundation - T... Page 3 of 6

disk temporarily. Another important limitation is the system cannot boot from a boot disk that spans multiple disks or LUNs or
devices. An example of this would be a rootvol that is concatenated or spin from one disk to another physical disk, and then you try
to boot from it and sometimes you can boot from it and sometimes you can't. You can certainly not un-encapsulate that disk and
then hope to re-encapsulate it because once you un-encapsulate it, you remove the volumes from the disk and you're left with only
one partition on one disk as opposed to two, so you strand data on the second desk. So we want to make sure that whenever we
have a boot disk that we want to encapsulate, that all of the data and partitions and stuff is on that single boot disk. And if you need
to get a larger boot disk, then go ahead and do it, but we don't want to spin from one into the other. We also don't want to change
the layout of volumes on the boot disk after it's been encapsulated because that can cause some unexpected results to the data in
some of those volumes, especially if you are doing different types of relayouts within those volumes. Those are volumes that are not
meant to be relayed out, they're only meant to be grown if anything, which you can do. But we don't recommend that you change
the layout of those boot disk volumes. Also, you don't want to expand boot disk volumes or shrink boot disk volumes using the
familiar vxresize. Instead we have a command called vxrootadm which grows volumes on a boot disk. That's a command that we're
going to discuss a little bit more about in the lesson and it's also covered extensively in your course manual for the ILT.
File system requirements: Solaris only
So let's use Solaris as a brief example here for the file system requirements. So we're going to have file system on top of all these
volumes here, and almost always you're going to see UNIX file systems or UFS type on each one of the boot disk volumes. Now we
don't want to change the type of file system on the volumes typically, unless we have a really good reason to. In fact, we cannot
change the type of file system to be VxFS on the root and user volumes. We can on other volumes on that boot disk but there really
should be a good enough reason to do that because if these volumes are never going to be as large as their shared data volumes,
you might not see the same benefits or get the same benefits out of VxFS on these volumes as you would on shared data volumes.
We also don't want to use dirty region logging on the system volumes. It's perfectly okay, and we actually recommend it, to mirror
the boot disk volumes but not to use dirty region logging. We can use dirty region logging for opt and var, but not root, swap, and
usr. For the swap volumes, the swap volume must be contiguous. The volume can't use striped or layered layouts. We're very specific
about the way the swap volume needs to be architected or created. If you have other swap volumes, those can be noncontiguous
and use any layout. But the whole purpose of a swap volume, whether it's a partition or a volume, is to hold temporary data being
swapped back and forth between the memory in the system and the disk. So we want to make sure that that data is fast performing.
We don't want to do anything special to it. We want to give it all that it needs to help you swap from one to the other. Now if you
happen to be using HP-UX -- I'll just jump to this slide for a minute so you can see some of the differences here in the HP-UX
operating system with respect to encapsulating the boot disk, where the volume should be, the volume names, some of the volume
usage types. And if you look towards the bottom of your slide there, you'll see HP has some more specific restrictions on things like,
types of disks, like simple formats for example, and hot-relocation spares.
Before placing the boot disk under VxVM control
What to do before you place the boot disk under Volume Manager control? If you've met the three requirements of encapsulation, the
slice 2, the two partition entries unused, and the 32 contiguous K at the beginning or end of the disk, 64,000 sectors (32K). You also
want to be aware of these two balloons on your slide depending on which operating system you're using. On Solaris, you want to
make sure that you have a statement called EEPROM use-nvramrc=true. That is a statement that you can set from the terminal
window level with that very same command, or if you're at level zero or run level zero on your Solaris box, you'll have an okay
prompt and you'll be able to type or print ENV and you'll see all of the EEPROM commands that you can use in the settings that
they're set to. You want to make sure that this setting is also set to true. And if you set something at the terminal window and then
reboot the box, it will automatically be set in the EEPROM. This is going to allow Volume Manager to use the nonvolatile RAN in the
boot PROM to be able to see that it can boot off the mirrored boot disk. So this is set defaults by default, if you set it to true it will
use that RAM to be able to figure out what it needs to do to boot the system off the other boot disk. On HP, you want to have
setboot-p primary path-a alternate_path, and you want to save the LVM volume group configuration, which is a lot like a disk group
configuration, vg00 which is the initial volume group containing your boot disk.
Placing the boot disk under VxVM control: Solaris
Here's a quick summary of placing the boot disk under Volume Manager control for Solaris. Now, the vxdiskadm command is available
to any operating system, and not just Solaris, but this one happens to be option two, encapsulate one or more disks. So you select
option two and you're going to be prompted for a series of questions. The device with the LUN, the name of the disk group, and this
is where I mentioned you have to give it your readily available name, like rootdg or osdg, sliced disk format, the boot disk cannot be
a CDS disk, and the size of the private region for that sliced disk. If you want a bigger than 32Meg to fall private region, this is where
you tell it. Now that command is actually going to call this CLI command vxencap under the hood. Then you have to reboot the
system, you do have to reboot, and it's going to run the following script and reboot automatically for vxvm-reconfig. That script is
going to be run by the encapsulation procedure and there's a reboot command inside that script. For the VEA, you follow the
instructions that are on your slide right there, which is the same basic effect.
Placing the boot disk under VxVM control: HP-UX
On HP, some of the files that are going to be touched and the commands that are going to be done are a little bit different. You can
see we have a vxcp_lvmroot and we also have a command called vxrootmir. If you look almost all the way down your slide, rootmir
looks a lot like vxdiskadm, mirror route or mirror something. So I've developed a little diagram right here that hopefully will help you
understand some of these different VX commands that encapsulate and mirror the boot disk. So we just mentioned vsdiskadm option
number two, which encapsulates the boot disk. There's another option, which is option six, which mirrors a boot disk. Now it doesn't
just mirror a boot disk, it can mirror any disk you want, but it has to assume that that disk already has volumes on that disk. If there

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

Lesson 9: Manage and Administer - Managing the Boot Disk with Storage Foundation - T... Page 4 of 6

are no volumes on a disk you're trying to use this option for, you get an error message and you'll have to go back and put volumes
on the disk. But I also have some asterisk here to show you some of the subcommands get called by the vxdiskadm under the covers
when you run it. For example, when you say vxdiskadm option two encap, you're running the vxencap under the hood for a disk on a
device, and that is going to fire off a lot of other function calls and scripts and types of commands that go ahead and encapsulate the
boot disk that eventually reboot the system or prompt you to reboot the system. Once the system comes back and you have an
encapsulated boot disk, that's a good time to mirror the boot disk. So we select option six for vxdiskadm, that calls a command under
the hood, which by the way, you can run on the command line yourself as well, which is called vxmirror. Now vxmirror is going to
prompt you for the original disk and then prompt you for the destination disk, you put both of these in the same line. The original
disk meaning the logical disk name for your boot disk, so OS disk or root disk or something like that, and then the destination disk,
which is the alt boot or the alternate or something like that, or mirror, alt mirror. So you already have to have your alternate disk
added to the disk group as an additional disk. So this literally mirrors everything on the original to everything on the destination disk.
So here's an asterisk which shows you some of the subcommands called by vxmirror. On the Solaris operating system only, and there
may be equivalents on other operating systems, we're going to run a command called vxbootsetup. That sets up the partition table to
have zero slice for root and one slice for swap and then it does whatever it needs to do to set up those slices and partitions. Then
what happens is vxmirror calls this command right here, vxrootmir. That command is actually on your slide, or the slide that I just
had up a minute ago for HP-UX, but it also happens in Solaris. And vsrootmir mirrors only your root volume, it doesn't do anything
else with any other partition or volume on the boot disk. It only mirrors your rootvol and nothing else, that may not be good enough.
Could you live with that only and not have to mirror anything else? Actually, yes you could. You could just mirror you rootvol, not
mirror any other boot disk volumes or partitions. And then if you lost your boot disk and you had to boot up on the other disk, you
would have a completely booted up root disk. The problem is you wouldn't have any services available. You wouldn't have anything in
var, usr, or opt or export, home, or anything else because none of that stuff had been mirrored. So what's the best practice? Mirror
the whole thing if you have plenty of space in the boot disk and you have plenty of space in the destination disk. There going to have
to be the same size anyway, or larger, you might as well let vxmirror do its thing. Vxassistmirrorswap, vxassistmirrorusr, vxassistvar,
opt, and anything else in the boot disk will also be mirrored. So not only does it set up the partition table and set up the disk to be
rebootable, it also mirrors each of the critical volumes on that boot disk to the destination disk. And now when this process is over,
what's a good thing to do for the destination disk? Test it, try to boot off the destination boot disk and see if you did the right thing
and see if everything went as expected. If not, and you can't boot off the alternate boot disk that you just made, you can always go
back to the original, wipe out the volumes and destination disk and redo vxdiskadm option six again. This is a very effective way and
easy way to mirror the entire boot disk to a blank destination disk in the same disk group. And by the way, you can do vxdiskadm
option six and vxmirror with any disk, it doesn't even have to be a boot disk. So let's get back to our lessons.
After placing the boot disk under VxVM control
So after placing the boot disk under Volume Manager control, these files, depending on what operating system you're dealing with,
get updated automatically by the vxdiskadm option six or the vxmirror commands. So the VTOC is updated and the original VTOC is
stored on the original boot disk in a file called VTOC, which you can always access and bring back if you need it. Also, there is
information now in your ETSI system related to the boot disk. And if you're on Solaris, there is updated information in your etc/vfstab
for the new device nodes that happen to be pointing to your boot disk volumes. So before you encapsulated the boot disk you had
dev/rdsk/c0t0d0s2, or s1, or s2, or s3, or s4, whatever it is. Now you're going to have dev/vxrdsk or dsk and the boot disk group
name and then your volume name, rootvol, swapvol, usr, var, or opt. So just like with the data disk and just like with the data
volume, we're going to use the Volume Manager device nodes in that file in the vfstab, not the original operating system specific
device nodes, same with LINUX and HP-UX. Okay, so now we've talked about how to encapsulate the boot disk. We've talked a little
bit about how to mirror the boot disk.
Creating an alternate boot disk
Let's talk about creating a third alternate boot disk.
Creating an alternate boot disk
I want to make sure that you know the difference between a live mirrored boot disk and an alternate boot disk. Some people call an
alternate boot disk an off-line or an emergency boot disk. The biggest difference is when you mirror the boot disk with vxdiskadm
option six or vxmirror, you have each volume mirrored onto two plexes and each plex represents one of the two disks. You first plex
represents the boot disk, the original one, your second plex represents your mirrored boot disk. This is going to tell you how to create
a third mirror in all the same volumes, break off that third mirror into volumes separately, separate the volumes from their mother
volumes and then store that physical alternate boot disk somewhere where you can use it for a rainy day. So this is different than a
situation where you're just test booting up on one disk on the other and keep the system running. The alternate boot disk is good in
the condition where the entire original site goes down and both your mirrored boot disk and your original boot disk go down with it.
So the alternate boot disk is a mirror of the entire boot disk just like your mirror boot disk, but this one you're going to break off,
breakaway and save for a rainy day. So this disk has to have pretty much the same requirements as your mirrored boot disk. It has
to be a free disk, or if it's not, you have to be ready to wipe it out. It's going to get a private and public partition and region. It has to
have contiguous space available, and it's going to get a mirror and data of all of your original boot disk volumes.
Creating an alternate boot disk: Solaris
So there are some specifics, based on the operating system that you might be running, on how to create your alternate boot disk.
Here's how to do it on Solaris. Notice we have the vxmirror command that I mentioned at the bottom of the slide.
Creating an alternate boot disk: HP-UX

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

Lesson 9: Manage and Administer - Managing the Boot Disk with Storage Foundation - T... Page 5 of 6

And here's how to do it on HP-UX. Also notice that we have a vxrootmir. We have a new command specific to HP called vxvmboot,
but the result is the same. You get an alternate boot disk, same data as your original that you can use in the case of an emergency.
Now how do you know you're going to have a problem with your original boot disk?
Boot disk error messages
Here are some error examples from various different error files and logs that you might see if you're having a problem with your boot
disk. So we see stale unusable message from vxconfigd. Almost always its vxconfigd, the demon in Volume Manager, is going to give
us these types of error messaging, and it's not always going to tell us exactly what to do, but it's pretty specific about where the
problem is happening. For example, that first message at least gives you information about the exact object in this case, rootvol-01,
that's having the problem. And you're trying to boot up on a stale plex in this particular case which you can't do. Hopefully, rootvol02, which is the second plex in the mirrored rootvol does not have a stale state, it has an active state and you would just be able to
boot up off that second plex by booting off the mirrored boot disk. At the bottom of the screen you'll see that sometimes it's not
always quite specific about its messaging. So you may have to dig a little bit deeper and get a message, like please boot from one of
the following disks, disk01 and the device information if you want to try to boot up on the other disk. But that is one scenario,
another scenario might be it doesn't even find your mirrored boot disk, it all depends on your situation. If you have updated your
EEPROM variable, like I described earlier, and you mirrored the boot disk with one of these types of methods then you should get this
type of message if it knows that you have a mirrored boot disk. Because that information is contained in the EEPROM as well as the
configuration database for your boot disk group.
Booting from an alternate mirror: Solaris
So this variable message set to true, that's the use-nvramrc variable which we already talked about. And if we do that, we have to do
a reset to the system, or basically a shut down and reboot to make that take effect. And then we should see in the devalias tree, vxand we should see the logical disk media name of the mirrored boot disk. This is how the system and the EEPROM know that there is
a mirrored boot disk available if the original boot disk is dead and you have to type in the name to be able to boot that second mirror.
This will happen usually at the okay prompter or on level zero on the Solaris machine. So you have to say boot VX- logical disk name
for the mirrored boot disk. And of course, you tested this, so it's going to work perfectly, right? Right.
Booting from an alternate mirror: HP-UX
How about an HP-UX? Here are some similar commands, you notice they are different in the EEPROM area that you would do on HP.
And if you know HP pretty well you should know what's going on here, you have interact with IPL, yes, no, or cancel. You have
basically the same settings that you would use on Solaris equivalents, and you should be able to boot up on the HP Volume Manager
mirrored boot disk.
Administering the boot disk
Okay, let's talk about making changes on the boot disk, or let's also talk about making what we call a boot disk snapshot.
Boot disk snapshot (Solaris and Linux)
So if you recall from earlier lessons it is possible in the later versions of the product to do a LUN-based snapshot or a hardware-based
snapshot. We talked about cloning disks. We talked about unique user disk IDs and that sort of thing. This command here,
vxrootadm, was introduced in Storage Foundation 5.0 to be able to allow an entire snapshot of the boot disk. As opposed to just
individually mirroring things, you can snapshot the entire boot disk and do volume mirrorings of each one of the boot disk volumes
with this command as well. The difference here is vxrootadm is going to take it one step further and actually make a snapshot of all
those mirrored volumes that you just created on the mirrored boot disk. So it's kind of like what we're just talking about, a vxmirror
or a vxdiskadm option six plus the additional variable, is the snapshot gets done at the end. So you're going to have separate
volumes, plexes, subdisks, and a disk that hold your boot disk or emergency boot disk snapshot. So if you look on your slide, it does
all of these things at the bottom of the screen automatically.
Growing the boot disk volumes (Solaris only)
This is a good opportunity to talk about growing the boot disk volumes because this is one way that you can grow the boot disk
volumes without having to actually grow the volumes on a live production system with its boot disk. If you want, you can snapshot
the boot disk and then grow those volumes on the emergency snapshotted boot disk. And we talked about how to do that here at the
top of your slide with the vxrootadm grow variable. So you can see we're taking each one of those volumes, rootvol and swapvol, and
growing them to those particular sizes, 15Gig and 8Gig.
Removing the boot disk from VxVM control
Okay, so the last thing to discuss is how to un-encapsulate the boot disk or remove the boot disk from Volume Manager control.
Removing the boot disk from VxVM control: Solaris
Now in case you want to ask the question, why do I need to know about this, the reason you need to know about this is if you

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

Lesson 9: Manage and Administer - Managing the Boot Disk with Storage Foundation - T... Page 6 of 6

upgrade Storage Foundation or you upgrade the operating system that it lies on, either one of those things are going to require you
to un-encapsulate your boot disk and then re-encapsulate your boot disk after the upgrade happens successfully. Now, when you
upgrade and you un-encapsulate the boot disk, you're also going to have to un-mirror your boot disk. So if the boot disk has mirrored
volumes, rootvol, swapvol, usr, var, opt, stand, or whatever your volumes are, you have to break those mirrors before you unencapsulate the boot disk. You don't necessarily have to remove all the mirrors or destroy them. You can leave the mirrors on the
secondary boot disk or the mirrored boot disk and then basically un-encapsulate your boot disk, upgrade, re-encapsulate, and then
reattach each mirror. But sometimes what people like to do for ease of management is just break the mirror, get rid of those mirrors,
un-encapsulate the boot disk, upgrade, re-encapsulate, and then re-mirror the boot disk immediately after that. It depends on the
size of your boot disk, it depends on the time it's going to take to mirror that boot disk. But it's a lot easier if you have the time and
you have some space to be able to mirror it, it's an easier method to do what I just suggested. Either way, probably the best
command to un-encapsulate the boot disk is called vxunroot. So just like I said, vxunroot doesn't like mirrored volumes at all. It's
going to give you an error if you have a mirrored volume anywhere in root, swap, usr, var, opt, in export home or home. So it tells
you have to unmirror all of those volumes before you run vxunroot. Also, if you want test and see if you can still boot the original
boot disk on the physical partitions that were there before you un-encapsulated, maybe that's a good opportunity to try to do that.
Because vxunroot will take the private, public, and all those related Volume Manager regions and objects off of the disk and leave
only the data and restore the original Solaris partition table. So you've got some good time to test and make sure you can reboot off
that disk.
Removing the boot disk from VxVM control: HP-UX
Now if you want to look at HP-UX, there may be a couple of different commands like you see on this slide here, but the general result
and process is the same. You go back to having an HP disk physically that has no Volume Manager objects on it, a good time to test
and make sure you can boot up.
Removing the boot disk from VxVM control: Solaris
On the bottom of this slide on the last bullet, change the size or location of the private region, that's also a good opportunity to do
that in case you want a larger private region to hold more configuration database objects inside it. You can't do that, except if you
reinitialize or re-encapsulate the disk, so that's another opportunity to update that as well.
The vxunroot command: Solaris
And there's some screenshots and some examples of vxunroot and the commands leading up to vxunroot. So in that first one, we're
doing a vxprint. In the second step we're making sure that we remove the mirror from all the volumes from that second disk. So in
this case, we're actually removing the mirror, not just attaching it but we're removing all the mirrors from rootvol, swapvol, usr, var,
opt, and all the other volumes and then getting rid of those mirrors. So we will end up with a free alternate boot disk. Then we run
vxunroot to un-encapsulate the original boot disk. And then, of course, we can do our upgrade and then re-encapsulate after the
upgrade is done.
Lesson summary
There's a lot more information about upgrading both the operating system, Storage Foundation, or both at the same time in your
product documentation for Storage Foundation 5.1. I hope you've enjoyed this training. I hope you've enjoyed the lessons and I wish
you the best of luck using Symantec products. Thank you very much.

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

You might also like