The problem all this is trying to get around is that, if you define a system that brings up, say, minidisks at 391, 392 and 393, they become /dev/dasda, dasdb and dasdc. Now you add a new minidisk at 291.... If the system puts this at the end of the list, then it would become /dev/dasdd, and this would happen when you add the disk into the running system. But, what if, when you re-boot the entire image, it now finds this disk first? It could become /dev/dasda, pushing the other disks each up one letter, and causing your fstab and other things to fail miserably.
But, minidisk 391 is (or at least, should be) always 391, no matter if it is /dev/dasda or /dev/dasdb. Which ever it is, you know you want it to be your root filesystem (or your /boot, or whatever). You don't care a smidge about the letter it lives at. This is where /dev/disk/by-path comes in. You can use this to identify the disk by its CUU address in the virtual machine. Suddenly, you're immune to new disks added at random addresses. The /dev/disk/by-id would be used for the wild and insane among us, that want to change around the minidisk addresses randomly between boots. There's also by-uuid... I think this one is looking at some internal field in the disk's label, but I've no research to back up that statement. Note that if you use LVM for the majority of your system, then this whole issue is only relevant for the /boot disk (and possibly the root filesystem; depends on whose rules you follow). LVM uses the disk's uuid to locate the physical volumes that make up a volume group, and sets everything up accordingly. -- Robert P. Nix Mayo Foundation .~. RO-OE-5-55 200 First Street SW /V\ 507-284-0844 Rochester, MN 55905 /( )\ ----- ^^-^^ "In theory, theory and practice are the same, but in practice, theory and practice are different." On 2/29/08 12:33 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > Managled is understated. If it said partitions instead of disks it might > make more sense to me. But in my case, I have only one volume/dasd/disk > with 1 boot partition and 1 logical volume partition. So when you bring a > cloned volume/dasd/disk online he must compare the NEW "real addr" to the > by-id label. But, if use by-path he doesn't? Sorry still a little confused > about this. What is wrong with old naming conventions? > > > > > > "Romanowski, John > (OFT)" > <John.Romanowski@ To > oft.state.ny.us> [email protected] > Sent by: The IBM cc > z/VM Operating > System Subject > <[EMAIL PROTECTED] Re: error bringing up cloned system > ARK.EDU> > > > 02/29/2008 11:53 > AM > > > Please respond to > The IBM z/VM > Operating System > <[EMAIL PROTECTED] > ARK.EDU> > > > > > > > Novell's sles 10 sp1 release notes actually give a mangled attempt to > alert one to this z/VM mdisk issue. > When they ran the original text thru the translator to English it must > have substituted 'disk' for the non-dictionary 'mdisk' words in these > sentences: > > "Using Disks in z/VM > If SLES 10 is installed on disks in z/VM, which reside on the same > physical disk, the created access path (/dev/disk/by-id/) is not unique. > The ID of a disk is the ID of the underlaying disk. So if two or more > disk are on the same physical disk, they all have the same ID. > > To avoid this ambiguity, please use the access path by-path. This can be > specified during the installation when the mount points are definied. > > To change from by-id to by-path please perform the following steps: > > > Modify /etc/zipl.conf to use by-path names, example: > parameters = "root=/dev/disk/by-path/ccw-0.0.0201-part1 TERM=dumb" > Have the boot configuration pick up the changes: > mkinitrd > zipl -V > Change all by-id entries in /etc/fstab to by-path entries as well, > example: > /dev/disk/by-path/ccw-0.0.0201-part1 / ext3 acl,user_xattr 1 1 > reboot to pick up changes" > > > > > -------------------------------------------------------- > This e-mail, including any attachments, may be confidential, privileged or > otherwise legally protected. It is intended only for the addressee. If you > received this e-mail in error or from someone who was not authorized to > send it to you, do not disseminate, copy or otherwise use this e-mail or > its attachments. Please notify the sender immediately by reply e-mail and > delete the e-mail from your system. > > > -----Original Message----- > > From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On > Behalf Of Hilliard, Chris > Sent: Friday, February 29, 2008 8:14 AM > To: [email protected] > Subject: Re: error bringing up cloned system > > I ran into this problem as well. I went back and re-installed my master > image. When I got to the partitioning step, I changed the FSTAB options > for dev/dasdx to use "device-name" instead of "device-id". I'm not sure > what one selection has over the other but it sure makes cloning a lot > easier. > > -----Original Message----- > From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On > Behalf Of [EMAIL PROTECTED] > Sent: Thursday, February 28, 2008 5:49 PM > To: [email protected] > Subject: error bringing up cloned system > > Does anyone know what I did wrong here. DDR'd new SLES10 -sp1 system and > now receive the following IPL errors.. After the DDR I correctly relabel > the pack to reflect its real addr as usual, define the pack to another > guest machine and modify the mdisk to match the original. This time it > does not work. I took the SLES defaults for installation for storage > Device > names. If I knew if this info was in a Yast log I could try to find it, > if > it would help. > > Waiting for udev to settle... > Scanning for LVM volume groups... > Reading all physical volumes. This may take a while... > Found volume group "system" using metadata type lvm2 > Activating LVM volume groups... > 1 logical volume(s) in volume group "system" now active > ..done > Waiting for /dev/disk/by-id/ccw-IBM.75000000029217.2500.2e-part1 . > no more events > Checking file systems... > fsck 1.38 (30-Jun-2005) > Checking all file systems. > error on stat() /dev/disk/by-id/ccw-IBM.75000000029217.2500.2e-part1: No > such f > [/sbin/fsck.ext3 (1) -- /boot] fsck.ext3 -a > /dev/disk/by-id/ccw-IBM.75000000029 > error on stat() /dev/disk/by-id/ccw-IBM.75000000029217.2500.2e-part1: No > such f > fsck.ext3: No such file or directory while trying to open > /dev/disk/by-id/ccw-I > /dev/disk/by-id/ccw-IBM.75000000029217.2500.2e-part1: > /dev/disk/by-id/ccw-IBM.75000000029217.2500.2e-part1: > The superblock could not be read or does not describe a correct ext2 > filesystem. If the device is valid and it really contains an ext2 > filesystem (and not swap or ufs or something else), then the superblock > is corrupt, and you might try running e2fsck with an alternate > superblock: > e2fsck -b 8193 <device> > fsck.ext3 /dev/disk/by-id/ccw-IBM.75000000029217.2500.2e-part1 failed > (status 0 > [1A..failedblogd: no message logging because /var file system is not > accessible > fsck failed for at least one filesystem (not /).
