1. Introduction

1.1. JUST DO IT ALREADY!!!

VxMake is certainly the best way to build things. You know what you want, you know how you want it, and you want it done right. Right? What if you don't k now exactly what you want. Even worse, what if you don't care! Thats where vxassist comes in. You can directly build volumes without building the sub-obje cts and give vxassist just as much or little info as you like. The trade off? The less you tell vxassist the more it decides for you. This can be really b ad. Kinda like telling your kids to put away the groceries without telling them specifically where to put things... you might find places to put things in your kitchen you didn't know were there.

There is a time and place for everything. Often this actually has to do with what you're using and how much you care. On a Sun A5200 you might want to put only one volume per disk. You might want each disk in Array A to be perfectly mirrored to a disk in the same slot in Array B. But you might also be using a D1000 where you don't care what goes where. For these reasons you may want to carefully decide which tool you should use for building. We'll talk about a number of reasons and ways in which to use the tool. But remember that analogy of the kids in your kitchen, it's pretty close to letting vxassist decide whe re to dump all your data.

1.2. VxAssist: Why it's the Lazy Way

This course directly correlates to its sister course "Volume Kreation: The VxMake Way". There we saw that we can acheive a huge ammount of control over our volume creations by building each volume object by object untill we have a well humming bit bucket for our data to live. But all too often we just need the data quickly, or we don't care about the nitty gritty details, or, more likely, we simply don't have the time neccisary to broad over the details of each volume. What's needed is a simple, quick method of creation. Not to mention the fact that when we build each of our objects by hand we leave ourselves open to accidental errors which may be difficult to catch. Chief ammong all other reasons this is why vxAssist should be carefully considered as an alternative (if used properly!). A simple example of the dangers of manual creation: when you create a volume from the ground up you'll quickly realize the need for a shell that has command history (such as the Borne Again SHell). And you'll be humming along recalling the last command, changing the neccisary bits and building along. At some point, I guarrenty you'll accidently name an object wrong doing this. And that little innocent typo, that may or may not cause an error, will cause you headaches. But, with that said, there are times and places for both. For instance, if you simply want a plex to use you'll need to vxMake it yourself, and therefore you need a good foundation in using it. Furthermore, you can not properly understand the Volume Manager without having a good solid background in vxMake.

But what makes VxAssist such a "lazy" method. It's the fact that you can, in one line, tell the Volume Manager to create you a, say, 20G volume on disks A, B, and C, and bang! with only that information you've got a functional usable ready for filesystem volume. Or you could even go so far as to only tell VxAssist to create you a 20G volume named "newvol" and not even tell it which disks to use, it'll just find the space in it's configured disks and go off on it's merry way. Whatever you lack to tell VxAssist about the volume your creating it will descide for itself, but as we mentioned before, the less you descide the less control you have and the more likely you are to get something you didn't want. In the examples we'll go through below we'll build far more complex volumes than we did in the VxMake course, but we'll put heavy emphisis in using as much information as we can to get the job done right, the first time. Let's hop into it.