Showing results for 
Search instead for 
Did you mean: 

general discussion why root volume group

Go to solution
Trusted Contributor

general discussion why root volume group

Hi all,

I've been asked to justify why I'd want to keep application binaries / data / configs etc on a seperate volume group other the root.

I've come across a situation where root has been sized at 150gb single lun and the only other volume group is a lu configured for database data.

Reasons I'd say to keep seperate,

allows greater flexibilty when upgrading root or even the apps
seperating backup data for system and apps
restoring systems is quicker
migrating systems is more manageable

the list can go on - what idea's do other people have to justify a seperate application VG?


Chris Lawrence
Pete Randall
Outstanding Contributor

Re: general discussion why root volume group


You've already touched on what I consider to be the most important reason when you mentioned separating backup data.

The primary recovery tool in HP-UX is Ignite and Ignite is designed to recover your root volume group, including your backup software which is, of course, in /opt. You can force Ignite to backup other VGs and data but remember that Ignite is really just a tar backup with some boot headers stuck on the front. Would you trust your company's lifeblood data to a tar backup? If that's all you had available then I guess the answer would have to be yes, but the vast majority of us have invested in backup packages to protect our data. Those, combined with Ignite backups (multiple ones are a good idea) offer the best recovery possibilities.


Tim Nelson
Honored Contributor

Re: general discussion why root volume group

The points you list are all good.

Keeping root on its own is a best practice for all those reasons.

You did not specify whether or not this 150GB LUN was divided into a number of segregated lvols.

If they are, then the discussion is driven towards performance. A busy application may make it difficult to monitor or troubleshoot via the OS, the OS disk may become so busy that the OS becomes unresponsive as well.

If they are not, then the discussion is as follows.
The size of the root partition/volume directly effects recovery. The length of time for image creation, the lenth of time to recover that image and the success of the recovery are all directly related.

Also, there is some discussion about whether or not to locate the root partition on SAN based storage.

One argument is that if there are SAN issues, you will have no OS to troubleshoot with.

The other arg, is consolidation and ease of storage management.

One trade off for the other. The cost of two internal scsi disk is pretty minimal.
James R. Ferguson
Acclaimed Contributor

Re: general discussion why root volume group

Hi Chris:

You have enumerated the principal reasons for not putting application data on the root volume group (vg00).

You could also add that this makes cloning systems (for testing or disaster recovery) easier, too.

I'd point out that disk is cheap and plentiful compared to years ago and therefore a 150GB physical volume that is only 50% used isn't a great waste!


Trusted Contributor

Re: general discussion why root volume group

Thanks all for the information,

the 150gb volume has been carved into seperate LV's and for instance oracle binaries / patrol binaries / system management tools such as asset management and the like live on these LV's which some are specific for the system backed up .....

I've always liked keeping the root volume just for os specific then add an apps volume for all the binaries and if necessary a data volume for customer data / user application data etc ......

I find that migrating and decommissioning systems is much easier using this method but as always "there are several ways to skin a cat"

just for information I've also has a single volume group configured for all application data, config files, user home, binaries specific to one app which is perfect for upgrades and migrations ....

Muchas ....

Michael Steele_2
Honored Contributor

Re: general discussion why root volume group


The only other advantage to the advantages mentioned above that I see ommited is a performance monitoring advantage. It can be very hard to isolate problem file system processes if the application and O/S are all within the same VG and using the same disk(s).

With sar you can isolate a disk bottleneck. Using 'pvdisplay' you can isolate the lvols residing on the disk. If you have a busy file system that now needs to be split apart because it is very busy taking a lot of read/write hits, then you can do so if you've made unique vgs and lvols.

But if the application and O/S are all in vg00, all residing on one disk, good luck. It's nearly impossible because sar will only report the one 'big' disk as the problem.
Support Fatherhood - Stop Family Law
Steven E. Protter
Exalted Contributor

Re: general discussion why root volume group


My take is system reliability.

If logs live in /var and its a separate mount point, and other important file systems are segmented, then the filling of a single file system will not stop the entire system.

Lets say Oracle gets hung up and tries to cut an extent larger than available space. In your scenario though size of root might delay consequences, the end result is the system halts. If oracle is in a separate file system you at least have a running system on which to clean up the mess.

That's why contrary to a Linux style approach, we have file systems set up.

Here is a real life Linux example that proves the point.

There was a bug in a mysql backup script I have run every night. Without too much detail, the bug caused backups to multiply in size.

First time that happened, backups were sitting in /var and the entire system halted.

I moved the backups into a file system named /backups and when the bug manifested itself again, /backups was full but the web services were still up and running.

So the approach you suggest lets sloppy systems administration extend time between crashes, but guarantees that a full file system will be fatal and require down time to correct.

Steven E Protter
Owner of ISN Corporation
Wim Rombauts
Honored Contributor

Re: general discussion why root volume group

I can give two reasons to split up your volume groups.

1) If I am not mistaken, HP-UX uses an IO queue per LUN-path (at least in 11i v2). When you split your system over multiple LUN's, IO throughput will be significantly higher. But you can still gather all the LUN's in one single large VG of course ...

2) I recently started upgrading servers from 11i v2 to 11i v3. My approach : Cold install the OS, copy over some configuration files, import the volumegroups with software installations and database on it and run. I could not have done this last step when all my software and the database was installed on the root volumegroup. I should have had to restore software and recover the database, a very lengthy procedure.

The same is true for when you move to new hardware : with a small root volumegroup, Ignite recovers your system in a matter of tens of minutes, an hour maybe. How long does it take to read 150GB from tape ?
RC Park
Frequent Advisor

Re: general discussion why root volume group

I hate to be simple, but here's one: they are free. By that, I mean you really don't spend any money on a new VG. You do on the LUN, and if you're like most of us out there, you're no longer focused on local storage, but you don't mention where your disk sources (local/SAN). All previous answers are valid and good as I've either experienced what was discussed or agree in principle. What struck me about this thread topic is that you felt compelled (by your manglers/peers) to justify SA best practices; would you mind sharing your pain point? What is driving someone to suggest that you simplify when, in your own words, you have many reasons NOT to? So, not wanting to repeat what others have contributed, I'll simply add that given HP's implementation of LVM, both in v2 and v3, you're given sufficient controls over specifics of the volume group that give you some ability to distinguish one group from another. A one-size-fits-all approach can work, but you'll never be able to optimize for a specific app. The more control you need to maximize the OS's ability to perform, the better off you are with separate vg's.