Re: [linux-lvm] Can't work normally after attaching disk volumes originally in a VG on another machine

2018-03-26 Thread Fran Garcia 
On 26 March 2018 at 08:04, Gang He  wrote:
>> Gang He schreef op 23-03-2018 9:30:
>>
>>> 6) attach disk2 to VM2(tb0307-nd2), the vg on VM2 looks abnormal.
>>> tb0307-nd2:~ # pvs
>>>   WARNING: Device for PV JJOL4H-kc0j-jyTD-LDwl-71FZ-dHKM-YoFtNV not
>>> found or rejected by a filter.
>>>   PV VG  Fmt  Attr PSize  PFree
>>>   /dev/vdc   vg2 lvm2 a--  20.00g 20.00g
>>>   /dev/vdd   vg1 lvm2 a--  20.00g 20.00g
>>>   [unknown]  vg1 lvm2 a-m  20.00g 20.00g
>>
>> This is normal because /dev/vdd contains metadata for vg1 which includes
>> now missing disk /dev/vdc   as the PV is no longer the same.
>
> It looks like each PV includes a copy meta data for VG, but if some PV has 
> changed (e.g. removed, or moved to another VG),
> the remained PV should have a method to check the integrity when each startup 
> (activated?), to avoid such inconsistent problem automatically.

Your workflow is strange. What are you trying to accomplish here?

Your steps in 5 should be:

vgreduce vg01 /dev/vdc /dev/vdc
pvremove /dev/vdc /dev/vdd

That way you ensure there's no leftover metadata in the PVs (specially
if you need to attach those disks to a different system)

Again a usecase to understand your workflow would be beneficial...

Cheers

Fran

___
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/

Re: [linux-lvm] Can't work normally after attaching disk volumes originally in a VG on another machine

2018-03-26 Thread Fran Garcia 
On 26 March 2018 at 08:04, Gang He  wrote:
> It looks like each PV includes a copy meta data for VG, but if some PV has 
> changed (e.g. removed, or moved to another VG),
> the remained PV should have a method to check the integrity when each startup 
> (activated?), to avoid such inconsistent problem automatically.

Your workflow is strange. What are you trying to accomplish here?

Your steps in 5 should be:

vgreduce vg01 /dev/vdc /dev/vdc
pvremove /dev/vdc /dev/vdd

That way you ensure there's no leftover metadata in the PVs (specially
if you need to attach those disks to a different system)

Again a usecase to understand your workflow would be beneficial...

Cheers

fran

___
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/

Re: [linux-lvm] -l 100%FREE doesn't work with RAID1

2016-01-20 Thread Fran Garcia 
On 20 January 2016 at 13:19, Bryan Larsen  wrote:
> I'm setting up some provisioning scripts, so I don't know the actual sizes
> of the hard drives
>
> $ sudo lvcreate --type raid1 -m 1 -l 100%FREE -n backups hdd_vg
>   Insufficient free space: 781320 extents needed, but only 390658 available
> $ sudo lvcreate --type raid1 -m 1 -l 50%FREE -n backups hdd_vg
>   Insufficient free space: 390662 extents needed, but only 390658 available

the quick and dirty solution... :

EXTENTS=$(sudo vgs -o vg_all --noheadings hdd_vg | awk '{print $12/2}')
lvcreate --type raid1 -m 1 -l $EXTENTS -n backups hdd_vg

:-)

___
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/