All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: [linux-lvm] Exposing the same VG from two different disks
@ 2009-06-17 14:27 liam
  2009-06-17 15:48 ` [linux-lvm] " Mike Snitzer
  2009-06-19  4:39 ` [linux-lvm] " chris procter
  0 siblings, 2 replies; 3+ messages in thread
From: liam @ 2009-06-17 14:27 UTC (permalink / raw)
  To: linux-lvm

I've had a closer look at the vgimportclone script and I think the fix for the
 lost filter is very straight forward. The errors are coming out of the final
 vgscan and it seems to be caused by the LVM_SYSTEM_DIR variable being set to an 
empty string rather than being unset. So I made the following change and it seemed 
to fix the errors...

327,333c327
<
< if [[ -z ${ORIG_LVM_SYS_DIR} ]]
< then
<       unset LVM_SYSTEM_DIR
< else
<       LVM_SYSTEM_DIR=${ORIG_LVM_SYS_DIR}
< fi
---
> LVM_SYSTEM_DIR=${ORIG_LVM_SYS_DIR}

I'm not sure if this change causes any issues but I'd be suprised.
Thanks
Liam

>Thanks to everyone who replied. The vgimportclone worked really well and I can 
>recommend it to anyone who is in my situation. 
>
>I have a follow up question about how the LVM filter works in the script. 
>Should I post here or to the LVM Devel list instead?
>
>Just in case here is the right place !!! My question is, I have multiple paths 
>to the same disks so I have masked the individual paths (the sd devices) and 
>just exposed the logical deives (the emcpower devices). The script loses this 
>filter and complains about lots of duplicate PV ids as it runs through. This 
>"problem" is purely cosmetic and doesn't seem to in anyway effect the script 
>from working. If this is not expected behaviour and the fix is fairly straight 
>forward I'd be more than happy to test any fix. I've had a look at trying to 
>see where the errors are coming from but I have to admit my LVM knowledge 
>isn't up to it.
>
>Thanks again to everyone for their hope,
>Liam
>
>
>
>>On Fri, 2009-06-05 at 15:18 +0200, liam@landv.org.uk wrote:
>>> Hi,
>>> 
>>> I'm not sure if what I'm trying to do is possible or not but hopefully
>>>  someone out there can help!!
>>> 
>>> I have a volume group which consists of a LUN (/dev/emcpowerv1) in an
>>>  EMC cabinet. To backup up the disk I use EMC technology to synchronise
>>>  a second LUN (/dev/emcpoweraf1) with the first, when the
>>>  synchronisation is complete I then break the connection. At this point
>>>  I have two identical volume groups exposed to the same host. What I
>>>  would like to do is rename the second volume group and mount its
>>>  logical volumes. However I can't because (understandably) LVM doesn't
>>>  like having two identical volume groups so when I issue pvchange -u I
>>>  get...
>>> 
>>> 
>>> # pvchange -u /dev/emcpoweraf1
>>>   Found duplicate PV dXiYI6nVqu8UpXO2mlaWiKKPKSBPrRbn: using 
>/dev/emcpowerv1 
>>not /dev/emcpoweraf1
>>>   get_pv_from_vg_by_id: vg_read failed to read VG !
>>>   /dev/emcpowerv1: write failed after 0 of 4096 at 4096: Operation not 
>>permitted
>>>   pv_write with new uuid failed for /dev/emcpowerv1.
>>>   0 physical volumes changed / 1 physical volume not changed
>>> 
>>> Notice I issue the command against /dev/emcpoweraf1 but it complains about 
>
>>writing to /dev/emcpowerv1.
>>
>>Take a look at the vgimportclone script posted to the lvm-devel list
>>last month:
>>
>>http://www.redhat.com/archives/lvm-devel/2009-May/msg00130.html
>>
>>Regards,
>>Bryn.
>>
>>
>>_______________________________________________
>>linux-lvm mailing list
>>linux-lvm@redhat.com
>>https://www.redhat.com/mailman/listinfo/linux-lvm
>>read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>
>_______________________________________________
>linux-lvm mailing list
>linux-lvm@redhat.com
>https://www.redhat.com/mailman/listinfo/linux-lvm
>read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [linux-lvm] Re: Exposing the same VG from two different disks
  2009-06-17 14:27 [linux-lvm] Exposing the same VG from two different disks liam
@ 2009-06-17 15:48 ` Mike Snitzer
  2009-06-19  4:39 ` [linux-lvm] " chris procter
  1 sibling, 0 replies; 3+ messages in thread
From: Mike Snitzer @ 2009-06-17 15:48 UTC (permalink / raw)
  To: liam; +Cc: linux-lvm

On Wed, Jun 17 2009 at 10:27am -0400,
liam@landv.org.uk <liam@landv.org.uk> wrote:

> I've had a closer look at the vgimportclone script and I think the fix for the
>  lost filter is very straight forward. The errors are coming out of the final
>  vgscan and it seems to be caused by the LVM_SYSTEM_DIR variable being set to an 
> empty string rather than being unset. So I made the following change and it seemed 
> to fix the errors...
> 
> 327,333c327
> <
> < if [[ -z ${ORIG_LVM_SYS_DIR} ]]
> < then
> <       unset LVM_SYSTEM_DIR
> < else
> <       LVM_SYSTEM_DIR=${ORIG_LVM_SYS_DIR}
> < fi
> ---
> > LVM_SYSTEM_DIR=${ORIG_LVM_SYS_DIR}
> 
> I'm not sure if this change causes any issues but I'd be suprised.

Liam,

Looks good, I've committed your fix along with various other fixes to
vgimportclone.

Thanks,
Mike

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [linux-lvm] Exposing the same VG from two different disks
  2009-06-17 14:27 [linux-lvm] Exposing the same VG from two different disks liam
  2009-06-17 15:48 ` [linux-lvm] " Mike Snitzer
@ 2009-06-19  4:39 ` chris procter
  1 sibling, 0 replies; 3+ messages in thread
From: chris procter @ 2009-06-19  4:39 UTC (permalink / raw)
  To: LVM general discussion and development




> I've had a closer look at the vgimportclone script and I think the fix for the
> lost filter is very straight forward. The errors are coming out of the final
> vgscan and it seems to be caused by the LVM_SYSTEM_DIR variable being set to an 
> empty string rather than being unset. So I made the following change and it 
> seemed to fix the errors...

Cool, I'd kind of noticed this bit of weirdness but hadn't got round to actually doing anything about it :)

LVM_SYSTEM_DIR also gets reset in the cleanup function (which pointless because our changes are dropped when the script ends anyway so we might as well get rid of it, also we're using #!/bin/sh  but assuming several bash-isms so this is a cleanup patch that covers both (hopefully I've figured out how to create proper patches!):

diff --git a/vgimportclone.sh b/vgimportclone.sh
--- a/vgimportclone.sh
+++ b/vgimportclone.sh
@@ -1,4 +1,4 @@
-#!/bin/sh
+#!/bin/bash
 
 # Copyright (C) 2009 Chris Procter All rights reserved.
 # Copyright (C) 2009 Red Hat, Inc. All rights reserved.
@@ -87,8 +87,6 @@
 
 
 function cleanup {
-    #set to use old lvm.conf
-    LVM_SYSTEM_DIR=${ORIG_LVM_SYS_DIR}
 
     if [ $KEEP_TMP_LVM_SYSTEM_DIR -eq 1 ]; then
         echo "${SCRIPTNAME}: LVM_SYSTEM_DIR (${TMP_LVM_SYSTEM_DIR}) must be cleaned up manually."


      

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2009-06-19  4:39 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-06-17 14:27 [linux-lvm] Exposing the same VG from two different disks liam
2009-06-17 15:48 ` [linux-lvm] " Mike Snitzer
2009-06-19  4:39 ` [linux-lvm] " chris procter

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.