From: "Bryn M. Reeves" <breeves@redhat.com>
To: LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] vgimport without vgexport (hardware crash)
Date: Tue, 18 Mar 2008 16:02:53 +0000 [thread overview]
Message-ID: <47DFE7AD.9000206@redhat.com> (raw)
In-Reply-To: <07774C6E31D94A44A2A60E2085944F0901398E92@tbmail.tradebot.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Taylor Lewick wrote:
> Should that server suffer a hardware failure, we?d like to connect up a
> standby server to take its place.
>
> So in the event of a bad hardware failure, I won?t be able to unmount
> the filesystems, vgchange ?an, and vgexport the volume groups.
>
> Can I expect a vgscan and vgimport to work on the new server if I wasn?t
> able to run vgexport? Any other data I would need to make this work?
Yes - this isn't a problem with LVM2 - you'll be able to activate the VG
on any other host that can see the storage by issuing a vgchange.
The vgimport/vgexport just toggle a flag in the LVM2 metadata that marks
the VG status and PV statuses as imported or exported, e.g.:
Before exporting t0:
t0 {
id = "ecajMI-eLGR-5Gmn-T3KG-f3Ey-4JkR-VIQGh0"
seqno = 1
status = ["RESIZEABLE", "READ", "WRITE"]
[...]
physical_volumes {
pv0 {
id = "5LgAWX-Qc1q-e3IB-ak8P-EkEK-uY0q-Ar3Im6"
device = "/dev/loop0" # Hint only
status = ["ALLOCATABLE"]
[...]
}
}
}
After exporting t0:
t0 {
id = "ecajMI-eLGR-5Gmn-T3KG-f3Ey-4JkR-VIQGh0"
seqno = 2
status = ["EXPORTED", "RESIZEABLE", "READ", "WRITE"]
[...]
physical_volumes {
pv0 {
id = "5LgAWX-Qc1q-e3IB-ak8P-EkEK-uY0q-Ar3Im6"
device = "/dev/loop0" # Hint only
status = ["ALLOCATABLE", "EXPORTED"]
[...]
}
}
}
The tools won't allow you to change the VG while it's exported, e.g.:
# lvcreate -n foo -L 10M t0
Volume group t0 is exported
But it's fine to activate and use a VG previously created/used on
another host without doing the vgexport step first - the HA LVM service
in Red Hat Cluster Suite uses this for e.g. since it's not always
possible to cleanly export the VG when a node dies. We just change the
host tags used on the VG and activate it on the new node.
You might still need to fsck file systems if they weren't unmounted
cleanly but from LVM2's side it should be fine.
Regards,
Bryn.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFH3+et6YSQoMYUY94RAjtWAKDhho6glzvP8+LkvlVf2IUPUdsZkwCfVI5f
mc60NA1vw1AFXaGSDuQg9Ew=
=vC7h
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2008-03-18 16:11 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-18 16:00 [linux-lvm] vgimport without vgexport (hardware crash) Taylor Lewick
2008-03-18 16:02 ` Bryn M. Reeves [this message]
2008-03-28 12:40 ` Taylor Lewick
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=47DFE7AD.9000206@redhat.com \
--to=breeves@redhat.com \
--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.