All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Tuijnman <daniel@velotype.nl>
To: LVM general discussion and development <linux-lvm@redhat.com>
Subject: LVM UUID generation (was Re: [linux-lvm] Question on duplicating equally-sized HDs with dd and changing VG name and PV UUIDs)
Date: Wed, 12 Sep 2007 02:21:19 +0200	[thread overview]
Message-ID: <20070912002119.GA1980@velotype.nl> (raw)
In-Reply-To: <20070911101250.GB26592@heitec.net>

[-- Attachment #1: Type: text/plain, Size: 1137 bytes --]

> (I don't want't to forcefully recreate a PV, I just want to be able to
> assign a different UUID to it in order keep LVM from "thinking" that PV
> still belongs to some other VG).
> 
> But, on the other hand, I also just noticed that the UUIDs of PVs, VGs, LVs
> are formatted differently from those generated by uuidgen. Or can LVM also
> use UUIDs that are formatted differently?

In my experience: no. I ran into the same some time ago with a similar
problem: I wanted to be able to clone LV's which I use as disk for Xen-VM's.
Of course, within the LV I also use a VG to partition the disk.

Attached is my script for automating this. I didn't know at the time about
uuidgen, so I used some Perl to generate a UUID and then to massage it into
the LVM UUID format.

> So, my question about a UUID generation tool for proper UUID usage within
> LVM seems to be still valid...

I'd be very anxious to know about this too.

-- 
Dani�l Tuijnman                     phone:  +31-24-377.7329
De Voorstenkamp 19-59               mobile: +31-6-4611.4589
NL-6545 GR Nijmegen                 fax:    +31-24-373.3632

[-- Attachment #2: clone_lvm --]
[-- Type: text/plain, Size: 4414 bytes --]

#!/bin/bash
#
# Daniel Tuijnman
# Fri Mar  2 20:34:13 CET 2007
#
# This script clones a LVM based paravirtualized Xen-VM
# it makes a number of assumptions:

# 1. The single disk of the VM is in a Volume Group VG_domU
VMBASE="/dev/VG_domU"

# 2. The VM disk contains two partitions:
#    (1) /boot
#    (2) a single Physical Volume for the Volume Group in the VM disk
BOOTPART=1
PVPART=2

# 3. The root filesystem of the VM is in a LV called 'root'
ROOTLV="root"

# 4. The name of the Volume Group on the VM disk is the name of the Xen-VM
# with "VG_" prepended
function vm_to_vg {
    echo "VG_$1"
}

# 5. the VM boots the first kernel present in the grub.conf
# (no variables to change here, sorry)

# set paranoia mode
set -eu
# set debug mode
# set -x

function cleanup {
    echo "Cleaning up on exit"
    umount "$MNTBOOT" || true
    umount "$MNT" || true
    vgchange -a n "$SRC_VOLG" || true
    vgchange -a n "$DST_VOLG" || true
    kpartx -d "$DST_VM"
    vgscan
    return
    /bin/rm -rf "$CFGFILE" "$NEWCFGFILE" "$MNT" "$INITRDDIR"
}

# test input
if (( $# != 2 )); then
    echo "$0: wrong number of arguments" >&2
    echo "$0: usage: $0 <src-lvm> <dst-lvm>" >&2
    exit 1
fi

SRC="$1"
DST="$2"
SRC_VM="${VMBASE}/${SRC}"
DST_VM="${VMBASE}/${DST}"

if [[ ! -b "$SRC_VM" ]]; then
    echo "$0: source LV does not exist" >&2
    exit 2
fi

if [[ ! -b "$DST_VM" ]]; then
    echo "$0: destination LV does not exist, will be created" >&2
    SIZE=$(lvs --noheadings --units m -o lv_size "$SRC_VM")
    lvcreate -v -L $SIZE -n "$DST" "$VMBASE"
else
    echo "$0: warning: destination LV will be overwritten" >&2
    echo "$0: you have 5 seconds to bail out" >&2
    sleep 5
fi

# set various variables
SRC_VOLG=$(vm_to_vg "$SRC")
echo "Source VolGroup: $SRC_VOLG"
DST_VOLG=$(vm_to_vg "$DST")
echo "Destination VolGroup: $DST_VOLG"
CFGFILE="/tmp/vgcfg$$"
DST_BOOT="/dev/mapper/${DST}p${BOOTPART}"
DST_ROOT="$DST_VOLG/$ROOTLV"
DST_PV="/dev/mapper/${DST}p${PVPART}"
MNT="/tmp/mnt$$"
MNTBOOT="$MNT/boot"
INITRDDIR="/tmp/initrd$$"
mkdir "$MNT"
mkdir "$INITRDDIR"
trap cleanup EXIT ERR SIGQUIT SIGINT

# now start with the real work
echo "$0: copying LV contents" >&2
echo "$0: this may take some time" >&2
dd if="$SRC_VM" of="$DST_VM"

# make device nodes for partitions on destination VM
kpartx -a "$DST_VM"
# read VG's and backup the current config
# (VG is still SRC named!)
vgscan
vgchange -a y "$SRC_VOLG"
vgcfgbackup -f "$CFGFILE" "$SRC_VOLG"
vgchange -a n "$SRC_VOLG"

# create new UUIDs for the PV, the VG and the LV's
# for the PV, we use pvchange to also change it on disk
# and subsequently, pvs to read the new UUID
# LVM UUID's are not official UUID's, so we have to massage
# the output of the Perl modules
perl -pi -e '
    BEGIN {
        use Data::UUID;
        $uuid = new Data::UUID;
        $physvol = 0;
    }
    if ( /physical_volumes/ ) { $physvol = 1 }
    if ( /logical_volumes/  ) { $physvol = 0 }
    if ( /^\s*id\s*\=\s*\"([A-Za-z0-9-]+)\"\s*$/ ) {
        my $newuuid;
        if ( $physvol ) {
            system "pvchange", "-u", "'"$DST_PV"'";
            $newuuid = qx!pvs --noheadings --options pv_uuid '"$DST_PV"'!;
            $newuuid =~ s/\s//g;
        } else {
            $newuuid = $uuid->create_str();
            $newuuid =~ s/(\w\w)-/-$1/g;
            $newuuid =~ s/(\w{4})(\w{6})$/-$1-$2/;
        }
        s/$1/$newuuid/;
    }
' "$CFGFILE";

# restore the VG and rename it
echo "Restoring volume group" >&2
vgcfgrestore -f "$CFGFILE" "$SRC_VOLG"
echo "Renaming volume group" >&2
vgrename "$SRC_VOLG" "$DST_VOLG"

# now change the VG name in the three places it's mentioned:
# 1 /etc/fstab
# 2 /boot/grub/grub.conf
# 3 'init' on the initrd...

vgchange -a y "$DST_VOLG"
mount "/dev/$DST_VOLG/$ROOTLV" "$MNT"
mount "$DST_BOOT" "$MNTBOOT"

# /etc/fstab
ed -s "$MNT/etc/fstab" <<-EDEND
	1,\$s/$SRC_VOLG/$DST_VOLG/
	w
	q
EDEND
# /boot/grub/grub.conf
ed -s "$MNTBOOT/grub/grub.conf" <<-EDEND
	1,\$s/$SRC_VOLG/$DST_VOLG/
	w
	q
EDEND
# 'init' on initrd
# first, what's the right initrd to change?
INITRD=$(sed -n '/^[ 	]*initrd/{
	s/[ 	]*initrd[ 	]*//
	p
	q
}' "$MNTBOOT"/grub/grub.conf)

cd "$INITRDDIR"
zcat "$MNTBOOT/$INITRD" | cpio -i
ed -s init <<-EDEND
	1,\$s/$SRC_VOLG/$DST_VOLG/
	w
	q
EDEND
find . | cpio -o -H newc | gzip > "$MNTBOOT/$INITRD"

# finally, wrap up
umount "$MNTBOOT"
umount "$MNT"
vgchange -a n "$DST_VOLG"
kpartx -d "$DST_VM"
vgscan
exit 0


  reply	other threads:[~2007-09-12  0:21 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-07 12:13 [linux-lvm] Question on duplicating equally-sized HDs with dd and changing VG name and PV UUIDs Holger Rauch
2007-09-07 17:53 ` Lars Ellenberg
2007-09-10  8:59   ` Holger Rauch
2007-09-10 17:17     ` malahal
2007-09-11 10:00       ` Holger Rauch
2007-09-11 10:12         ` Holger Rauch
2007-09-12  0:21           ` Daniel Tuijnman [this message]
2007-09-17 21:19           ` Alasdair G Kergon
2007-09-19 16:04             ` Holger Rauch

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070912002119.GA1980@velotype.nl \
    --to=daniel@velotype.nl \
    --cc=linux-lvm@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.