Re: BaseVol/GuestVol server for SLES9
(Sorry this is so late; we wanted to make sure we had something solid
before I responded.)
Michael MacIsaac wrote:
What are other people using for the layout of their master/golden image?
Right now, we're testing out the basevol/guestvol setup at
http://www.linuxvm.org/Info/HOWTOs/basevol9.html With the help of the
folks at Novell, we finally solved our FCP issue, allowing our guestvol
systems to attach to FCP LUNs for filesystems like /opt, and save DASD
for the R/W portions of the operating system.
On our basevol system, we have a file called /etc/luns.guestvols, which
looks like this:
LINUX15:0.0.f106:0x50050768012004cc:0x0006
LINUX1:0.0.f105:0x50050768012004cc:0x0003
LINUX5:0.0.f100:0x5005076300c99168:0x5702
LINUX16:0.0.f107:0x50050768012004cc:0x0007
LINUX9:0.0.f101:0x50050768012004cc:0x0001
LINUX9:0.0.f103:0x50050768012004cc:0x0005
The fields, separated by colons, are Guest ID, channel, WWPN, and LUN.
We also have a script called /etc/init.d/boot.fcpluns:
#!/bin/sh
# Get the name of the guest:
modprobe vmcp
sleep 1
GUESTID=$(vmcp q userid | awk '{ print $1 }')
# Get a list of the targets
FCPTARGET=$(sed /^$GUESTID/p;d /etc/luns.guestvols)
# iterate
for a in $FCPTARGET ; do
CCW=$(echo $a | awk -F: '{ print $2 }')
WWPN=$(echo $a | awk -F: '{ print $3 }')
LUN=$(echo $a | awk -F: '{ print $4 }')
/sbin/zfcp_host_configure $CCW 1
/sbin/zfcp_disk_configure $CCW $WWPN $LUN 1
done
/etc/init.d/boot.fcpluns is run right after /etc/init.d/boot.guestvol
during the boot process.
When we add a system with an FCP LUN to our VM, we modify
/etc/luns.guestvols and re-run /etc/init.d/make-guestvol to ensure the
latest changes to this file will be sent to the new system.
-Matt
--
Matt Gourley
Systems Administrator
Pennsylvania State University
Administrative Information Services - Infrastructure/Sysarc
Rm 25 Shields Bldg., University Park, PA 16802
(814) 865-8726
[EMAIL PROTECTED]
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: BaseVol/GuestVol server for SLES9
Cool! Very nice.
Does your scheme handle multipath at all?
-- R;
Matt Gourley [EMAIL PROTECTED]
Sent by: Linux on 390 Port LINUX-390@VM.MARIST.EDU
07/10/2007 11:32 AM
Please respond to Linux on 390 Port LINUX-390@VM.MARIST.EDU
From
Matt Gourley [EMAIL PROTECTED]
To
LINUX-390@VM.MARIST.EDU
cc
Subject
Re: BaseVol/GuestVol server for SLES9
(Sorry this is so late; we wanted to make sure we had something solid
before I responded.)
Michael MacIsaac wrote:
What are other people using for the layout of their master/golden image?
Right now, we're testing out the basevol/guestvol setup at
http://www.linuxvm.org/Info/HOWTOs/basevol9.html With the help of the
folks at Novell, we finally solved our FCP issue, allowing our guestvol
systems to attach to FCP LUNs for filesystems like /opt, and save DASD
for the R/W portions of the operating system.
On our basevol system, we have a file called /etc/luns.guestvols, which
looks like this:
LINUX15:0.0.f106:0x50050768012004cc:0x0006
LINUX1:0.0.f105:0x50050768012004cc:0x0003
LINUX5:0.0.f100:0x5005076300c99168:0x5702
LINUX16:0.0.f107:0x50050768012004cc:0x0007
LINUX9:0.0.f101:0x50050768012004cc:0x0001
LINUX9:0.0.f103:0x50050768012004cc:0x0005
The fields, separated by colons, are Guest ID, channel, WWPN, and LUN.
We also have a script called /etc/init.d/boot.fcpluns:
#!/bin/sh
# Get the name of the guest:
modprobe vmcp
sleep 1
GUESTID=$(vmcp q userid | awk '{ print $1 }')
# Get a list of the targets
FCPTARGET=$(sed /^$GUESTID/p;d /etc/luns.guestvols)
# iterate
for a in $FCPTARGET ; do
CCW=$(echo $a | awk -F: '{ print $2 }')
WWPN=$(echo $a | awk -F: '{ print $3 }')
LUN=$(echo $a | awk -F: '{ print $4 }')
/sbin/zfcp_host_configure $CCW 1
/sbin/zfcp_disk_configure $CCW $WWPN $LUN 1
done
/etc/init.d/boot.fcpluns is run right after /etc/init.d/boot.guestvol
during the boot process.
When we add a system with an FCP LUN to our VM, we modify
/etc/luns.guestvols and re-run /etc/init.d/make-guestvol to ensure the
latest changes to this file will be sent to the new system.
-Matt
--
Matt Gourley
Systems Administrator
Pennsylvania State University
Administrative Information Services - Infrastructure/Sysarc
Rm 25 Shields Bldg., University Park, PA 16802
(814) 865-8726
[EMAIL PROTECTED]
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or
visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: BaseVol/GuestVol server for SLES9
I agree with Mark about the lameness of /srv and /media. But, Mark, what you describe under /mnt (where /mnt acts for you like /media does for others) is at odds with some historical Unix/POSIX methods. If there is any sliver of justification for /media it is to lend some consistency for floppy and cdrom. -- R; Mark Post [EMAIL PROTECTED] Sent by: Linux on 390 Port LINUX-390@VM.MARIST.EDU 06/27/2007 03:52 PM Please respond to Linux on 390 Port LINUX-390@VM.MARIST.EDU From Mark Post [EMAIL PROTECTED] To LINUX-390@VM.MARIST.EDU cc Subject Re: BaseVol/GuestVol server for SLES9 On Wed, Jun 27, 2007 at 3:33 PM, in message [EMAIL PROTECTED], McKown, John [EMAIL PROTECTED] wrote: -snip- Hum, I guess. Except that /mnt has been around vaguely forever and perhaps the architect was concerned with name collisions of some sort. /mnt/media might be a bit better than just /mnt. But, then again, suppose /mnt has something mounted onto it? Some distributions already have things such as /mnt/floppy /mnt/cdrom I wish more of them did. If you're sticking things into USB ports, that means you're probably responsible for anything else mounted on the system. If you can't keep from tripping over yourself by mounting something on just plain /mnt, then you probably have even bigger problems waiting for you. ;) Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: BaseVol/GuestVol server for SLES9
Richard Troth wrote: I agree with Mark about the lameness of /srv and /media. But, Mark, what you describe under /mnt (where /mnt acts for you like /media does for others) is at odds with some historical Unix/POSIX methods. If there is any sliver of justification for /media it is to lend some consistency for floppy and cdrom. and that was promptly lost by mounting CDs at /media/volser and by not mounting at all if there's no desktop, and then it's always mounted if there is a desktop: I've even seen freshly-burned CD/DVD media get mounted. Me, I've gone back to the old way using /mnt and /etc/fstab -- R; Mark Post [EMAIL PROTECTED] Sent by: Linux on 390 Port LINUX-390@VM.MARIST.EDU 06/27/2007 03:52 PM Please respond to Linux on 390 Port LINUX-390@VM.MARIST.EDU From Mark Post [EMAIL PROTECTED] To LINUX-390@VM.MARIST.EDU cc Subject Re: BaseVol/GuestVol server for SLES9 On Wed, Jun 27, 2007 at 3:33 PM, in message [EMAIL PROTECTED], McKown, John [EMAIL PROTECTED] wrote: -snip- Hum, I guess. Except that /mnt has been around vaguely forever and perhaps the architect was concerned with name collisions of some sort. /mnt/media might be a bit better than just /mnt. But, then again, suppose /mnt has something mounted onto it? Some distributions already have things such as /mnt/floppy /mnt/cdrom I wish more of them did. If you're sticking things into USB ports, that means you're probably responsible for anything else mounted on the system. If you can't keep from tripping over yourself by mounting something on just plain /mnt, then you probably have even bigger problems waiting for you. ;) Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Please do not reply off-list -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: BaseVol/GuestVol server for SLES9
Stricklin, Raymond J wrote: Probably. Generally accepted practice in the Unix world separates /, /usr, /var, /opt, /home, and /srv (if used) into distinct filesystems. I'm going to have to respectfully disagree. Making separate filesystems without understanding the _reasons_ for making things separate filesystems is not a long-term recipe for success. Most of the reasons are technical and related to the comparatively limited hardware capacity of UNIX systems in the '70s and '80s. Filesystems were split up so that they could fit on the disks which were available at the time, and to simplify backups in an era of ~60 MB tapes and tools no more sophisticated than 'dump'. Now disks are huge and backup tools are sophisticated enough that filesystem dumps seem hopelessly archaic. These are good things, in the big picture. The big drivers for splitting up filesystems these days are to keep users from filling up the wrong disks, and to keep things running smoothly for your operators. There's no reason to make directories which are relatively static and are not subject to being filled by users into separate filesystems. If you're running a server which won't have any users logging into it, making /home a separate filesystem is pointless. It adds to the complexity of maintaining the system without adding a commensurate benefit. If /opt isn't going to have much in it or change very often, there's not a lot of reason to split it into its own filesystem. If, as frequently happens here, nobody knows what the server will look like six months down the road, or what software will be on it, making /opt a separate logical volume---which can be grown as required---is a very good idea. If your site, like ours, isn't ruthlessly efficient at managing logfile sizes, and your operators are basically punished by getting paged whenever root hits 80% at three in the morning, and you can turn the problem into something that can be dealt with in the morning by making /var a separate filesystem, do it. I'd say that today, in general, if you don't know why you're splitting it out, don't split it out. Data, on the other hand, should almost always be separate. Especially if it's data which is not controlled by the system administrators. (i.e., /srv -- a SuSE convention which I personally find loathesome) Its part of the Filesystem Hierarchy Standard (FHS) http://www.pathname.com/fhs/ /srv Data for services provided by the system You have a complaint, take it up with them FHS is part of the Linux Standard Base (LSB) http://www.linux-foundation.org/en/LSB Kim -- Kim Goldenberg Systems Programmer I State of NJ - OIT 609-777-3722 [EMAIL PROTECTED] [EMAIL PROTECTED] -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: BaseVol/GuestVol server for SLES9
-Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Mark Post Sent: Friday, June 22, 2007 3:46 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: BaseVol/GuestVol server for SLES9 snip I don't think you can blame SUSE for that. I'm pretty sure it's a requirement of LSB. (But, while we're at it, let's condemn /media too. That's equally worthless.) snip Mark Post Why do you say that /media is worthless? Perhaps it is on System z, but it is very nice on Intel where it automounts my USB stick when I plug it in. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: BaseVol/GuestVol server for SLES9
On Wed, Jun 27, 2007 at 2:59 PM, in message [EMAIL PROTECTED], McKown, John [EMAIL PROTECTED] wrote: -snip- Why do you say that /media is worthless? Perhaps it is on System z, but it is very nice on Intel where it automounts my USB stick when I plug it in. Any reason why it couldn't do that under /mnt, instead of inventing an entirely new place to mount things? Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: BaseVol/GuestVol server for SLES9
-Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Mark Post Sent: Wednesday, June 27, 2007 2:06 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: BaseVol/GuestVol server for SLES9 On Wed, Jun 27, 2007 at 2:59 PM, in message [EMAIL PROTECTED] om, McKown, John [EMAIL PROTECTED] wrote: -snip- Why do you say that /media is worthless? Perhaps it is on System z, but it is very nice on Intel where it automounts my USB stick when I plug it in. Any reason why it couldn't do that under /mnt, instead of inventing an entirely new place to mount things? Mark Post Hum, I guess. Except that /mnt has been around vaguely forever and perhaps the architect was concerned with name collisions of some sort. /mnt/media might be a bit better than just /mnt. But, then again, suppose /mnt has something mounted onto it? I use /mnt fairly often for temporary mounts. I would be upset if I had mounted, say, a CDROM on /mnt and then inserted a USB stick and had problems. Also /mnt/media has a possible problem if a CDROM is mounted at /mnt, how is the /mnt/media subdirectory dynamically created on a read-only medium? And if a read-write medium is mounted at /mnt, do I want the system to dynamically create /mnt/media on it? (OK, /mnt/media was my thought and it was a poor one at that). -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: BaseVol/GuestVol server for SLES9
Using the /mnt directory to automatically mount stuff conflicts with the work that I do. Specifically I sometimes need to mount stuff to do maintenance. Even having /mnt/media might cause problems. I might mount something there without thinking. I think /media is a good idea. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of McKown, John Sent: Wednesday, June 27, 2007 12:34 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: BaseVol/GuestVol server for SLES9 -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Mark Post Sent: Wednesday, June 27, 2007 2:06 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: BaseVol/GuestVol server for SLES9 On Wed, Jun 27, 2007 at 2:59 PM, in message [EMAIL PROTECTED] om, McKown, John [EMAIL PROTECTED] wrote: -snip- Why do you say that /media is worthless? Perhaps it is on System z, but it is very nice on Intel where it automounts my USB stick when I plug it in. Any reason why it couldn't do that under /mnt, instead of inventing an entirely new place to mount things? Mark Post Hum, I guess. Except that /mnt has been around vaguely forever and perhaps the architect was concerned with name collisions of some sort. /mnt/media might be a bit better than just /mnt. But, then again, suppose /mnt has something mounted onto it? I use /mnt fairly often for temporary mounts. I would be upset if I had mounted, say, a CDROM on /mnt and then inserted a USB stick and had problems. Also /mnt/media has a possible problem if a CDROM is mounted at /mnt, how is the /mnt/media subdirectory dynamically created on a read-only medium? And if a read-write medium is mounted at /mnt, do I want the system to dynamically create /mnt/media on it? (OK, /mnt/media was my thought and it was a poor one at that). -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: BaseVol/GuestVol server for SLES9
On Wed, Jun 27, 2007 at 3:33 PM, in message [EMAIL PROTECTED], McKown, John [EMAIL PROTECTED] wrote: -snip- Hum, I guess. Except that /mnt has been around vaguely forever and perhaps the architect was concerned with name collisions of some sort. /mnt/media might be a bit better than just /mnt. But, then again, suppose /mnt has something mounted onto it? Some distributions already have things such as /mnt/floppy /mnt/cdrom I wish more of them did. If you're sticking things into USB ports, that means you're probably responsible for anything else mounted on the system. If you can't keep from tripping over yourself by mounting something on just plain /mnt, then you probably have even bigger problems waiting for you. ;) Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: BaseVol/GuestVol server for SLES9
So does the Filesystem Hierarchy Standard carry an weight? It says that /media is the place for automatically mounted devices like floppy and cdrom. http://www.pathname.com/fhs/ -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of Mark Post Sent: Wednesday, June 27, 2007 12:53 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: BaseVol/GuestVol server for SLES9 On Wed, Jun 27, 2007 at 3:33 PM, in message [EMAIL PROTECTED], McKown, John [EMAIL PROTECTED] wrote: -snip- Hum, I guess. Except that /mnt has been around vaguely forever and perhaps the architect was concerned with name collisions of some sort. /mnt/media might be a bit better than just /mnt. But, then again, suppose /mnt has something mounted onto it? Some distributions already have things such as /mnt/floppy /mnt/cdrom I wish more of them did. If you're sticking things into USB ports, that means you're probably responsible for anything else mounted on the system. If you can't keep from tripping over yourself by mounting something on just plain /mnt, then you probably have even bigger problems waiting for you. ;) Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: BaseVol/GuestVol server for SLES9
On Wed, Jun 27, 2007 at 4:06 PM, in message [EMAIL PROTECTED], Fargusson.Alan [EMAIL PROTECTED] wrote: So does the Filesystem Hierarchy Standard carry an weight? It says that /media is the place for automatically mounted devices like floppy and cdrom. Clearly it does, or distributions wouldn't be honoring it. Which doesn't mean it wasn't a stupid idea and shouldn't be in there in the first place. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
BaseVol/GuestVol server for SLES9
Hi Listers, I'm very grateful to all the responses to my BaseVol/GuestVol posting; it's certainly given us a lot to chew on. I think I'm rapidly coming to the conclusion that this may be just a wee bit over my head. But, I'm going to keep plugging away, and because I'm certain I'll fall into holes along the way, may end up learning alot after all. Thanks very much to all for your insights. susan -- Date:Mon, 25 Jun 2007 11:52:09 -0400 From:Edmund R. MacKenty [EMAIL PROTECTED] Subject: Re: BaseVol/GuestVol server for SLES9 On Friday 22 June 2007 16:30, Stricklin, Raymond J replied to : David Boyes: Probably. Generally accepted practice in the Unix world separates /, /usr, /var, /opt, /home, and /srv (if used) into distinct filesystems. I'm going to have to respectfully disagree. Making separate filesystems without understanding the _reasons_ for making things separate filesystems is not a long-term recipe for success. And, unfortunately, not making separate filesystems is not a long-term recipe for success either. It has always bugged me that the default installation of these Enterprise distros do not create at least three filesystems and provide some help screens explaining the purpose and trade-offs involved, or at least a few different options for pre-defined filesystem structures. You're perfectly correct in that the main reason for creating multiple filesystems is to avoid filling up disks the system needs space on to run. Of course, how you split things up depends on the purpose of the system. For a server, the goal is to keep / from filling up, so at a minimum /, /var and /tmp should be in separate filesystems. If the system is to be used by humans, /home should also be separate. If it's a mail server, /var/spool/mqueue, /var/spool/mail and /var/log might each be on separate filesystems. If you're going to share DASD, then /usr should probably be separate. But if you have a workload that chews up space in /, your system will eventually crash, so you had better move the directory your workload is writing into to a separate filesystem. /etc and /tmp are often also split out, but less commonly. I have never, ever, EVER seen /etc split out, or at least not as anything other than a joke. Off the top of my head I can think of at least four different varieties of UNIX which won't even boot if you do that. Don't do it, it's completely unnecessary and will complicate your life in needless ways. You *can* put /etc on a separate filesystem as long as you make a few files in it (passwd, shadow, fstab) available on the root filesystem so that you can boot to the point of mounting /etc. This is not something you want to do by hand, but an automation tool can handle this for you. shameless-plugI make a Provisioning Expert product that automates the creation of Linux guests with arbitrary filesystem layouts and manages the sharing of filesystems between guests for you. It can share almost any part of the directory structure, even individual files, by cleverly using bind-mounts and symlinks./shameless-plug When I really want to save DASD, I share most of /etc and make just the few configuration files I'll need to change on a guest be in a non-shared filesystem (and thus writable). You can do the same thing with /dev and /lib if you're brave. ;-) When setting up filesystems by hand, though, I think the most important thing to plan for is flexibility. It's easy to move /home to a separate filesystem later on if you find you need to (or even /usr, in single-user mode), but it's kind of hard to combine a separate /home back into the root filesystem. /tmp is a different story. I've always really liked Sun's approach of making it a transient, memory-backed filesystem. It seems that on a hypervisor system like VM, where we are using VDISK for swap, there is merit in doing the same with tmpfs on linux. We're about to give it a shot and see how it works in practice. I'm ambivalent about /tmp in a tmpfs. Some tools, such as sort(1), use /tmp when they would otherwise run out of memory. Sort tries to do as much as it can in-memory, but if it runs out, it dumps partially-sorted sub-lists into /tmp so it can handle more input. Using a tmpfs for /tmp makes this approach fail. There may well be other tools that do that, but they should be spooling workload under /var. Come to think of it, sort may be using /var/tmp, because only system processes are supposed to use /tmp. User-processes should use /var/tmp. Using a tmpfs for /tmp is just going to make it swap more, so for most architectures you might as well put /tmp on real disk. Under z/VM with VDISK swap, though, it should be more efficient to put increase your swap size and use a tmpfs because VDISK is faster that plain DASD. I haven't measured that specifically, though, so I'd be interested to know what numbers you get from your experiment. - MacK. - Edmund R. MacKenty Software
Re: BaseVol/GuestVol server for SLES9
On Friday 22 June 2007 16:30, Stricklin, Raymond J replied to : David Boyes: Probably. Generally accepted practice in the Unix world separates /, /usr, /var, /opt, /home, and /srv (if used) into distinct filesystems. I'm going to have to respectfully disagree. Making separate filesystems without understanding the _reasons_ for making things separate filesystems is not a long-term recipe for success. And, unfortunately, not making separate filesystems is not a long-term recipe for success either. It has always bugged me that the default installation of these Enterprise distros do not create at least three filesystems and provide some help screens explaining the purpose and trade-offs involved, or at least a few different options for pre-defined filesystem structures. You're perfectly correct in that the main reason for creating multiple filesystems is to avoid filling up disks the system needs space on to run. Of course, how you split things up depends on the purpose of the system. For a server, the goal is to keep / from filling up, so at a minimum /, /var and /tmp should be in separate filesystems. If the system is to be used by humans, /home should also be separate. If it's a mail server, /var/spool/mqueue, /var/spool/mail and /var/log might each be on separate filesystems. If you're going to share DASD, then /usr should probably be separate. But if you have a workload that chews up space in /, your system will eventually crash, so you had better move the directory your workload is writing into to a separate filesystem. /etc and /tmp are often also split out, but less commonly. I have never, ever, EVER seen /etc split out, or at least not as anything other than a joke. Off the top of my head I can think of at least four different varieties of UNIX which won't even boot if you do that. Don't do it, it's completely unnecessary and will complicate your life in needless ways. You *can* put /etc on a separate filesystem as long as you make a few files in it (passwd, shadow, fstab) available on the root filesystem so that you can boot to the point of mounting /etc. This is not something you want to do by hand, but an automation tool can handle this for you. shameless-plugI make a Provisioning Expert product that automates the creation of Linux guests with arbitrary filesystem layouts and manages the sharing of filesystems between guests for you. It can share almost any part of the directory structure, even individual files, by cleverly using bind-mounts and symlinks./shameless-plug When I really want to save DASD, I share most of /etc and make just the few configuration files I'll need to change on a guest be in a non-shared filesystem (and thus writable). You can do the same thing with /dev and /lib if you're brave. ;-) When setting up filesystems by hand, though, I think the most important thing to plan for is flexibility. It's easy to move /home to a separate filesystem later on if you find you need to (or even /usr, in single-user mode), but it's kind of hard to combine a separate /home back into the root filesystem. /tmp is a different story. I've always really liked Sun's approach of making it a transient, memory-backed filesystem. It seems that on a hypervisor system like VM, where we are using VDISK for swap, there is merit in doing the same with tmpfs on linux. We're about to give it a shot and see how it works in practice. I'm ambivalent about /tmp in a tmpfs. Some tools, such as sort(1), use /tmp when they would otherwise run out of memory. Sort tries to do as much as it can in-memory, but if it runs out, it dumps partially-sorted sub-lists into /tmp so it can handle more input. Using a tmpfs for /tmp makes this approach fail. There may well be other tools that do that, but they should be spooling workload under /var. Come to think of it, sort may be using /var/tmp, because only system processes are supposed to use /tmp. User-processes should use /var/tmp. Using a tmpfs for /tmp is just going to make it swap more, so for most architectures you might as well put /tmp on real disk. Under z/VM with VDISK swap, though, it should be more efficient to put increase your swap size and use a tmpfs because VDISK is faster that plain DASD. I haven't measured that specifically, though, so I'd be interested to know what numbers you get from your experiment. - MacK. - Edmund R. MacKenty Software Architect Rocket Software, Inc. Newton, MA USA -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: BaseVol/GuestVol server for SLES9
Probably. Generally accepted practice in the Unix world separates /, /usr, /var, /opt, /home, and /srv (if used) into distinct filesystems. I'm going to have to respectfully disagree. Making separate filesystems without understanding the _reasons_ for making things separate filesystems is not a long-term recipe for success. Fair enough -- it's easily definable as a religious issue, so my feelings aren't hurt. We do it for manageability and making images disk-sharing-friendly. Separating / is a good thing, as it's hard to resize it non-disruptively. I'd argue that /usr separate allows more trivial sharing between guests, particularly if you plan to make /usr R/O on multiple systems. /var, /srv, and /home are by definition variable and generally contain user data, which usually has different access and usage patterns than / or /usr. /opt is a debatable one; depends on the Unix variant. In most of the versions I support, /opt behaves more like /usr than /var, so we treat it like /usr. Most of the reasons are technical and related to the comparatively limited hardware capacity of UNIX systems in the '70s and '80s. Filesystems were split up so that they could fit on the disks which were available at the time, and to simplify backups in an era of ~60 MB tapes and tools no more sophisticated than 'dump'. Now disks are huge and backup tools are sophisticated enough that filesystem dumps seem hopelessly archaic. These are good things, in the big picture. Umm, not really. As noted above, the different access and utilization patterns do provide reasons to split them out. There's no reason to make directories which are relatively static and are not subject to being filled by users into separate filesystems. You've got much more idiot-free system administration and app mgmt groups than anyone I've ever worked for...8-). There's truth here, but there's also an argument for assembling your systems in the same way regardless of use. It allows rapid reassembly in another virtual machine quickly if something ugly happens to a system. If you're running a server which won't have any users logging into it, making /home a separate filesystem is pointless. It adds to the complexity of maintaining the system without adding a commensurate benefit. If /opt isn't going to have much in it or change very often, there's not a lot of reason to split it into its own filesystem. On the other hand, if you're doing logical volumes, making the LV for /opt and /home in these scenarios small, and assembling them in the same way is completely consistent, and I can then just expand the LV when I need more space w/o having to document unusual cases. Everything looks the same, and I always do the creation exactly the same way, regardless of what the server will be used for. This wins big if you're stamping out servers and don't necessarily know in advance what they'll be used for -- it's a heck of a lot easier to automate if I know every server is identical. It also allows me to do very fast automated surveys of configurations -- LVM can tell me a lot about utilization of LVs and how my physical storage is used. If your site, like ours, isn't ruthlessly efficient at managing logfile sizes, and your operators are basically punished by getting paged whenever root hits 80% at three in the morning, and you can turn the problem into something that can be dealt with in the morning by making /var a separate filesystem, do it. Self-correcting problem, methinks. This is what automation is for. One 3 am stint for stuff like this, and logrotate becomes your best friend. 8-) /etc and /tmp are often also split out, but less commonly. I have never, ever, EVER seen /etc split out, or at least not as anything other than a joke. Off the top of my head I can think of at least four different varieties of UNIX which won't even boot if you do that. Don't do it, it's completely unnecessary and will complicate your life in needless ways. On the other hand, it's a fundamental assumption of the basevol/guestvol approach we're discussing. All the identifying bits that make a Linux server unique are in /etc. We regularly do it with Linux, Solaris, AIX, and HP/UX systems. Irix is a major PITA for this, though. UNICOS tolerates it. DUNIX doesn't. FreeBSD tolerates it. BSDI tolerates it. Certainly, it's not for the faint of heart, though. /tmp is a different story. I've always really liked Sun's approach of making it a transient, memory-backed filesystem. It seems that on a hypervisor system like VM, where we are using VDISK for swap, there is merit in doing the same with tmpfs on linux. We're about to give it a shot and see how it works in practice. Whether you use VDISK or separate tmpfs filesystem, do keep in mind that it will dirty memory buffers at a accelerated rate, so your VM working set sizes will likely increase more rapidly. Splitting out /tmp is more important on systems with interactive shell
Re: BaseVol/GuestVol server for SLES9
Some shops have used it and are using it, I believe. Some have backed away from it. Are people still using basevol/guestvol? It's still valuable, but it's more a hack until we can provide something more sophisticated like unionfs support. Much of what basevol/guestvol does could be done better by unionfs. The book quotes Albert Einstein: Everything should be made as simple as possible, but not simpler. Perhaps a single file system is too simpler Probably. Generally accepted practice in the Unix world separates /, /usr, /var, /opt, /home, and /srv (if used) into distinct filesystems. /etc and /tmp are often also split out, but less commonly. Whether you make them separate LVs or PVs is a religious issue. There are arguments for both. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: BaseVol/GuestVol server for SLES9
On Thu, Jun 21, 2007 at 8:26 AM, in message [EMAIL PROTECTED], Susan Zimmerman [EMAIL PROTECTED] wrote: -snip- Please bear with me (this is still very new to me), but do you put your file systems on their own minidisks and then group them together as one logical volume? Since the file systems will be R/O, is there any harm No. When you go through the install process, you create 1, 2, or 3 partitions on any given DASD volume (or minidisk), and then either assign that partition to become a file system, or an LVM PV (physical volume). If you're going to assign an entire volume to LVM, you only need to create one partition. Once you have all your PVs assigned to LVM, then you start creating your LVs (logical volumes). The space for these will be carved out of the pool you've given LVM. You tell it how much you want for each LV, what file system to put on it, etc. in placing these into an LVM (in the basevol/guestvol scheme)? Is there a way to easily determine the amount to allocate to each file system? I don't know if having an LV R/O is an issue or not. I suspect not, but will be interested in hearing your results. They way I've always determined how much space was needed for what file systems was to lump everything into one big file system (just as the cookbooks describe), and then use the du -csm command to see how much space was used. Then, go back and do the install again. If you use the graphical installer, when you're in the package selection part of the process, it gives you a little window with how much space has been allocated to a particular file system, and how much is in use. It also color codes the graphs so you can tell at a glance if you're getting tight on space, or don't have enough. You can then go back to the partitioning dialog and adjust things there. It only really works with SLES10, but you might want to use the AutoYaST script I posted recently, to get you started. More than likely you'll want to then go and add a second (third, fourth, etc.) DASD volume to the LVM pool (or create a separate one for your application stuff), and parcel the space out as you think necessary. I'm not sure how well, or poorly, the basevol/guestvol scheme will work with SLES10, but I would think it would be fine. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: BaseVol/GuestVol server for SLES9
Probably. Generally accepted practice in the Unix world separates /, /usr, /var, /opt, /home, and /srv (if used) into distinct filesystems. I'm going to have to respectfully disagree. Making separate filesystems without understanding the _reasons_ for making things separate filesystems is not a long-term recipe for success. Most of the reasons are technical and related to the comparatively limited hardware capacity of UNIX systems in the '70s and '80s. Filesystems were split up so that they could fit on the disks which were available at the time, and to simplify backups in an era of ~60 MB tapes and tools no more sophisticated than 'dump'. Now disks are huge and backup tools are sophisticated enough that filesystem dumps seem hopelessly archaic. These are good things, in the big picture. The big drivers for splitting up filesystems these days are to keep users from filling up the wrong disks, and to keep things running smoothly for your operators. There's no reason to make directories which are relatively static and are not subject to being filled by users into separate filesystems. If you're running a server which won't have any users logging into it, making /home a separate filesystem is pointless. It adds to the complexity of maintaining the system without adding a commensurate benefit. If /opt isn't going to have much in it or change very often, there's not a lot of reason to split it into its own filesystem. If, as frequently happens here, nobody knows what the server will look like six months down the road, or what software will be on it, making /opt a separate logical volume---which can be grown as required---is a very good idea. If your site, like ours, isn't ruthlessly efficient at managing logfile sizes, and your operators are basically punished by getting paged whenever root hits 80% at three in the morning, and you can turn the problem into something that can be dealt with in the morning by making /var a separate filesystem, do it. I'd say that today, in general, if you don't know why you're splitting it out, don't split it out. Data, on the other hand, should almost always be separate. Especially if it's data which is not controlled by the system administrators. (i.e., /srv -- a SuSE convention which I personally find loathesome) /etc and /tmp are often also split out, but less commonly. I have never, ever, EVER seen /etc split out, or at least not as anything other than a joke. Off the top of my head I can think of at least four different varieties of UNIX which won't even boot if you do that. Don't do it, it's completely unnecessary and will complicate your life in needless ways. /tmp is a different story. I've always really liked Sun's approach of making it a transient, memory-backed filesystem. It seems that on a hypervisor system like VM, where we are using VDISK for swap, there is merit in doing the same with tmpfs on linux. We're about to give it a shot and see how it works in practice. ok r. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: BaseVol/GuestVol server for SLES9
On Fri, Jun 22, 2007 at 4:30 PM, in message [EMAIL PROTECTED], Stricklin, Raymond J [EMAIL PROTECTED] wrote: Probably. Generally accepted practice in the Unix world separates /, /usr, /var, /opt, /home, and /srv (if used) into distinct filesystems. I'm going to have to respectfully disagree. Making separate filesystems without understanding the _reasons_ for making things separate filesystems is not a long-term recipe for success. As we've seen over and over again on this mailing list, not splitting them out at all is almost a guarantee of short-term problems. If that weren't the case http://linuxvm.org/Info/HOWTOs/movefs.html would not have needed writing. -snip- I'd say that today, in general, if you don't know why you're splitting it out, don't split it out. And here I disagree with you, since that means that almost everyone who's new to the game is almost guaranteed to have problems. Sometimes, following the advice of more experienced people, and gaining understanding of their recommendations later (if they don't come concurrently with the advice) produces far fewer headaches. Data, on the other hand, should almost always be separate. Especially if it's data which is not controlled by the system administrators. (i.e., /srv -- a SuSE convention which I personally find loathesome) I don't think you can blame SUSE for that. I'm pretty sure it's a requirement of LSB. (But, while we're at it, let's condemn /media too. That's equally worthless.) The bottom line for me (and the group I helped lead at EDS) was that a combination of splitting file systems out from the root, and LVM, gave us the maximum amount of flexibility. We could have a standard build that we could start with, and know that at worst, we'd need to tweak the amount of space in one file system or another. All of our systems would look the same, and be managed the same. No big surprises when logging on to one system versus another. We never had a system go down because an OS file system filled up, and if an alert came in for a non-OS file system, we would just bounce it to the appropriate group, since it wasn't our responsibility. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: BaseVol/GuestVol server for SLES9
On Jun 22, 2007, at 3:30 PM, Stricklin, Raymond J wrote: I have never, ever, EVER seen /etc split out, or at least not as anything other than a joke. Off the top of my head I can think of at least four different varieties of UNIX which won't even boot if you do that. Don't do it, it's completely unnecessary and will complicate your life in needless ways. It actually makes some sense on Linux on s390 or s390x. That's because all your machine's personality is in /etc, so you can make / read-only and shared, as long as each machine has its own /etc and /var. Adam -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: BaseVol/GuestVol server for SLES9
Ray, I was in total agreement with you up until you said never ever..ever. with respect to the /etc directory... I know of one UNIX implementation (Unix System Services) on z/OS where the root file system is shared (ro) across all the system in a SYSPLEX. The /etc directory contains system specific configuration files and each system in the SYSPLEX has it's own ZFS/HFS file system mounted off /etc . .. and it boots just fine. Ted Ware Stricklin, Raymond J raymond.j.strick To [EMAIL PROTECTED] LINUX-390@VM.MARIST.EDU Sent by: Linux on cc 390 Port [EMAIL PROTECTED] Subject IST.EDU Re: BaseVol/GuestVol server for SLES9 06/22/2007 04:30 PM Please respond to Linux on 390 Port [EMAIL PROTECTED] IST.EDU Probably. Generally accepted practice in the Unix world separates /, /usr, /var, /opt, /home, and /srv (if used) into distinct filesystems. I'm going to have to respectfully disagree. Making separate filesystems without understanding the _reasons_ for making things separate filesystems is not a long-term recipe for success. Most of the reasons are technical and related to the comparatively limited hardware capacity of UNIX systems in the '70s and '80s. Filesystems were split up so that they could fit on the disks which were available at the time, and to simplify backups in an era of ~60 MB tapes and tools no more sophisticated than 'dump'. Now disks are huge and backup tools are sophisticated enough that filesystem dumps seem hopelessly archaic. These are good things, in the big picture. The big drivers for splitting up filesystems these days are to keep users from filling up the wrong disks, and to keep things running smoothly for your operators. There's no reason to make directories which are relatively static and are not subject to being filled by users into separate filesystems. If you're running a server which won't have any users logging into it, making /home a separate filesystem is pointless. It adds to the complexity of maintaining the system without adding a commensurate benefit. If /opt isn't going to have much in it or change very often, there's not a lot of reason to split it into its own filesystem. If, as frequently happens here, nobody knows what the server will look like six months down the road, or what software will be on it, making /opt a separate logical volume---which can be grown as required---is a very good idea. If your site, like ours, isn't ruthlessly efficient at managing logfile sizes, and your operators are basically punished by getting paged whenever root hits 80% at three in the morning, and you can turn the problem into something that can be dealt with in the morning by making /var a separate filesystem, do it. I'd say that today, in general, if you don't know why you're splitting it out, don't split it out. Data, on the other hand, should almost always be separate. Especially if it's data which is not controlled by the system administrators. (i.e., /srv -- a SuSE convention which I personally find loathesome) /etc and /tmp are often also split out, but less commonly. I have never, ever, EVER seen /etc split out, or at least not as anything other than a joke. Off the top of my head I can think of at least four different varieties of UNIX which won't even boot if you do that. Don't do it, it's completely unnecessary and will complicate your life in needless ways. /tmp is a different story. I've always really liked Sun's approach of making it a transient, memory-backed filesystem. It seems that on a hypervisor system like VM, where we are using VDISK for swap, there is merit in doing the same with tmpfs on linux. We're about to give it a shot and see how it works in practice. ok r
Re: BaseVol/GuestVol server for SLES9
Susan, I'd like to save disk storage as well as simplify maintenance so thought the concept of a basevol/guestvol penguin colony sounded perfect. Some shops have used it and are using it, I believe. Some have backed away from it. Are people still using basevol/guestvol? I'm a relative newbie, so what might be obvious to most administrators is lost on me. Then perhaps you want to start with a simpler approach. I've had discussions about this with Mike before. We don't agree much. I recall one discussion, and yes we agreed to disagree. I believe the main reason Mike does it the way he does is that it simplifies the cloning process/scripts. Simplify, yes, but not really for the cloning script. Cloning 6 file systems instead of 1 should only require an additional 5 function calls to copy_disk(). The main reason we used just a single root file system is because there doesn't seem to be a one size fits all when trying to decide which file systems to break out and how much space to give them. This book was written to get shops going with z/VM and Linux. I know people who have used the books then modified the master (golden) image in a number of different ways. One just went to a single 3390-9 over / (to give 6.9GB of space instead of 2.3GB) and no modification to the clone script was needed. Another added more file systems per Mark's suggestion and modified the cloning process accordingly. The book quotes Albert Einstein: Everything should be made as simple as possible, but not simpler. Perhaps a single file system is too simpler I know some shops are using a number o 3390-3s or maybe a single 3390-9 to create a single volume group. Perhaps 1/2 to 2/3 of that volume group is carved into logical volumes for file systems as Mark suggests. Then if any of the file systems start to fill up, the logical volumes can be dynamically extended. For a while on this list, there was a recommendation to keep the root file system on a conventional file system, not a logical volume. That can still be done while using logical volumes for all other non-root file systems. This is another, more flexible approach, that probably comes under the clause but not simpler. I have been doing work with IBM middleware and find that /opt often needs to be large. I've modifed the cloning process to clone a two volume system: 100 minidisk over / and a 103 over /opt (101 and 102 are VDISK swap spaces). I wrote up that process in cookbook-style steps if anyone is interested. The only way I've built a Linux system is outlined in the Redbook z/VM and Linux on zSeries: From LPAR to Virtual Servers in Two Days There are updated books - see the top three entries on linuxvm.org/present - but they still use just a single root file system. What are other people using for the layout of their master/golden image? Mike MacIsaac [EMAIL PROTECTED] (845) 433-7061 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
BaseVol/GuestVol server for SLES9
Hi Mark, thanks for replying. In my mind, the basevol/guestvol concept replaces the whole cloning philosophy... so laying out the file system now is crucial. Since cloning the basevol won't be necessary, I'd imagine breaking these out into their own file systems may not be an issue...as long as they are R/O. Please bear with me (this is still very new to me), but do you put your file systems on their own minidisks and then group them together as one logical volume? Since the file systems will be R/O, is there any harm in placing these into an LVM (in the basevol/guestvol scheme)? Is there a way to easily determine the amount to allocate to each file system? thanks again... Susan -- Date:Wed, 20 Jun 2007 16:19:36 -0600 From:Mark Post [EMAIL PROTECTED] Subject: Re: BaseVol/GuestVol server for SLES9 On Wed, Jun 20, 2007 at 4:50 PM, in message OF8382A14B.6368F7C0-ON85257300.0070757D-85257300.00727751 @navyfederal.org= , Susan Zimmerman [EMAIL PROTECTED] wrote:=20 -snip- The only way I've built a Linux system is outlined in the Redbook z/VM and Linux on zSeries: From LPAR to Virtual Servers in Two Days. Everything gets installed in / (root)... that is the only mount point (aside from swap) defined. I've had discussions about this with Mike before. We don't agree much. = From my perspective building a system with everything in one file system = is just asking for trouble later on. My standard build breaks out the = following into their own file system: /home /opt /srv (If you're going to be actually putting anything in there. = Alternately you can make /srv/ftp or /srv/www the mount points, but then = you're hiding the stuff that might have gotten installed into the = directories underneath /srv/www) /tmp /usr /var I believe the main reason Mike does it the way he does is that it = simplifies the cloning process/scripts. For this basevol/guestvol setup, do I still only set up one partition on the base volume with the mount point of /?Do I set up any mount point on the guest volume? See above. I presume everything gets installed on the base volume...just not sure about the directories.The HOWTO documents the different directories...but doesn't outline different mount points so I'm not sure how to proceed. The doc instructs to conduct a completely normal installation, following SUSE's instruction. YaST makes it really easy to break out the various file systems, so I = would do that. I normally make my non-root file systems LVM logical = volumes. I'm not sure if that would mess up Bill's basevol/guestvol = scheme or not. (I haven't ever played with it, and I haven't re-read it = in quite a while.) Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
BaseVol/GuestVol server for SLES9
Hi Listers. I'd like to save disk storage as well as simplify maintenance so thought the concept of a basevol/guestvol penguin colony sounded perfect. I'm a relative newbie, so what might be obvious to most administrators is lost on me. I am referencing both the Redbook Large Scale Linux Deployment and the linuxvm.org HOWTO on Using BIND mounts to Create a Simplified BaseVol/GuestVol Linux Server for SLES9. I am installing SLES9 SP3 on a z/VM 5.2 guest (running on a z9 - in case that matters - using ECKD DASD). While I understand the concepts of what needs to be done, the mechanics escape me. The only way I've built a Linux system is outlined in the Redbook z/VM and Linux on zSeries: From LPAR to Virtual Servers in Two Days. Everything gets installed in / (root)... that is the only mount point (aside from swap) defined. For this basevol/guestvol setup, do I still only set up one partition on the base volume with the mount point of /?Do I set up any mount point on the guest volume? I presume everything gets installed on the base volume...just not sure about the directories.The HOWTO documents the different directories...but doesn't outline different mount points so I'm not sure how to proceed. The doc instructs to conduct a completely normal installation, following SUSE's instruction. Thanks in advance for any and all help. susan -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: BaseVol/GuestVol server for SLES9
On Wed, Jun 20, 2007 at 4:50 PM, in message [EMAIL PROTECTED], Susan Zimmerman [EMAIL PROTECTED] wrote: -snip- The only way I've built a Linux system is outlined in the Redbook z/VM and Linux on zSeries: From LPAR to Virtual Servers in Two Days. Everything gets installed in / (root)... that is the only mount point (aside from swap) defined. I've had discussions about this with Mike before. We don't agree much. From my perspective building a system with everything in one file system is just asking for trouble later on. My standard build breaks out the following into their own file system: /home /opt /srv (If you're going to be actually putting anything in there. Alternately you can make /srv/ftp or /srv/www the mount points, but then you're hiding the stuff that might have gotten installed into the directories underneath /srv/www) /tmp /usr /var I believe the main reason Mike does it the way he does is that it simplifies the cloning process/scripts. For this basevol/guestvol setup, do I still only set up one partition on the base volume with the mount point of /?Do I set up any mount point on the guest volume? See above. I presume everything gets installed on the base volume...just not sure about the directories.The HOWTO documents the different directories...but doesn't outline different mount points so I'm not sure how to proceed. The doc instructs to conduct a completely normal installation, following SUSE's instruction. YaST makes it really easy to break out the various file systems, so I would do that. I normally make my non-root file systems LVM logical volumes. I'm not sure if that would mess up Bill's basevol/guestvol scheme or not. (I haven't ever played with it, and I haven't re-read it in quite a while.) Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
