Re: Backup disks RHEL 5.4 operating system
Thanks... 2010/8/9 Alan Altmark > On Saturday, 08/07/2010 at 08:39 EDT, Antonio Silva > wrote: > > I have a zvm 6.1 and several red hat 5.4 under. Backup zvm disks using > the > > backup/restore manager tool. I need to make a reliable backup disks of > the > > Linux operating system. Someone performs these backups reliably and > without > > down the virtual machines. > > If you aren't going to take down the Linux virtual machines, then you must > take the backups using in-Linux utilities such as Tivoli Storage Manager. > If you are running a complex application like a database, then it is > important to use the app-provided utilities to manage backups. You may be > able to create consistent backups on a separate file or disk. If a > separate file, use (e.g.) TSM. If on a separate disk, you have the option > to unmount the disk and then back the disk up using Backup/Restore. > > Alan Altmark > z/VM Development > IBM Endicott > > -- > 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: Shared root and shutdown
I like the writable / with RO /bin, /sbin, /lib, /lib64, /usr. This way if you do get around to charging (yeah old school) for disk space, the customer pays for the writable areas, not the shared RO areas. If the customer needs more space, break out other directories to their own disks (/home, /srv, /var/log, etc). And /usr/local is a symlink to /local so it is their space to write on. Now if I can get this done in VMWare or OVM. /Tom Kern Leland Lucius wrote: > Edmund R. MacKenty wrote: >> BTW: We ended up doing shared-root a bit differently, because we >> wanted to >> have shared filesystems but also wanted / itself to be writable so we >> could >> create mount-points for new filesystems as needed. So we made the >> filesystem >> containing / writable, and put all of /bin, /boot, /lib, /lib64, /sbin >> on a >> read-only filesystem and bind-mounted those directories onto the writable >> filesystem. This gives us more flexibility to make changes as user needs >> evolve over time. But it's the same basic idea. > > Yepper, I gave that a try as well. I'd set up a small 8MB / and did all > of the bind mounts as appropriate. I may still go this route, but it > does add a tad bit more complexity to the setup. No biggie, just trying > to keep it as simple as possible for my initial go round. > > Leland -- 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: mapping zLinux scsi disks to real devices
Thank you too! heheeh, i was looking for it too, but i find it (and a lot more) on redbook SC33-8291-00 ( How to use FC-attached SCSI devices with Linux on System z) On Tue, Aug 10, 2010 at 3:23 PM, Donald Russell wrote: > On Tue, Aug 10, 2010 at 10:41, Sterling James wrote: > >> >I'm running zLinux on zVM and an lsscsi command tells me that /dev/sda is >> at >> [0:0:0:1] >> Try "lszfcp -D" >> >> > Thank you, > > That was the missing link :-) > > -- > 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: Shared root and shutdown
Hm, I didn't think of that when I tried it. IIRC the redbook did mention to replace the /etc/mtab on the / disk with a sym-link but didn't mention to also replace it on the RW disk that is bind mounted. So that's keeping my /etc from umount. Also, I did replace it once and found the boot.rootfsck to remove the mtab (or the link to /proc/mounts) and recreate a new mtab. Yes, that was before the / went RO. After that a link can't be removed obviously. Berry. Op 10-08-10 12:26, Richard Troth schreef: > To get /etc unmounted, you need to make /etc/mtab a sym-link to > something outside of that filesystem. Sym-linking /proc/mounts as > /etc/mtab is the most common way to do this. 'umount' needs to be > able to do its work without the deadlock of "mtab" being open when it > makes the system call. So good practice is to replace /etc/mtab as a > stand alone file with a sym-link to /proc/mounts. > -- 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: Shared root and shutdown
I have been playing with a RO setup. Directories that need to be RW are separate minidisks (/var and /tmp) or they are linked to a directory on the RW disk (/root, /home, /srv). /var is a separate RW disk, even the regular RW systems also have /var on it's own (mini)disk. I didn't test it with lvm just yet but I guess that would not need some temporary bind mount. Or at least we don't see errors on /var/lock/lvm with our full RW systems so I expect the /var disk is mounted before lvm needs it. I don't think in this case it matters if /var is mounted on an RW or an RO rootdisk. Berry. Op 10-08-10 16:03, Leland Lucius schreef: > It was /var/lock/lvm that needed to be bind > mounted to somewhere else temporarily. > > Leland > > -- 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: mapping zLinux scsi disks to real devices
On Tue, Aug 10, 2010 at 10:41, Sterling James wrote: > >I'm running zLinux on zVM and an lsscsi command tells me that /dev/sda is > at > [0:0:0:1] > Try "lszfcp -D" > > Thank you, That was the missing link :-) -- 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: mapping zLinux scsi disks to real devices
>I'm running zLinux on zVM and an lsscsi command tells me that /dev/sda is at [0:0:0:1] Try "lszfcp -D" - Please consider the environment before printing this email and any attachments. This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination, or copying of this e-mail or the information contained in this e-mail is strictly prohibited by the sender. If you have received this transmission in error, please return the material received to the sender and delete all copies from your system. -- 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/
mapping zLinux scsi disks to real devices
I'm running zLinux on zVM and an lsscsi command tells me that /dev/sda is at [0:0:0:1] How do I use that to map it back to a CP directory entry (or whatever) to find what the real device is I could have somebody look at? If this were ECKD dasd I'd be a little more familiar... lsdasd shows the virtual address, a vmcp query tells me the rest of what I need to know... Thanks, Don -- 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: Shared root and shutdown
On Tue, 10 Aug 2010, Edmund R. MacKenty wrote: I'm still wondering what RPM issues with read-only filesystems have been solved. Russ, are there any docs you can point us to on that? I ended up doing essentially what you suggested: letting an admin maintain software on one system using RPM, and having my tool distributing those changes to the many Linux instances it has created, dealing with R/O filesystems in its own way. Some of the the live CD [really, live ISO images] creation tools leave the RPMDB present and intact, even though on RO media, particularly when that live CD (DVD). The process is merely laborious, and once solved readily scriptable, as you and others have noted as in the nicely comprehensive RedBooks mentioned yesterday Install into a DD'd base image, having suitable -bind mounted visibility into /proc/ dev, and /sys under a 2.6 kernel Fix up mount points that need to be RW, to be such Toss a link out of the RO FS for /etc/mtab ;) Adjust the (custom) initrd scripts to do: - rsyncs, cp -a, or other relocations of content that needs to be RW, during the phase one boot (tmpfs is wonderful here) - does the mounts of RW partitions - perhaps do path munges so that the /bin and /sbin/ within the RO come at the end of the search paths under different path names, so that transient or machine image specific rpm updates in the RW space take precedence (ditto libraries -- this is where managing the variant distribution part gets tricky and of course, Rinse, Test, and Repeat -- Russ herrold -- 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: Shared root and shutdown
Edmund R. MacKenty wrote: BTW: We ended up doing shared-root a bit differently, because we wanted to have shared filesystems but also wanted / itself to be writable so we could create mount-points for new filesystems as needed. So we made the filesystem containing / writable, and put all of /bin, /boot, /lib, /lib64, /sbin on a read-only filesystem and bind-mounted those directories onto the writable filesystem. This gives us more flexibility to make changes as user needs evolve over time. But it's the same basic idea. Yepper, I gave that a try as well. I'd set up a small 8MB / and did all of the bind mounts as appropriate. I may still go this route, but it does add a tad bit more complexity to the setup. No biggie, just trying to keep it as simple as possible for my initial go round. Leland -- 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: Shared root and shutdown
On Tuesday 10 August 2010 10:49, Michael MacIsaac wrote: >> All the issues of the RO compoennt >> are long since known and solved, > >Did that include moving the RPM database from /var/lib/rpm/ to somewhere >under /etc/? I'm guessing the answer is "no way", but it just seems out >of place in /var/lib/rpm/. It really does belong under /var/lib, because it is something that is changed by the system. If I remember the FHS correctly, /etc is for system config stuff: namely things an admin makes changes to. /var/lib is for programs to keep state information around in, and I think the RPM database fits that description. I've always thought that LVM maintaining state in /etc/lvm was wrong, but I can understand why they put it there: /var might well not be around when LVM actions need to be performed, but /etc almost has to be. If I had been writing it, I probably would have put it in /dev/lvm instead, because /dev really does have to be there already for LVM to work. I'm still wondering what RPM issues with read-only filesystems have been solved. Russ, are there any docs you can point us to on that? I ended up doing essentially what you suggested: letting an admin maintain software on one system using RPM, and having my tool distributing those changes to the many Linux instances it has created, dealing with R/O filesystems in its own way. - MacK. - Edmund R. MacKenty Software Architect Rocket Software 275 Grove Street · Newton, MA 02466-2272 · USA Tel: +1.617.614.4321 Email: m...@rs.com Web: www.rocketsoftware.com -- 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: Consistency groups for ZLinux Oracle environment
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I expect what you're going to have to do is export your oracle database
to a local filesystem (with the CONSISTENT=Y option) just before your
take your snapcopy, and force a disk flush (sync command). So long as
the dump + flush finishes before the snapcopy, you should be able to
restore oracle from the export.
You can probably arrange your export script to send some form of alert
to your snapcopy process when the export is done, using some of the
tools in the s390utils package ('vmur' and send something to the
account's spool, 'vmcp smsg' ...).
- -- Pat
Graves, Aaron wrote:
> Unless you can shut down the zLinux instance when you take your snapcopy, you
> will always be out of sync.
>
> Aaron
>
> -Original Message-
> From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of Joseph
> Higgins
> Sent: Tuesday, August 10, 2010 8:04 AM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: Consistency groups for ZLinux Oracle environment
>
> Thank you for the reply.
> This is a little different than a straight backup.
> We are using a snapcopy (Flashcopy, TimeFinder, Shadowimage) to take the PIT
> and the Oracle control files and index are not in sync.
>
> Joseph Higgins
> Account Consultant
> HITACHI DATA SYSTEMS
> 90 Park Avenue
> New York, NY 10016
> P 212 827 1343 / C 201 566 6029
>
> joseph.higg...@hds.com
>
>
> -Original Message-
> From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of
> Shockley, Gerard C
> Sent: Tuesday, August 10, 2010 7:59 AM
> To: LINUX-390@vm.marist.edu
> Subject: Re: Consistency groups for ZLinux Oracle environment
>
> Have tried many -:
>
> Use RMAN with the FDR/Upstream interface. Works great.
>
> Several successful recoveries in a wind tunnel (DR site).
>
> Gerard
>
>
> -Original Message-
> From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of David
> Boyes
> Sent: Monday, August 09, 2010 2:34 AM
> To: LINUX-390@vm.marist.edu
> Subject: Re: Consistency groups for ZLinux Oracle environment
>
> How are you taking the backup? If you're using anything but an application
> running inside the virtual machine (eg RMAN to disk, or another app that uses
> the Oracle APIs to get the data), you're going to lose, and you get the
> problem you've observed. The virtual machine probably has loads of stuff in
> RAM which the disk controllers may not know about yet, so your PIT copy is
> missing stuff.
>
> You either have to take the virtual machine down, or do your backups from
> inside the virtual machine. I'd suggest the latter.
>
> --db
>
> On 8/8/10 9:38 PM, "Joseph Higgins" wrote:
>
>> Hello,
>>
>> Is there any way to maintain consistency for point in time copies
>> without suspending the server IO?
>
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkxhb/QACgkQNObCqA8uBswjjACePeMj5ISe0vxkNwZxR6zub5c6
a+AAn3qMfbU9+F3l6l4n0BR1RejA+NOp
=DUK0
-END PGP SIGNATURE-
--
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: Shared root and shutdown
> All the issues of the RO compoennt > are long since known and solved, Did that include moving the RPM database from /var/lib/rpm/ to somewhere under /etc/? I'm guessing the answer is "no way", but it just seems out of place in /var/lib/rpm/. "Mike MacIsaac"(845) 433-7061 -- 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: Shared root and shutdown
On Tuesday 10 August 2010 06:26, Richard Troth wrote:
>On Mon, Aug 9, 2010 at 02:37, Leland Lucius wrote:
>> For you "shared root crazies" out there, how did you get /etc to unmount
>> during shutdown? (on SLES10)
>
>Just kidding. Actually, the trick is to get rid of /etc/mtab. Also,
>as you already noted in your followup, remounting RO is sometimes
>sufficient.
Or, change your umount command to use the -n option, so it doesn't attempt to
write to /etc/mtab at all.
I ran into all these problems a few years back when making my Provisioning
Expert product automate all this shared-root stuff. Here's another trick:
put /etc/{fstab,zipl.conf,passwd,shadow} on the root filesystem because these
are often needed before you get to the point of mounting a read-only /etc.
When you do, the R/O /etc hides those file and processes begin to read them
from the new, R/O filesystem. With this trick, the files are there even when
the /etc/filesystem is not, so the boot and shutdown scripts before and after
you've mounted or unmounted /etc.
You can also play games with having /etc/fstab be different on the /etc
filesystem than on the root filesystem, if you want to have different
filesystem layouts on different instances of Linux. But that can get messy
pretty quickly. I ended up controlling that kind of thing with a pre-init
script that runs before /sbin/init to take care of differences between
instances.
BTW: We ended up doing shared-root a bit differently, because we wanted to
have shared filesystems but also wanted / itself to be writable so we could
create mount-points for new filesystems as needed. So we made the filesystem
containing / writable, and put all of /bin, /boot, /lib, /lib64, /sbin on a
read-only filesystem and bind-mounted those directories onto the writable
filesystem. This gives us more flexibility to make changes as user needs
evolve over time. But it's the same basic idea.
- MacK.
-
Edmund R. MacKenty
Software Architect
Rocket Software
275 Grove Street · Newton, MA 02466-2272 · USA
Tel: +1.617.614.4321
Email: m...@rs.com
Web: www.rocketsoftware.com
--
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: Consistency groups for ZLinux Oracle environment
Unless you can shut down the zLinux instance when you take your snapcopy, you will always be out of sync. Aaron -Original Message- From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of Joseph Higgins Sent: Tuesday, August 10, 2010 8:04 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Consistency groups for ZLinux Oracle environment Thank you for the reply. This is a little different than a straight backup. We are using a snapcopy (Flashcopy, TimeFinder, Shadowimage) to take the PIT and the Oracle control files and index are not in sync. Joseph Higgins Account Consultant HITACHI DATA SYSTEMS 90 Park Avenue New York, NY 10016 P 212 827 1343 / C 201 566 6029 joseph.higg...@hds.com -Original Message- From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of Shockley, Gerard C Sent: Tuesday, August 10, 2010 7:59 AM To: LINUX-390@vm.marist.edu Subject: Re: Consistency groups for ZLinux Oracle environment Have tried many -: Use RMAN with the FDR/Upstream interface. Works great. Several successful recoveries in a wind tunnel (DR site). Gerard -Original Message- From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of David Boyes Sent: Monday, August 09, 2010 2:34 AM To: LINUX-390@vm.marist.edu Subject: Re: Consistency groups for ZLinux Oracle environment How are you taking the backup? If you're using anything but an application running inside the virtual machine (eg RMAN to disk, or another app that uses the Oracle APIs to get the data), you're going to lose, and you get the problem you've observed. The virtual machine probably has loads of stuff in RAM which the disk controllers may not know about yet, so your PIT copy is missing stuff. You either have to take the virtual machine down, or do your backups from inside the virtual machine. I'd suggest the latter. --db On 8/8/10 9:38 PM, "Joseph Higgins" wrote: > Hello, > > Is there any way to maintain consistency for point in time copies > without suspending the server IO? -- 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/ -- 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: Shared root and shutdown
On Tue, 10 Aug 2010, Richard Troth wrote: Russ --- YOU ... are ... SPOOKY How can you remember a date so accurately. 'sent mail' archives and grep, on the confirmation on that lunch -- at Damon's of the Olentangy River Road, with the midrange global Linux architect for another firm here in town ;) It was Steve who suggested making the root RO and shared. I had only been pushing for shared /usr and things. Sun used to share /usr heavily, as I have said many times, so there is precedent in the non-VM and non-z world, so it should not be a weird idea to other Linux developers, distributors, and customers. But Steve took it up a notch and I am hooked. It is a compelling idea, at the expense of some re-jiggering of the initrd, and mounts. The 'deduplication' gain is compelling, and I have repeated the idea on VM work we have done since RPM is (still) the biggest part of the problem. Not RPM per se, but the practices surrounding RPM based packaging. (Same goes for Debian.) For those late to the party, I served as the Editor of the RPM website for many years, and talk daily with the long-time RPM maintainer, Jeff Johnson, who now does consulting work in packaging space (as I do) All the issues of the RO compoennt are long since known and solved, and really the issue is that a distribution packaging strategy designed to meet the needs of 'onsies and twosies' installs, is not well suited for hundreds or thousands of replications. A entity with enough mass to be running more than a couple hundreds instances needs to have packaging skills (in house, or contracted as needed), and basically ends up spinning a 'local rework' of some vendors base [commercially: RH's or SuSE's; community: CentOS, Debian testing, are the best suited], re-jiggered to meet local needs. It is the only sensible to out-compete one's peers in this space -- Russ herrold herr...@owlriver.com herr...@centos.org herr...@pmman.com -- 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: Shared root and shutdown
Richard Troth wrote: There's a bigger picture: avoid open files in /etc altogether (when trying to unmount it). (Your points #2 and #3 in your "nevermind" post also sugggest this.) To that end, while FHS and LSB say that your init scripts should go under /etc/init.d, there's nothing stopping you from making that be a sym-link to /sbin/init.d. (Or any other directory outside of /etc, but there is historical precedent for that one.) YOU MAY NEED to change things like /etc/inittab to point to the "real" location for some things. For example, if you're really running /sbin/init.d/halt instead of /etc/init.d/halt during shutdown, things may go better. I did wind up having to use my "nevermind" method of unmounting the filesystems for another reason. It works pretty well, makes it extremely SLES dependent, but that should be okay for the foreseeable future. I also needed to roll my own killall5 to skip some processes that needed to survive to the final umounts. LVM really has no problem with RO root. What it has a problem with is not being able to write lock files (because the FS where it wants to put its locks is RO). Look in /etc/lvm/lvm.conf and make a suitable change. Yea, I misspoke before. It was /var/lock/lvm that needed to be bind mounted to somewhere else temporarily. Leland -- 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: Shared root and shutdown
Richard Troth wrote: And now I've strayed from Leland's question. Ooopppsss... Was still interesting though. :-) Leland -- 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: Consistency groups for ZLinux Oracle environment
Thank you for the reply. This is a little different than a straight backup. We are using a snapcopy (Flashcopy, TimeFinder, Shadowimage) to take the PIT and the Oracle control files and index are not in sync. Joseph Higgins Account Consultant HITACHI DATA SYSTEMS 90 Park Avenue New York, NY 10016 P 212 827 1343 / C 201 566 6029 joseph.higg...@hds.com -Original Message- From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of Shockley, Gerard C Sent: Tuesday, August 10, 2010 7:59 AM To: LINUX-390@vm.marist.edu Subject: Re: Consistency groups for ZLinux Oracle environment Have tried many -: Use RMAN with the FDR/Upstream interface. Works great. Several successful recoveries in a wind tunnel (DR site). Gerard -Original Message- From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of David Boyes Sent: Monday, August 09, 2010 2:34 AM To: LINUX-390@vm.marist.edu Subject: Re: Consistency groups for ZLinux Oracle environment How are you taking the backup? If you're using anything but an application running inside the virtual machine (eg RMAN to disk, or another app that uses the Oracle APIs to get the data), you're going to lose, and you get the problem you've observed. The virtual machine probably has loads of stuff in RAM which the disk controllers may not know about yet, so your PIT copy is missing stuff. You either have to take the virtual machine down, or do your backups from inside the virtual machine. I'd suggest the latter. --db On 8/8/10 9:38 PM, "Joseph Higgins" wrote: > Hello, > > Is there any way to maintain consistency for point in time copies > without suspending the server IO? -- 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: Consistency groups for ZLinux Oracle environment
Have tried many -: Use RMAN with the FDR/Upstream interface. Works great. Several successful recoveries in a wind tunnel (DR site). Gerard -Original Message- From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of David Boyes Sent: Monday, August 09, 2010 2:34 AM To: LINUX-390@vm.marist.edu Subject: Re: Consistency groups for ZLinux Oracle environment How are you taking the backup? If you're using anything but an application running inside the virtual machine (eg RMAN to disk, or another app that uses the Oracle APIs to get the data), you're going to lose, and you get the problem you've observed. The virtual machine probably has loads of stuff in RAM which the disk controllers may not know about yet, so your PIT copy is missing stuff. You either have to take the virtual machine down, or do your backups from inside the virtual machine. I'd suggest the latter. --db On 8/8/10 9:38 PM, "Joseph Higgins" wrote: > Hello, > > Is there any way to maintain consistency for point in time copies > without suspending the server IO? -- 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: Shared root and shutdown
Russ --- YOU ... are ... SPOOKY How can you remember a date so accurately. It was Steve who suggested making the root RO and shared. I had only been pushing for shared /usr and things. Sun used to share /usr heavily, as I have said many times, so there is precedent in the non-VM and non-z world, so it should not be a weird idea to other Linux developers, distributors, and customers. But Steve took it up a notch and I am hooked. RPM is (still) the biggest part of the problem. Not RPM per se, but the practices surrounding RPM based packaging. (Same goes for Debian.) As it stands, with a RW and unique /etc for each "client", there will still be some things (that which is in a package which falls under /etc) which won't make it into the shared space and which must be handled. I say this is a small enough percentage. But it is greater than zero. People want to use common tools to manage systems. The majority of tools in the market for managing farms of systems still don't accommodate shared content. They tend to sit on top of unaltered distributor schemes which are designed for single systems each with dedicated disk and their own inventory. This leads to the call for de...de...deduplication (and that's just for the storage recoup and doesn't touch the admin scope creep.) And now I've strayed from Leland's question. Ooopppsss... -- R; <>< On Mon, Aug 9, 2010 at 12:59, R P Herrold wrote: > On Mon, 9 Aug 2010, Michael MacIsaac wrote: > >> The first time we wrote about it, based on the work of Rick Troth, Steve >> Womer, et al, (http://www.redbooks.ibm.com/abstracts/redp4322.html) /etc/ >> was bind-mounted, and glancing through the paper quickly, I don't see >> anything specific to umount it during shutdown. Perhaps Rick could >> elaborate. > > Spooky to see how it turned out -- I feel like an enabler; I > went to lunch with Steve and Rick 23 March 2006 to suggest > approaches within the RPM package management system to enable > such an approach ;) > > -- Russ herrold > > -- > 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: Shared root and shutdown
You don't. Just kidding. Actually, the trick is to get rid of /etc/mtab. Also, as you already noted in your followup, remounting RO is sometimes sufficient. * details * To get /etc unmounted, you need to make /etc/mtab a sym-link to something outside of that filesystem. Sym-linking /proc/mounts as /etc/mtab is the most common way to do this. 'umount' needs to be able to do its work without the deadlock of "mtab" being open when it makes the system call. So good practice is to replace /etc/mtab as a stand alone file with a sym-link to /proc/mounts. There's a bigger picture: avoid open files in /etc altogether (when trying to unmount it). (Your points #2 and #3 in your "nevermind" post also sugggest this.) To that end, while FHS and LSB say that your init scripts should go under /etc/init.d, there's nothing stopping you from making that be a sym-link to /sbin/init.d. (Or any other directory outside of /etc, but there is historical precedent for that one.) YOU MAY NEED to change things like /etc/inittab to point to the "real" location for some things. For example, if you're really running /sbin/init.d/halt instead of /etc/init.d/halt during shutdown, things may go better. LVM really has no problem with RO root. What it has a problem with is not being able to write lock files (because the FS where it wants to put its locks is RO). Look in /etc/lvm/lvm.conf and make a suitable change. If you're going to hack your own tiny RW root, you might want to redux a little and craft your own INITRD instead. Maint gets to be a problem. (From my perspective, reconciling /etc with maint is less of a pain; but not all agree.) CONVERSLY, for virtual environments, the current INITRD use ... well ... it seems inelegant or at least inconsistent. (Virtual systems and embedded systems have some common attributes. INITRD is not the only way to get bootstrapped.) -- R; <>< On Mon, Aug 9, 2010 at 02:37, Leland Lucius wrote: > For you "shared root crazies" out there, how did you get /etc to unmount > during shutdown? (on SLES10) > > I've been tinkering around with this and everything works well except > that it won't unmount /etc during shutdown since it's in use by the "rc" > script(s) when boot.localfs runs. And since /etc is a read/write mount, > I'd rather not pull the rug out from under it. > > Well, I'm actually fibbing just a little since I did find a way to do it > cleanly, but it's not pretty. So I was hoping to either find out I was > doing something wrong or if it's just the way it is. > > Thanks, > > Leland > > -- > 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/
