I'm looking for some definitive, thorough documentation on HP-UX LVM
that goes way
past the basics.

I have recently found myself with some complex LVM issues and the HP
documentation
is incomplete and inconsistent (I have the "Chapter 16" pdf).

Unfortunately, as with the proc structure, HP seems to have removed the
LVM data
structures from the distributed headers, and the error messages from
commands
are often misleading. HP support tends to give equally conflicting and
incomplete
data depending on who answers the call.

HP training is too costly and my recent employers won't fund it, nor do
I have access
to a sandbox server. In any event, I'd rather understand or have
supported procedures
rather than simply basing actions on something that "seems" to "work."

Please reply in the group.

> I have recently found myself with some complex LVM issues and the HP
> documentation

Can you give a sample ?
See here: http://docs.hp.com/en/B2355-90950/B2355-90950.pdf
In general, it's better to avoid using sam for disks management.
I found LVM very logical and easy to use.

Create a filesystem on a new disk take only few commands (I believe it's not a secret for you):
ioscan
pvcreate
mknod
vgcreate
lvcreate
newfs
vi /etc/fstab
mount
Et voilà !

To add a new disk to a vg:
pvcreate
vgextend

To mirror a filesystem:
lvextend -m 1

To increase a FS without unmounting it:
lvextend
fsadm -b

To move data from a disk to another:
pvmove

.....

Thanks for a good post.

I am coming from AIX and Linux background, this is very helpful!

Alain wrote:
> > I have recently found myself with some complex LVM issues and the HP
> > documentation
>
> Can you give a sample ?
> See here: http://docs.hp.com/en/B2355-90950/B2355-90950.pdf
> In general, it's better to avoid using sam for disks management.
> I found LVM very logical and easy to use.
> ...

Actually, http://us-support3.external.hp.com/iv/data/documents/
DE_SW_UX_swrec_EN_01_E/LVM.pdf

is a much more informative document, but it still doesn't answer a
lot of my questions.

For instance, I recently had occasion to want to do the equivalent of
a vgexport of only one mirrored physical volume to make some
alterations.
Unfortunately there doesn't appear to be any simple way to do this.
lvreduce followed by vgreduce leaves pointers to the original mirror in
the
lvm header of the disk, so you can't vgimport the drive. It appears
that
the only way to do this would be to edit the disk header to remove the
references to the lv mirrors and the other pv, but hp doesn't seem to
include the header files for these structures in the binary release of
HP-UX 11i. Also, even the document above is quite terse and doesn't
explain much of the underlying interfaces.

Actually, this seems to reflect a change in HP's attitude toward
customers
which began in the 1990s, a sort of "dumbing down" of the documentation
and an incresing secrecy about internals. This is reflected for
instance in
the way the proc structure was removed to discourage walking the kernel
structures. This was made worse by the fact that the pstat() interface
was
limited to just the same information already available from the command
line.

Anyone who has ever administered an Oracle database server on HP-UX
will appreciate what I mean here. There is no supported means to
identify
which processes are attached to a given shared memory segment, so
often DBAs and sysadmins are forced to reboot the server to clean up
stale
shared memory segments instead of merely killing an errant process or
two.
This involves a significant amount of work and often a costly service
outage,
hardly the high availability HP's marketing touts.

It is not particularly hard to program a tool similar to fuser to do
this, but the
only way to do so on HP-UX is to reverse engineer the kernel structures
which is hardly what one wants a production environment depending on.

icculus wrote:
> For instance, I recently had occasion to want to do the equivalent of
> a vgexport of only one mirrored physical volume to make some
> alterations.
> Unfortunately there doesn't appear to be any simple way to do this.
> lvreduce followed by vgreduce leaves pointers to the original mirror in
> the
> lvm header of the disk, so you can't vgimport the drive. It appears
> that
> the only way to do this would be to edit the disk header to remove the
> references to the lv mirrors and the other pv, but hp doesn't seem to
> include the header files for these structures in the binary release of
> HP-UX 11i. Also, even the document above is quite terse and doesn't
> explain much of the underlying interfaces.

Hi icculus, what were you trying to do with your disk? What were the
'alterations'? If you just wanted to replace it you could have done a
vgcfgbackup beforehand and then restored the VG setup back to the
replacement volume with vgcfgrestore and then re-synced.
I've worked with LVM for a few years now and haven't really found it to
be limiting in any way. It is much more straightforward and flexible
(to me) than Solaris disksuite e.g.

JohnK

JohnK wrote:
>
> Hi icculus, what were you trying to do with your disk? What were the
> 'alterations'? If you just wanted to replace it you could have done a
> vgcfgbackup beforehand and then restored the VG setup back to the
> replacement volume with vgcfgrestore and then re-synced.
> I've worked with LVM for a few years now and haven't really found it to
> be limiting in any way. It is much more straightforward and flexible
> (to me) than Solaris disksuite e.g.

Well, DiskSuite isn't really intended to do quite as much as HP-UX LVM.
In any event, I'm not sure it made sense for HP to self-virtualize the
root
just to prove it could be done. I've had the argument for a decade
with HP
that mirroring the boot drives should be done in hardware, because the
only
functionality that makes sense is to mirror the drive, not the
individual volumes.
Indeed, this is the case in almost all HA environments. Very few
people ever
mirror anything except to gain availability, and that inevitably
applies to hardware.
If you want improved read performance, you probably want better
hardware anyway.

It seems kind of silly to have the first three contiguous partitions on
a disk LVM
when you can't do anything with them that you can't do with a
traditional hard
partition. All it does is to make systems administration more
convoluted by
introducing a useless level of indirection.

However, this discussion is getting far off track from my original
posting. I am
not a HP-UX newbie. Indeed, I had access to a source license for 9.xx
and had
internal access later on. The modifications I wanted to perform
involved some
significant changes to the root volume group on newly (mis) installed
servers.
It's a sordid tale, but the point is that I wasn't able to be there to
install the OS
the way I wanted, and I wanted to change it with minimal effort in an
environment
where there was not yet any functional network and the servers had no
local
tape drives. In other words, an enterprise environment. BTW, when I
say no
network, that also includes the planned FC SAN.

In any event, I was eventually able to resolve the issue with help from
HP support
without having to reinstall everything but I am not comfortable with
this "special
sauce" approach to systems administration. In other words, what the
support
consultant told me to do "worked," but I don't have any documentation
to tell me
why it worked or whether it might work on the next release. Indeed, it
seemed
kind of scary in assuming that LVM would figure out how to do the right
things.
Either LVM is a lot smarter than we have been led to believe or else I
have
witnessed a miracle, and as an experienced sysadmin, I don't believe in
miracles.

This still doesn't answer my question, though. MirrorDisk-UX is with
us for the forseeable
future, and I want to know how to manipulate it as *I* want, not just
in a few ways
that some HP developer *assumed* I would want. After all, whose
computer is it anyway?

There's a third party manual out on the 'net which purports to be from
a course in HP-UX
"LVM Internals," a course HP doesn't openly offer, yet the "free
downloads" (DRM .pdfs
that you can't even print) look like nothing but a less comprehensive
rehash of the HP
document I posted the link to here. Additionally, the price is over
$900 US which seems
utterly absurd.

Until HP wises up and puts hardware RAID1 disk controllers in all of
their servers for the
boot drives, we'll have to struggle with their silly notions of HA.
The amazing thing is that
it's an option in their low-end HP9000 servers, but not in the mid to
high end ones unless
you choose to boot off an EVA or XP array which opens a whole other can
of worms with
respect to the chicken and the egg.

Maybe while they're at it, they'll also figure out that it might be
good to provide a memory
subsystem that can support more than half the configurable number of
CPUs without
being starved for bandwidth.

BTW, Solaris DiskSuite isn't as flexible as HP-UX LVM, but it's a heck
of a lot easier to
do commonly useful things with it once you get the hang of it and
figure out the obscure
metadata stuff. I once cloned the OS and software install for a whole
rack full of Sun
SPARC Solaris servers in less time than it would take to begin to
figure out how to
set up an Ignite-UX server (though I have done that in the past and it
was great for
cloning hundreds of workstations, it was almost more trouble than it
was worth for
less than a dozen servers).

HP has left their roots as an engineering company by and for engineers,
and it has
hurt them, at least at the S800 level.

magawake@gmail.com <nganta@gmail.com>:

> Thanks for a good post.
>
> I am coming from AIX and Linux background, this is very helpful!

Okay. In that case, please note, that the LVM syntax on
Linux is VERY much identical to what you'll find on HP-UX.

Alexander Skwar
--
"Why can't we ever attempt to solve a problem in this country without having
a 'War' on it?" -- Rich Thomson, talk.politics.misc

icculus wrote:
I've had the argument for a decade
> with HP
> that mirroring the boot drives should be done in hardware, because the
> only
> functionality that makes sense is to mirror the drive, not the
> individual volumes.
???
On our old servers without SAN connectivity, all LVs are mirrored. Boot is possible on this alternate disk.
In case of a disk failure, server continue to work. What you have more with hardware mirroring ?

> BTW, Solaris DiskSuite isn't as flexible as HP-UX LVM, but it's a heck
> of a lot easier to
SolarisVolumeManager and ZFS now. DiskSuite is discontinued (we are in 2006 not 2000).
SVM and LVM are both easy to use.
HP have signed a strong partnership with Veritas (why reinvent the wheel).See new VxVm, Vxfs new features.

What's is so bad in the initial install of your server ?
Why not connect an external tape drive to this server, make a make_tape_recovery and reinstall OS this way ?
It's fast and easy.
Like that, you use a supported HP procedure.

Alain.