Jeff Jensen wrote:
> Hi,
>
> I really messed up LVM on my backup server. I'm really out of my depth with
> this, and seriously need help. I've been trying to figure it out the past
> few hours. I know what I did, but not sure if I did what I intended nor how
> to correct it.
>
> Currently the system won't boot (Fedora 11). I can boot the install CD and
> use Rescue System option to get a shell. Files et al are there.
>
> The system was low on space, so I added a new drive. It already had 3
> drives, so I intended to move extents from 2 drives to the new drive so I
> can remove the 2 drives. I believe I successfully moved them using the
> Partition Manager tool. Too easy in fact!
>
I think you might have made the big mistake here. Did you plan on
adding the new drive as part of the LV, or just have it as a stand alone
drive? Simply copying the data for the two drive to the new third,
yanking out the former two, and rebooting is a bad deal.
To take a disk out of service it must first have all of its active
physicalextents moved to one or more of the remaining disks in the
volume group. There must be enough free physical extents in the
remaining PVs to hold the extents to be copied from the old disk.
Here is a small exerp from the LVM-HOW to
13.5. Removing an Old Disk
Say you have an old IDE drive on /dev/hdb. You want to remove that
old disk
but a lot of files are on it.
Caution Backup Your System
You should always backup your system before attempting a pvmove
operation.
-----------------------------------------------------------------------------
13.5.1. Distributing Old Extents to Existing Disks in Volume Group
If you have enough free extents on the other disks in the volume
group, you
have it easy. Simply run
# pvmove /dev/hdb
pvmove -- moving physical extents in active volume group "dev"
pvmove -- WARNING: moving of active logical volumes may cause data loss!
pvmove -- do you want to continue? [y/n] y
pvmove -- 249 extents of physical volume "/dev/hdb" successfully moved
This will move the allocated physical extents from /dev/hdb onto the rest of
the disks in the volume group.
Note pvmove is Slow
Be aware that pvmove is quite slow as it has to copy the contents
of a
disk block by block to one or more disks. If you want more steady
status
reports from pvmove, use the -v flag.
-----------------------------------------------------------------------------
13.5.1.1. Remove the unused disk
We can now remove the old IDE disk from the volume group.
# vgreduce dev /dev/hdb
vgreduce -- doing automatic backup of volume group "dev"
vgreduce -- volume group "dev" successfully reduced by physical volume:
vgreduce -- /dev/hdb
The drive can now be either physically removed when the machine is next
powered down or reallocated to other users.
-----------------------------------------------------------------------------
13.5.2. Distributing Old Extents to a New Replacement Disk
If you do not have enough free physical extents to distribute the old
physical extents to, you will have to add a disk to the volume group and
move
the extents to it.
-----------------------------------------------------------------------------
13.5.2.1. Prepare the disk
First, you need to pvcreate the new disk to make it available to LVM. In
this recipe we show that you don't need to partition a disk to be able
to use
it.
# pvcreate /dev/sdf
pvcreate -- physical volume "/dev/sdf" successfully created
-----------------------------------------------------------------------------
13.5.2.2. Add it to the volume group
As developers use a lot of disk space this is a good volume group to
add it
into.
# vgextend dev /dev/sdf
vgextend -- INFO: maximum logical volume size is 255.99 Gigabyte
vgextend -- doing automatic backup of volume group "dev"
vgextend -- volume group "dev" successfully extended
-----------------------------------------------------------------------------
13.5.2.3. Move the data
Next we move the data from the old disk onto the new one. Note that it is
not necessary to unmount the file system before doing this. Although it is *
highly* recommended that you do a full backup before attempting this
operation in case of a power outage or some other problem that may interrupt
it. The pvmove command can take a considerable amount of time to
complete and
it also exacts a performance hit on the two volumes so, although it isn't
necessary, it is advisable to do this when the volumes are not too busy.
# pvmove /dev/hdb /dev/sdf
pvmove -- moving physical extents in active volume group "dev"
pvmove -- WARNING: moving of active logical volumes may cause data loss!
pvmove -- do you want to continue? [y/n] y
pvmove -- 249 extents of physical volume "/dev/hdb" successfully moved
-----------------------------------------------------------------------------
13.5.2.4. Remove the unused disk
We can now remove the old IDE disk from the volume group.
# vgreduce dev /dev/hdb
vgreduce -- doing automatic backup of volume group "dev"
vgreduce -- volume group "dev" successfully reduced by physical volume:
vgreduce -- /dev/hdb
The drive can now be either physically removed when the machine is next
powered down or reallocated to some other users.
> I then removed the 2 drives from the LV and rebooted. It fails of course -
> I see the POST, then some initial messages, and then it hangs with a blank
> screen.
>
> I've reviewed lvm CLI commands, looked at statuses, and even tried restoring
> from the automatically created LVM archive files (vgcfgrestore). I'm not
> sure that that works from the shell, as when I reboot again (not using the
> rescue), the lvm cfg is the same (pvdisplay).
Everything works from the shell, and IMHO it is the gui tool that lead
you to trouble.
>
> Does anyone have suggestions on how to proceed to fix this?
try this:
REPLACING PHYSICAL VOLUMES
vgdisplay --partial --verbose will show you the UUIDs and sizes of
any PVs
that are no longer present. If a PV in the VG is lost and you wish to
substitute another of the same size, use
pvcreate --restorefile filename --uuid uuid (plus additional arguments as
appropriate) to initialize it with the same UUID as the missing PV.
Repeat for all other missing PVs in the VG. Then use
vgcfgrestore --file filename to restore the volume group’s metadata.
Good Luck!
B-o-B
>
>
>
> _______________________________________________
> TCLUG Mailing List - Minneapolis/St. Paul, Minnesota
> tclug-list at mn-linux.org
> http://mailman.mn-linux.org/mailman/listinfo/tclug-list
--
We are building a fighting force of extraordinary magnitude.
We forge our tradition in the spirit of our ancestors.
You have our gratitude.
Those who oppose us will be sent to Detroit.