Re: LVM usage

[van Sleeuwen, Berry]

Actually, those were just examples. The Samba and TSM guests have the biggest 
LVM filesystems. We have a quite a few linux guests, most of them use LVM. 
Ranging from a small webserver to a couple of oracle database machines with 
LVM's up to 40G.

I don’t think it matters if we are talking zVM guests or native linux machines. 
The usage of LVM depends on what storage is available. Mainframe DASD typically 
doesn't have the large disksizes so the smaller disks require LVM or any other 
solution that glues disk together. But even when the storage solution has the 
required sizes available there can be other reasons for using LVM. We use LVM 
primarily for two reasons. First of all to glue smaller disks together and 
secondly to spread IO onto multiple disks.

We use LVM only for user filesystems. The system data remains on non-LVM disks. 
Most of the user data is located in /srv that is located in an LVM.

Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen,
Berry van Sleeuwen

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Sergey 
Korzhevsky
Sent: Monday, October 05, 2015 5:23 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: LVM usage

Stories about TSM and Samba are great, but this is one installation for the 
site and we are speaking in terms of z/VM, right?
This e-mail and the documents attached are confidential and intended solely for 
the addressee; it may also be privileged. If you receive this e-mail in error, 
please notify the sender immediately and destroy it. As its integrity cannot be 
secured on the Internet, Atos’ liability cannot be triggered for the message 
content. Although the sender endeavours to maintain a computer virus-free 
network, the sender does not warrant that this transmission is virus-free and 
will not be liable for any damages resulting from any virus transmitted. On all 
offers and agreements under which Atos Nederland B.V. supplies goods and/or 
services of whatever nature, the Terms of Delivery from Atos Nederland B.V. 
exclusively apply. The Terms of Delivery shall be promptly submitted to you on 
your request.

LVM usage - Thank you very much!

[Sergey Korzhevsky]

It was very valuable for me, thanks to all of you!



WBR, Sergey

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: LVM usage

[Grzegorz Powiedziuk]

I would like also to mention that when it comes to LVM, it makes much more 
easier to manage such systems especially with FCP involved.
Imagine that you break your multipath config for example and you lose your 
“mpath” names. If you have LVM, you can still boot. LVM will just scan all your 
paths, pick the first (or last - can’t remember) available with a proper label 
and use that to bring up the vg and logical volumes. Without LVM, you will have 
to a lot of work to get system online again. 
There were few others scenarios which I can't remember now, when LVM saved me 
big time or made things a lot easier. 
 
Gregory Powiedziuk



> On Oct 6, 2015, at 3:34 AM, van Sleeuwen, Berry <berry.vansleeu...@atos.net> 
> wrote:
> 
> Actually, those were just examples. The Samba and TSM guests have the biggest 
> LVM filesystems. We have a quite a few linux guests, most of them use LVM. 
> Ranging from a small webserver to a couple of oracle database machines with 
> LVM's up to 40G.
> 
> I don’t think it matters if we are talking zVM guests or native linux 
> machines. The usage of LVM depends on what storage is available. Mainframe 
> DASD typically doesn't have the large disksizes so the smaller disks require 
> LVM or any other solution that glues disk together. But even when the storage 
> solution has the required sizes available there can be other reasons for 
> using LVM. We use LVM primarily for two reasons. First of all to glue smaller 
> disks together and secondly to spread IO onto multiple disks.
> 
> We use LVM only for user filesystems. The system data remains on non-LVM 
> disks. Most of the user data is located in /srv that is located in an LVM.
> 
> Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen,
> Berry van Sleeuwen
> 
> -Original Message-
> From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Sergey 
> Korzhevsky
> Sent: Monday, October 05, 2015 5:23 PM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: LVM usage
> 
> Stories about TSM and Samba are great, but this is one installation for the 
> site and we are speaking in terms of z/VM, right?
> This e-mail and the documents attached are confidential and intended solely 
> for the addressee; it may also be privileged. If you receive this e-mail in 
> error, please notify the sender immediately and destroy it. As its integrity 
> cannot be secured on the Internet, Atos’ liability cannot be triggered for 
> the message content. Although the sender endeavours to maintain a computer 
> virus-free network, the sender does not warrant that this transmission is 
> virus-free and will not be liable for any damages resulting from any virus 
> transmitted. On all offers and agreements under which Atos Nederland B.V. 
> supplies goods and/or services of whatever nature, the Terms of Delivery from 
> Atos Nederland B.V. exclusively apply. The Terms of Delivery shall be 
> promptly submitted to you on your request.

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

LVM usage

[Sergey Korzhevsky]

Hi All,

Could you, please, explain me a real usage of the LVM in the server
environments with z/VM or whatever.
Do you really need to "online" expand your "opt" or "home" directory which
is worth to have additional layer in disk access?
Moreover,  databases already have such functionality
(tablespace/containers), so they don't need LVM.

Thank you.



WBR, Sergey

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: LVM usage

[Nix, Robert P.]

Do you really need it? Yes! We use it all the time to do just that, and
did especially on zLinux, because the physical DASD devices were fixed in
size, and relatively small. We also did it because it allowed us to
non-disruptively move between DASD, using the pvmove command. This allowed
us to remain up through several major disk subsystem replacements, both on
the zSeries boxes and on Intel based Linux servers. Anything that avoids
downtime for my users, and masks infrastructure changes from them is a
³Good Thing (tm)².
--
Robert P. Nix | Sr IT Systems Engineer |  Data Center Infrastructure
Services
Mayo Clinic| 200 First Street SW | Rochester, MN 55905

507-284-0844 | nix.rob...@mayo.edu





On 10/5/15, 7:56 AM, "Linux on 390 Port on behalf of Sergey Korzhevsky"
 wrote:

>Hi All,
>
>Could you, please, explain me a real usage of the LVM in the server
>environments with z/VM or whatever.
>Do you really need to "online" expand your "opt" or "home" directory which
>is worth to have additional layer in disk access?
>Moreover,  databases already have such functionality
>(tablespace/containers), so they don't need LVM.
>
>Thank you.
>
>
>
>WBR, Sergey
>
>--
>For LINUX-390 subscribe / signoff / archive access instructions,
>send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
>visit
>http://www.marist.edu/htbin/wlvindex?LINUX-390
>--
>For more information on Linux on System z, visit
>http://wiki.linuxvm.org/

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: LVM usage

[Rick Troth]

Two great responses from Bob and Berry. Here's my LVM story too.


On 10/05/2015 08:56 AM, Sergey Korzhevsky wrote:
> Could you, please, explain me a real usage of the LVM
> in the server environments with z/VM or whatever.

I was introduced to LVM by colleagues.
Since then, I have used it increasingly.
It is the central facilitator for most of my storage needs.


> Do you really need to "online" expand your "opt" or "home" directory
> which is worth to have additional layer in disk access?

Online resizing works very well.

For me, there is no additional layer
because I use LVM without partitioning.
Where possible, I discard the partitioning "layer" in favor of LVM.
In other words, where it can be done, I stamp the whole disk as a PV
rather than stamping one or more partitions.

Recent discussion exposes a bug in recent LVM utilities where there is
some sad confusion between partitioned and unpartitioned physical
volumes. Other than that, LVM is everything partitioning wanted to be if
partitioning grew up.

Hard numbers exposing the insertion loss from use of LVM would be great.
Best practice recommends use of LVM for the administrative advantage.


> Moreover,  databases already have such functionality
> (tablespace/containers), so they don't need LVM.

There are many places we see functional overlap. Not only databases, but
also ...

 + EVMS combined multipath support with volume management, yet LVM won

 + newer filesystems combine volume management with the FS, and LVM is
losing

There is no one size fits all, so you'll want to dig-into the
capabilities of LVM to answer your own needs. But LVM is an excellent
solution with fewer layering violations than the overlaps mentioned
here. (It fits the Unix rule of do one thing and do it well.)

-- R; <><

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: LVM usage

[van Sleeuwen, Berry]

Hi Sergey,

Our Samba server has a 180G filesystem on Model 9 DASD. It's obviously an LVM 
just to get to that size. Our TSM server has a 3.2TB staging filesystem, this 
guest has 72 model 54 disks to build the LVM filesystem.

Striping within LVM can spread IO onto multiple disks.

Databases might indeed have the possibility to group disks but most 
applications don't have that option. DASD volumes are usually not large enough 
to hold the data. Especially model 3 and model 9 are too small by itself most 
of the time.

While databases might have similar features to group disks into larger 
tablespaces and/or to spread IO, implementation (and therefore advantages) 
depend on the database in question. Some implementations might disregard the 
s390 features and result in poor performance and/or increased costs.

Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen,
Berry van Sleeuwen

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Sergey 
Korzhevsky
Sent: Monday, October 05, 2015 2:56 PM
To: LINUX-390@VM.MARIST.EDU
Subject: LVM usage

Hi All,

Could you, please, explain me a real usage of the LVM in the server 
environments with z/VM or whatever.
Do you really need to "online" expand your "opt" or "home" directory which is 
worth to have additional layer in disk access?
Moreover,  databases already have such functionality (tablespace/containers), 
so they don't need LVM.

Thank you.



WBR, Sergey

--
For LINUX-390 subscribe / signoff / archive access instructions, send email to 
lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit http://wiki.linuxvm.org/
This e-mail and the documents attached are confidential and intended solely for 
the addressee; it may also be privileged. If you receive this e-mail in error, 
please notify the sender immediately and destroy it. As its integrity cannot be 
secured on the Internet, Atos’ liability cannot be triggered for the message 
content. Although the sender endeavours to maintain a computer virus-free 
network, the sender does not warrant that this transmission is virus-free and 
will not be liable for any damages resulting from any virus transmitted. On all 
offers and agreements under which Atos Nederland B.V. supplies goods and/or 
services of whatever nature, the Terms of Delivery from Atos Nederland B.V. 
exclusively apply. The Terms of Delivery shall be promptly submitted to you on 
your request.

Re: LVM usage

[Rick Troth]

Summary:
Think about how and where (and by whom) the storage is to be managed.
What is the pattern? YES, I am beginning to see a pattern as we discuss it.


On 10/05/2015 11:23 AM, Sergey Korzhevsky wrote:
>  Could you tell me some details, because it is not obvious for what type
> of services you are actually using LVM? Is this Websphere, databases,
> Samba, log storage, custom application with a lot of data, anything else?

Oh my personal systems, I use LVM for all filesystems except the boot
volume.
Once the system is up, the boot volume is out of the picture.
(I maintain the kernel and related files by copying them from /boot to
wherever they physically reside. But that's just me.)

Last time I used LVM at work, it was primarily WAS, but also included
Tomcat and/or IHS (IBM's spin on Apache) and DB2 (UDB). Backing store in
that context was primarily SAN. Note what Robert Nix said about using
ECKD for the backing store: you can grow your volume groups (VGs) by
adding physical volumes (PVs).

As Scott just noted (overlapping email) SAN volumes tend to be much
larger, but even there it's common to add a PV to a VG as the needs grow
and the LVs grow.


> Stories about TSM and Samba are great, but this is one installation
> for the site and we are speaking in terms of z/VM, right?
> Maybe i need to ask additional query: do you use LVM no matter what?
> For example, if you need to create one linux (maybe a bunch of them)
>  with webserver (it is relatively small), will you use LVM anyway?

Can't say that I use LVM no matter what, but for my "big storage" it is
first choice. Always.

You mention web server as an example.
Common use of web servers today is to sit between your users and your
applications. For that, you don't need "big storage". So for a web
server, I'd let VM do your volume management, doling out minidisks to
such a guest. Little value in LVM there. (This is assuming you have VM
behind the server. For anything *not* virtual, go with LVM.)

But IF you have ANY concerns that your web servers will need more file
storage, go with LVM. It won't hurt. Even without hard numbers,
experience indicates that the insertion loss with LVM is no issue.

Three strikes in favor of LVM: big storage, a guest with storage growth
needs, anything not virtual.


> DASD now can be 27 and 54GB, which is plenty of space for normal
> application use (except DB). Is it not enough for your needs?
> Maybe you initially allocate as little space as possible (say 1GB) and
> then add later?
> Basically, what is the pattern? :)

It's not a question of adequacy or sufficiency. It's a question of
management.

I am seeing a pattern ... a need to differentiate how much you have
versus how you will manage it.

Am loving the conversation. I hope this helps.

-- R; <>

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: LVM usage

[Nix, Robert P.]

We use LVM on EVERY server we build, for all of the disk, with the
exception of /boot, and ASM disks for Oracle. Everything else is beneath
LVM. Why? Because the users never estimate their space needs sufficiently,
so there is always a need to add. Because disk subsystems seldom last the
life of a system, so we are constantly being asked to move data to a new
subsystem, and with LVM, we can do this transparently and without an
outage to the user. Because other things grow over time, and while we
include some ³buffer² space, we also don¹t like our disk going unused, so
we run close to the actual size needed. Because the root filesystem
shouldn¹t be maxed out by a run-away user¹s home directory, /tmp file, or
/var file, and with LVM we can isolate these things, without having to
allocate multiple disks.

LVM lets you make little disks out of big ones, a.k.a z/VM minidisks, and
it also lets you make big disks out of little ones. It lets you stripe and
mirror without too much of a headache. It¹s a nice, useful, lightweight
management layer that takes some of the guesswork out of disk management,
and keeps it all within one tool.
--
Robert P. Nix | Sr IT Systems Engineer |  Data Center Infrastructure
Services
Mayo Clinic| 200 First Street SW | Rochester, MN 55905

507-284-0844 | nix.rob...@mayo.edu





On 10/5/15, 10:23 AM, "Linux on 390 Port on behalf of Sergey Korzhevsky"
<LINUX-390@VM.MARIST.EDU on behalf of s_korzhev...@iba.by> wrote:

>Hi Rick,
>
> Could you tell me some details, because it is not obvious for what type
>of services you are actually using LVM? Is this Websphere, databases,
>Samba, log storage, custom application with a lot of data, anything else?
>
>Stories about TSM and Samba are great, but this is one installation for
>the site and we are speaking in terms of z/VM, right?
>Maybe i need to ask additional query: do you use LVM no matter what? For
>example, if you need to create one linux (maybe a bunch of them)  with
>webserver (it is relatively small), will you use LVM anyway?
>
>DASD now can be 27 and 54GB, which is plenty of space for normal
>application use (except DB). Is it not enough for your needs?
>Maybe you initially allocate as little space as possible (say 1GB) and
>then add later?
>Basically, what is the pattern? :)
>
>
>Thank all who will respond and already responded.
>
>WBR, Sergey
>
>
>
>
>Rick Troth <r...@casita.net>
>Sent by: Linux on 390 Port <LINUX-390@VM.MARIST.EDU>
>05-10-15 17:18
>Please respond to Linux on 390 Port
>
>To: LINUX-390@VM.MARIST.EDU
>cc:
>Subject:Re: LVM usage
>
>
>Two great responses from Bob and Berry. Here's my LVM story too.
>
>
>On 10/05/2015 08:56 AM, Sergey Korzhevsky wrote:
>> Could you, please, explain me a real usage of the LVM
>> in the server environments with z/VM or whatever.
>
>I was introduced to LVM by colleagues.
>Since then, I have used it increasingly.
>It is the central facilitator for most of my storage needs.
>
>
>> Do you really need to "online" expand your "opt" or "home" directory
>> which is worth to have additional layer in disk access?
>
>Online resizing works very well.
>
>For me, there is no additional layer
>because I use LVM without partitioning.
>Where possible, I discard the partitioning "layer" in favor of LVM.
>In other words, where it can be done, I stamp the whole disk as a PV
>rather than stamping one or more partitions.
>
>Recent discussion exposes a bug in recent LVM utilities where there is
>some sad confusion between partitioned and unpartitioned physical
>volumes. Other than that, LVM is everything partitioning wanted to be if
>partitioning grew up.
>
>Hard numbers exposing the insertion loss from use of LVM would be great.
>Best practice recommends use of LVM for the administrative advantage.
>
>
>> Moreover,  databases already have such functionality
>> (tablespace/containers), so they don't need LVM.
>
>There are many places we see functional overlap. Not only databases, but
>also ...
>
> + EVMS combined multipath support with volume management, yet LVM won
>
> + newer filesystems combine volume management with the FS, and LVM is
>losing
>
>There is no one size fits all, so you'll want to dig-into the
>capabilities of LVM to answer your own needs. But LVM is an excellent
>solution with fewer layering violations than the overlaps mentioned
>here. (It fits the Unix rule of do one thing and do it well.)
>
>-- R; <><
>
>--
>For LINUX-390 subscribe / signoff / archive access instructions,
>send email to lists...@vm.marist.edu with

Re: LVM usage

[Sergey Korzhevsky]

Hi Rick,

 Could you tell me some details, because it is not obvious for what type
of services you are actually using LVM? Is this Websphere, databases,
Samba, log storage, custom application with a lot of data, anything else?

Stories about TSM and Samba are great, but this is one installation for
the site and we are speaking in terms of z/VM, right?
Maybe i need to ask additional query: do you use LVM no matter what? For
example, if you need to create one linux (maybe a bunch of them)  with
webserver (it is relatively small), will you use LVM anyway?

DASD now can be 27 and 54GB, which is plenty of space for normal
application use (except DB). Is it not enough for your needs?
Maybe you initially allocate as little space as possible (say 1GB) and
then add later?
Basically, what is the pattern? :)


Thank all who will respond and already responded.

WBR, Sergey




Rick Troth <r...@casita.net>
Sent by: Linux on 390 Port <LINUX-390@VM.MARIST.EDU>
05-10-15 17:18
Please respond to Linux on 390 Port

To: LINUX-390@VM.MARIST.EDU
cc:
Subject:    Re: LVM usage


Two great responses from Bob and Berry. Here's my LVM story too.


On 10/05/2015 08:56 AM, Sergey Korzhevsky wrote:
> Could you, please, explain me a real usage of the LVM
> in the server environments with z/VM or whatever.

I was introduced to LVM by colleagues.
Since then, I have used it increasingly.
It is the central facilitator for most of my storage needs.


> Do you really need to "online" expand your "opt" or "home" directory
> which is worth to have additional layer in disk access?

Online resizing works very well.

For me, there is no additional layer
because I use LVM without partitioning.
Where possible, I discard the partitioning "layer" in favor of LVM.
In other words, where it can be done, I stamp the whole disk as a PV
rather than stamping one or more partitions.

Recent discussion exposes a bug in recent LVM utilities where there is
some sad confusion between partitioned and unpartitioned physical
volumes. Other than that, LVM is everything partitioning wanted to be if
partitioning grew up.

Hard numbers exposing the insertion loss from use of LVM would be great.
Best practice recommends use of LVM for the administrative advantage.


> Moreover,  databases already have such functionality
> (tablespace/containers), so they don't need LVM.

There are many places we see functional overlap. Not only databases, but
also ...

 + EVMS combined multipath support with volume management, yet LVM won

 + newer filesystems combine volume management with the FS, and LVM is
losing

There is no one size fits all, so you'll want to dig-into the
capabilities of LVM to answer your own needs. But LVM is an excellent
solution with fewer layering violations than the overlaps mentioned
here. (It fits the Unix rule of do one thing and do it well.)

-- R; <><

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/


--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: LVM usage

[Scott Rohling]

My experience is that LVM is almost always used -- non-LVM is rarer on
zLinux.DASD sizes have grown which help limit some needs for using LVM
-- but the ability to be expanded dynamically is a pretty big sell point
when the goal is 'no outage required' for most shops..

One exception is probably FCP/SAN storage -- where LVM may be used less
often ...  Large enough spaces may be allocated on the SAN that combining
devices isn't necessary..   but I still see LVM used for expandability
purposes even on this storage...

Scott Rohling

On Mon, Oct 5, 2015 at 8:23 AM, Sergey Korzhevsky <s_korzhev...@iba.by>
wrote:

> Hi Rick,
>
>  Could you tell me some details, because it is not obvious for what type
> of services you are actually using LVM? Is this Websphere, databases,
> Samba, log storage, custom application with a lot of data, anything else?
>
> Stories about TSM and Samba are great, but this is one installation for
> the site and we are speaking in terms of z/VM, right?
> Maybe i need to ask additional query: do you use LVM no matter what? For
> example, if you need to create one linux (maybe a bunch of them)  with
> webserver (it is relatively small), will you use LVM anyway?
>
> DASD now can be 27 and 54GB, which is plenty of space for normal
> application use (except DB). Is it not enough for your needs?
> Maybe you initially allocate as little space as possible (say 1GB) and
> then add later?
> Basically, what is the pattern? :)
>
>
> Thank all who will respond and already responded.
>
> WBR, Sergey
>
>
>
>
> Rick Troth <r...@casita.net>
> Sent by: Linux on 390 Port <LINUX-390@VM.MARIST.EDU>
> 05-10-15 17:18
> Please respond to Linux on 390 Port
>
> To: LINUX-390@VM.MARIST.EDU
> cc:
> Subject:Re: LVM usage
>
>
> Two great responses from Bob and Berry. Here's my LVM story too.
>
>
> On 10/05/2015 08:56 AM, Sergey Korzhevsky wrote:
> > Could you, please, explain me a real usage of the LVM
> > in the server environments with z/VM or whatever.
>
> I was introduced to LVM by colleagues.
> Since then, I have used it increasingly.
> It is the central facilitator for most of my storage needs.
>
>
> > Do you really need to "online" expand your "opt" or "home" directory
> > which is worth to have additional layer in disk access?
>
> Online resizing works very well.
>
> For me, there is no additional layer
> because I use LVM without partitioning.
> Where possible, I discard the partitioning "layer" in favor of LVM.
> In other words, where it can be done, I stamp the whole disk as a PV
> rather than stamping one or more partitions.
>
> Recent discussion exposes a bug in recent LVM utilities where there is
> some sad confusion between partitioned and unpartitioned physical
> volumes. Other than that, LVM is everything partitioning wanted to be if
> partitioning grew up.
>
> Hard numbers exposing the insertion loss from use of LVM would be great.
> Best practice recommends use of LVM for the administrative advantage.
>
>
> > Moreover,  databases already have such functionality
> > (tablespace/containers), so they don't need LVM.
>
> There are many places we see functional overlap. Not only databases, but
> also ...
>
>  + EVMS combined multipath support with volume management, yet LVM won
>
>  + newer filesystems combine volume management with the FS, and LVM is
> losing
>
> There is no one size fits all, so you'll want to dig-into the
> capabilities of LVM to answer your own needs. But LVM is an excellent
> solution with fewer layering violations than the overlaps mentioned
> here. (It fits the Unix rule of do one thing and do it well.)
>
> -- R; <><
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
> visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
> --
> For more information on Linux on System z, visit
> http://wiki.linuxvm.org/
>
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
> visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
> --
> For more information on Linux on System z, visit
> http://wiki.linuxvm.org/
>

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: LVM usage between lpars

[Froberg, David C]

I really appreciate everyone's feedback on this topic.

It was a *big* help in planning out a few things.

Dave

 -Original Message-
 From: Linux on 390 Port [mailto:[EMAIL PROTECTED]
 Sent: Friday, January 09, 2004 5:20 PM
 To: [EMAIL PROTECTED]
 Subject: Re: [LINUX-390] LVM usage between lpars


 On Fri, 2004-01-09 at 14:44, Froberg, David C wrote:
  Thanks, David.  Neglected the reserve/release issue.
 
  For the simpler solution you outlined, is NFS a better way
 to go than SMB
  [Samba]?

 NFS and Samba both have their own sets of issues.  I find Samba easier
 to set up; NFS is more ubiquitous when talking to non-Windows hosts,
 though.

 Adam

Re: LVM usage between lpars

[David Boyes]

 For the simpler solution you outlined, is NFS a better way to
 go than SMB
 [Samba]?

Either will work, but NFS imposes a lot less overhead than SMB. If you
anticipate Windows systems needing direct access to the filesystems, then
you might consider using SMB, but if not, then the overhead cost is probably
prohibitive. It's not an either-or setup; you might consider using NFS
between the Linux systems and have one of them run Samba to provide an
external interface to the Windows systems w/o exposing the file server
directly.

Using NFS does imply that the numeric UID values for all users be identical
on all the systems accessing the shared file systems. You may want to set up
the file server system also as a NIS master server (or use LDAP or
Kerberos for authentication).

-- db

LVM usage between lpars

[Froberg, David C]

Folks,

Sanity check.

I've defined two LVM physical volume groups.  I plan to share these two
volume groups between three lpars running Linux (SLES 8).  The physical
volume groups will provide two pools of space from which logical volumes can
be allocated and mounted to the various Linux images. (Any given logical
volume will be mounted exclusively to only one Linux image.)

This should not be a problem sharing physical volume groups, correct?  I
should be able to share the physical volume groups, right?  Are there any
obvious problems with this?

Thanks in advance for any input.

Dave

Re: LVM usage between lpars

[Eric Sammons]

I was always under the impression that a single volume group can only be
made available to a single system.  This is where the import volume group
and export volume group features of Veritas and other LVM tools come from.

I know that disks can be made visiable to more than one system, this is
where HA comes in.  However, in the event of a failure most HA solutions
will perform the necessary force import functions on a volume group before
fully taking advantage of them.

Am I mistaken here?

Eric Sammons
FRIT - Unix Systems





Froberg, David C [EMAIL PROTECTED]
Sent by: Linux on 390 Port [EMAIL PROTECTED]
01/09/2004 11:55 AM
Please respond to Linux on 390 Port

To: [EMAIL PROTECTED]
cc:
Subject:LVM usage between lpars

Folks,

Sanity check.

I've defined two LVM physical volume groups.  I plan to share these two
volume groups between three lpars running Linux (SLES 8).  The physical
volume groups will provide two pools of space from which logical volumes
can
be allocated and mounted to the various Linux images. (Any given logical
volume will be mounted exclusively to only one Linux image.)

This should not be a problem sharing physical volume groups, correct?  I
should be able to share the physical volume groups, right?  Are there any
obvious problems with this?

Thanks in advance for any input.

Dave

Re: LVM usage between lpars

[David Boyes]

Linux does not do reserve/release, so you need to be very, very sure that
the devices never come online to more than one LPAR at a time.

I'd suggest a simpler solution: designate one LPAR as a NFS file server and
use NFS to mount the volumes on the various other LPARs. It's a lot simpler
to manage, and it's a ideal use for hipersockets if you have them.

-- db

David Boyes
Sine Nomine Associates


 -Original Message-
 From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of
 Froberg, David C
 Sent: Friday, January 09, 2004 11:55 AM
 To: [EMAIL PROTECTED]
 Subject: LVM usage between lpars


 Folks,

 Sanity check.

 I've defined two LVM physical volume groups.  I plan to share
 these two
 volume groups between three lpars running Linux (SLES 8).
 The physical
 volume groups will provide two pools of space from which
 logical volumes can
 be allocated and mounted to the various Linux images. (Any
 given logical
 volume will be mounted exclusively to only one Linux image.)

 This should not be a problem sharing physical volume groups,
 correct?  I
 should be able to share the physical volume groups, right?
 Are there any
 obvious problems with this?

 Thanks in advance for any input.

 Dave

Re: LVM usage between lpars

[Froberg, David C]

Thanks, David.  Neglected the reserve/release issue.

For the simpler solution you outlined, is NFS a better way to go than SMB
[Samba]?

Dave

 -Original Message-
 From: Linux on 390 Port [mailto:[EMAIL PROTECTED]
 Sent: Friday, January 09, 2004 2:24 PM
 To: [EMAIL PROTECTED]
 Subject: Re: [LINUX-390] LVM usage between lpars


 Linux does not do reserve/release, so you need to be very,
 very sure that
 the devices never come online to more than one LPAR at a time.

 I'd suggest a simpler solution: designate one LPAR as a NFS
 file server and
 use NFS to mount the volumes on the various other LPARs. It's
 a lot simpler
 to manage, and it's a ideal use for hipersockets if you have them.

 -- db

 David Boyes
 Sine Nomine Associates


  -Original Message-
  From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of
  Froberg, David C
  Sent: Friday, January 09, 2004 11:55 AM
  To: [EMAIL PROTECTED]
  Subject: LVM usage between lpars
 
 
  Folks,
 
  Sanity check.
 
  I've defined two LVM physical volume groups.  I plan to share
  these two
  volume groups between three lpars running Linux (SLES 8).
  The physical
  volume groups will provide two pools of space from which
  logical volumes can
  be allocated and mounted to the various Linux images. (Any
  given logical
  volume will be mounted exclusively to only one Linux image.)
 
  This should not be a problem sharing physical volume groups,
  correct?  I
  should be able to share the physical volume groups, right?
  Are there any
  obvious problems with this?
 
  Thanks in advance for any input.
 
  Dave
 

Re: LVM usage between lpars

[Post, Mark K]

Dave,

Yes, NFS is better than SMB.  No file name mangling code, no mapping MS
Windows permissions to UNIX ones (and then back again in this case), etc.,
etc.

Mark Post

-Original Message-
From: Froberg, David C [mailto:[EMAIL PROTECTED]
Sent: Friday, January 09, 2004 3:45 PM
To: [EMAIL PROTECTED]
Subject: Re: LVM usage between lpars


Thanks, David.  Neglected the reserve/release issue.

For the simpler solution you outlined, is NFS a better way to go than SMB
[Samba]?

Dave

 -Original Message-
 From: Linux on 390 Port [mailto:[EMAIL PROTECTED]
 Sent: Friday, January 09, 2004 2:24 PM
 To: [EMAIL PROTECTED]
 Subject: Re: [LINUX-390] LVM usage between lpars


 Linux does not do reserve/release, so you need to be very,
 very sure that
 the devices never come online to more than one LPAR at a time.

 I'd suggest a simpler solution: designate one LPAR as a NFS
 file server and
 use NFS to mount the volumes on the various other LPARs. It's
 a lot simpler
 to manage, and it's a ideal use for hipersockets if you have them.

 -- db

 David Boyes
 Sine Nomine Associates


  -Original Message-
  From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of
  Froberg, David C
  Sent: Friday, January 09, 2004 11:55 AM
  To: [EMAIL PROTECTED]
  Subject: LVM usage between lpars
 
 
  Folks,
 
  Sanity check.
 
  I've defined two LVM physical volume groups.  I plan to share
  these two
  volume groups between three lpars running Linux (SLES 8).
  The physical
  volume groups will provide two pools of space from which
  logical volumes can
  be allocated and mounted to the various Linux images. (Any
  given logical
  volume will be mounted exclusively to only one Linux image.)
 
  This should not be a problem sharing physical volume groups,
  correct?  I
  should be able to share the physical volume groups, right?
  Are there any
  obvious problems with this?
 
  Thanks in advance for any input.
 
  Dave
 

Re: LVM usage between lpars

[Adam Thornton]

On Fri, 2004-01-09 at 14:44, Froberg, David C wrote:
 Thanks, David.  Neglected the reserve/release issue.

 For the simpler solution you outlined, is NFS a better way to go than SMB
 [Samba]?

NFS and Samba both have their own sets of issues.  I find Samba easier
to set up; NFS is more ubiquitous when talking to non-Windows hosts,
though.

Adam