All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick Caulfield <pcaulfie@redhat.com>
To: LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] vgimport/vgexport commands when logically moving disks	between systems
Date: Tue, 05 Dec 2006 10:28:43 +0000	[thread overview]
Message-ID: <457549DB.2080700@redhat.com> (raw)
In-Reply-To: <690999.71486.qm@web51113.mail.yahoo.com>

Dave wrote:
> Hello,
> 
> I believe I might be misunderstanding whether vgimport and vgexport are needed in my
> particular situation.  It would be great to get some feedback for clarification.
> 
> THE SETUP:
> 
> LVM1 (1.0.8-14) on two RedHat AS3 systems (kernel: 2.4.21-47.ELsmp).
> I think the same concept applies for LVM2 as well though.
> Machine A is primary and Machine B is backup in a two-node Linux heartbeat cluster.
> Both machines are connected to the same SAN via fiber, and see the same disks, where
> the volume groups reside.
> 
> THE STRATEGY:
> 
> The idea is for A to have the LVM file systems mounted, and when a failure is
> detected, have the LVM file systems "moved" to (or seen by) system B.  The way this
> is currently accomplished is for A to do the following upon detection of a failure:
> 
> + unmount file systems
> + deactivate (vgchange -an $vg)
> + export (vgexport $vg)
> 
> then, on system B:
> 
> + import & activate (vgimport $vg $disks)
> + mount file systems
> 
> THE ISSUE:
> 
> The export works as expected on A, but upon import on B, a return code of 4 is
> returned meaning "volume group already exists".  The mounting works properly, but
> all the disks are shown like this:
> 
> "inactive PV /dev/sdx  is in EXPORTED VG $vg"  
> 
> when inspected with pvscan.
> 
> 
> Does a vgimport and/or vgexport mark the disks themselves, or simply update the
> system on which the commands are run???  I suppose that is essentially the heart of
> this issue.


Yes, vgimport/export marks the disks in the volume group. It's really for moving disks between systems where the target system might
have a volume group with the same name as the one to be imported.

> I'm starting to believe that for our strategy the vgexport and vgimport commands are
> not necessary, and are actually causing the problem.  (The HOWTO mentions these
> commands are used to move disks between systems, but perhaps that is meant to refer
> to disks that are only physically moved?)
> 
> Instead, the following strategy might be correct in case system A fails (Note: no
> vgimport or vgexport commands):
> 
> + unmount fs
> + vgchange -an $vg
> 
> then, on system B:
> 
> + vgchange -ay $vg
> + mount fs
> 
> 
> IS THIS CORRECT???
> 

Yes. IF YOU'RE VERY CAREFUL!
vgimport/vgexport are not the tools you want for this job.


-- 

patrick

  reply	other threads:[~2006-12-05 10:28 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-05  9:38 [linux-lvm] vgimport/vgexport commands when logically moving disks between systems Dave
2006-12-05 10:28 ` Patrick Caulfield [this message]
2006-12-06 15:12   ` Dave
2006-12-06 15:54     ` Patrick Caulfield
2006-12-14 13:37       ` Dave
2006-12-14 13:49         ` Patrick Caulfield
2006-12-14 15:09           ` Alasdair G Kergon

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=457549DB.2080700@redhat.com \
    --to=pcaulfie@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.