[linux-lvm] [IMPORTANT]LVM+iSCSI issue..Local Disk disappeared..

[linux-lvm] [IMPORTANT]LVM+iSCSI issue..Local Disk disappeared..

[himanshu padmanabhi]

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

I am using "iscsi-initiator-utils-6.2.0.865-0.2.fc7" as initiator and
"iscsitarget-0.4.15-1" as target.

Following is the scenario

*PV  =  local_disk1       remote_disk1  (i.e PV is formed using 2 disks
1 local and 1 from iscsitarget)
*

* VG  =  Vgname
*

* LV =  lv_localdisk_1       lv_localremotedisk1
lv_remotedisk1 (i.e. 1 lv only from local disk,1 from remote
iscsitarget and one from combination of both)
*

I performed "logout" operation on "remote_disk1" after deactivating
"lv_localremotedisk1 and           lv_remotedisk1" on it using
"lvchange" command.

Then result I should at least get,

*PV  =  local_disk1    (remote_disk1 is removed now)
*

* VG = Vgname
*

* LV = lv_localdisk1     (So LVs containing PVs as "remote_disk1" are
deactivated.It can be in combination with local disk also) *

Still confused about  "lv_localremotedisk1"?Local disk part would also
lost here till I again login to that target.

But the result was

*PV =
VG =
LV =
*

i.e They all were lost temporarily.

When I logged in to the same target and activated the LVs on
"remote_disk1",I got my original configuration.i.e.

*PV  =  local_disk1       remote_disk1  (i.e PV is formed using 2 disks
1 local and 1 from iscsitarget)
*

* VG  =  Vgname
*

* LV =  lv_localdisk_1       lv_localremotedisk1
lv_remotedisk1 (i.e. 1 lv only from local disk,1 from remote
iscsitarget and one from combination of both)*

Please help......

This should not happen.....right...

-- 
Thanks and Regards,
Himanshu Padmanabhi

[-- Attachment #2: Type: text/html, Size: 3343 bytes --]

Re: [linux-lvm] [IMPORTANT]LVM+iSCSI issue..Local Disk disappeared..

[Peter Larsen]

On Wed, 2008-10-15 at 18:50 +0530, himanshu padmanabhi wrote:
> 
> I am using "iscsi-initiator-utils-6.2.0.865-0.2.fc7" as initiator and 
> "iscsitarget-0.4.15-1" as target. 
> 
> 
> Following is the scenario 
> 
> 
> PV  =  local_disk1       remote_disk1  (i.e PV is formed using 2
> disks 
> 1 local and 1 from iscsitarget) 

Strange construction?
Why not simply format each target as a separate PV and then join them in
a single VG? Much easier to manage. 

That aside - I wouldn't mix and match that way. You're getting very
different response times and security issues on each device. I would
treat them very different.

> VG  =  Vgname 

You need to assign the PV's to your VG.

> LV =  lv_localdisk_1       lv_localremotedisk1 
> lv_remotedisk1 (i.e. 1 lv only from local disk,1 from remote 
> iscsitarget and one from combination of both) 

That makes no sense. You don't use physical volumes when you create
logical ones. You use groups. You don't assign physical devices like
that when you do LVs.

> I performed "logout" operation on "remote_disk1" after deactivating 
> "lv_localremotedisk1 and           lv_remotedisk1" on it using 
> "lvchange" command. 
> 
> 
> Then result I should at least get, 
> 
> 
> PV  =  local_disk1    (remote_disk1 is removed now) 
> 
> 
> VG = Vgname 
> 
> 
> LV = lv_localdisk1     (So LVs containing PVs as "remote_disk1" are 
> deactivated.It can be in combination with local disk also)

No - things don't work that way. If you damage/remove a PV from a VG -
everything in that VG gets disabled until the whole VG is operational.
It doesn't matter if your LV is in the area damaged or not.

> i.e They all were lost temporarily. 

Not temporarily. As long as the VG is bad, nothing is there. You should
see all available PVs but the way you set it up, you didn't do a PV on
each disk so when the disk-group sees one disk missing the whole disk
group is offline, you loose your PV, your VG gets deactivated = the
result you see.

> When I logged in to the same target and activated the LVs on 
> "remote_disk1",I got my original configuration.i.e. 

Because your PV is now present, the VG can activate etc.


--- 
Regards
    Peter Larsen

We have met the enemy, and he is us.
		-- Walt Kelly

Re: [linux-lvm] [IMPORTANT]LVM+iSCSI issue..Local Disk disappeared..

[himanshu padmanabhi]

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

We configured it as
*
Case 1

*pv1= localdisk1    pv2 =localdisk2

Vg1= pv1,pv2

created lv1 of size =pv1size + pv2size

Deleted lv1,

removed pv2,

vg is getting displayed properly in vgs command

*
Case 2

*pv1= localdisk1    pv2 =remotedisk2(iscsi disk)

Vg1= pv1,pv2

created lv1 of size =pv1size + pv2size

Deleted lv1,

logout from iscsi target

vg is not getting displayed properly in vgs command


On Wed, Oct 15, 2008 at 9:36 PM, Peter Larsen <plarsen@ciber.com> wrote:

> On Wed, 2008-10-15 at 18:50 +0530, himanshu padmanabhi wrote:
> >
> > I am using "iscsi-initiator-utils-6.2.0.865-0.2.fc7" as initiator and
> > "iscsitarget-0.4.15-1" as target.
> >
> >
> > Following is the scenario
> >
> >
> > PV  =  local_disk1       remote_disk1  (i.e PV is formed using 2
> > disks
> > 1 local and 1 from iscsitarget)
>
> Strange construction?
> Why not simply format each target as a separate PV and then join them in
> a single VG? Much easier to manage.
>
> That aside - I wouldn't mix and match that way. You're getting very
> different response times and security issues on each device. I would
> treat them very different.
>
> > VG  =  Vgname
>
> You need to assign the PV's to your VG.
>
> > LV =  lv_localdisk_1       lv_localremotedisk1
> > lv_remotedisk1 (i.e. 1 lv only from local disk,1 from remote
> > iscsitarget and one from combination of both)
>
> That makes no sense. You don't use physical volumes when you create
> logical ones. You use groups. You don't assign physical devices like
> that when you do LVs.
>
> > I performed "logout" operation on "remote_disk1" after deactivating
> > "lv_localremotedisk1 and           lv_remotedisk1" on it using
> > "lvchange" command.
> >
> >
> > Then result I should at least get,
> >
> >
> > PV  =  local_disk1    (remote_disk1 is removed now)
> >
> >
> > VG = Vgname
> >
> >
> > LV = lv_localdisk1     (So LVs containing PVs as "remote_disk1" are
> > deactivated.It can be in combination with local disk also)
>
> No - things don't work that way. If you damage/remove a PV from a VG -
> everything in that VG gets disabled until the whole VG is operational.
> It doesn't matter if your LV is in the area damaged or not.
>
> > i.e They all were lost temporarily.
>
> Not temporarily. As long as the VG is bad, nothing is there. You should
> see all available PVs but the way you set it up, you didn't do a PV on
> each disk so when the disk-group sees one disk missing the whole disk
> group is offline, you loose your PV, your VG gets deactivated = the
> result you see.
>
> > When I logged in to the same target and activated the LVs on
> > "remote_disk1",I got my original configuration.i.e.
>
> Because your PV is now present, the VG can activate etc.
>
>
> ---
> Regards
>    Peter Larsen
>
> We have met the enemy, and he is us.
>                -- Walt Kelly
>
> _______________________________________________
> 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/
>



-- 
Regards,
Himanshu Padmanabhi

[-- Attachment #2: Type: text/html, Size: 4397 bytes --]

Re: [linux-lvm] [IMPORTANT]LVM+iSCSI issue..Local Disk disappeared..

[Klaus Strebel]

Hi himanshu,

himanshu padmanabhi schrieb:
> We configured it as
> *
> Case 1
> 
> *pv1= localdisk1    pv2 =localdisk2
> 
> Vg1= pv1,pv2
> 
> created lv1 of size =pv1size + pv2size
> 
> Deleted lv1,
>  
> removed pv2,
> 
> vg is getting displayed properly in vgs command
> 
> *
> Case 2
> 
> *pv1= localdisk1    pv2 =remotedisk2(iscsi disk)
> 
> Vg1= pv1,pv2
> 
> created lv1 of size =pv1size + pv2size
> 
> Deleted lv1,
> 
> logout from iscsi target
> 
> vg is not getting displayed properly in vgs command
In case 1 you just physically removed the pv2? And vgdisplay shows you
the error message of the missing pv in the vg? Or you removed the pv
from the vg, vgdisplay showing you that the vg is ok?

In case 2 you just log the iscsi target out, which is the same as just
pulling the cable off, and vgdisplay doesn't show you, that the vg is
damaged, cause the pv2 is missing?

If you want to remove the pv2 from the vg without getting it in error
state, you have to remove the pv from the vg before iscsi-logout.

Anyways, it would be quite helpfull to cut-n-past the output of
vgdisplay into your mails instead of telling us, that it's not
displaying properly ;-).

Ciao
Klaus
-- 
Mit freundlichen Grüssen / best regards

Klaus Strebel, Dipl.-Inform. (FH), mailto:klaus.strebel@gmx.net

/"\
\ /     ASCII RIBBON CAMPAIGN
 X        AGAINST HTML MAIL
/ \

Re: [linux-lvm] [IMPORTANT]LVM+iSCSI issue..Local Disk disappeared..

[Peter Larsen]

On Thu, 2008-10-16 at 15:57 +0530, himanshu padmanabhi wrote:
> We configured it as
> 
> Case 1
> [....]
> Deleted lv1, 
> removed pv2,
> vg is getting displayed properly in vgs command
> Case 2
> [...]
> Deleted lv1,
> logout from iscsi target
> vg is not getting displayed properly in vgs command

Those are not the same? In case 1 you tell LVM to drop a storage (I
assume by removing pv2 you first take it out of the vg and then apply
pvremove). In case 2 you you're simulating media failure to LVM. You
can't just remove a media it depends on. Regardless if LVM has data on
the PV or not.

Are you trying to make failover work? If so, your approach is a bit
wrong. Setup a software raid 1 first, then build your PV on that. Once
done, you can remove one disk and your LVM will continue to run
(degraded).


--- 
Regards
    Peter Larsen
 
I don't kill flies, but I like to mess with their minds.  I hold them
above
globes.  They freak out and yell "Whooa, I'm *way* too high."
		-- Bruce Baum

Re: [linux-lvm] [IMPORTANT]LVM+iSCSI issue..Local Disk disappeared..

[himanshu padmanabhi]

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

Thnx everyone(Esp. peter).....Your comments were really useful.

Just want to ask one thing....

We can get physical volumes associated with given LV using "lvdisplay -m
"/dev/vgname/lvname".....Is the information given by it no so sure.....

Because you specified that "we cannot get which PV's are associated with
which LV".


On Thu, Oct 16, 2008 at 8:50 PM, Peter Larsen <plarsen@ciber.com> wrote:

> On Thu, 2008-10-16 at 15:57 +0530, himanshu padmanabhi wrote:
> > We configured it as
> >
> > Case 1
> > [....]
> > Deleted lv1,
> > removed pv2,
> > vg is getting displayed properly in vgs command
> > Case 2
> > [...]
> > Deleted lv1,
> > logout from iscsi target
> > vg is not getting displayed properly in vgs command
>
> Those are not the same? In case 1 you tell LVM to drop a storage (I
> assume by removing pv2 you first take it out of the vg and then apply
> pvremove). In case 2 you you're simulating media failure to LVM. You
> can't just remove a media it depends on. Regardless if LVM has data on
> the PV or not.
>
> Are you trying to make failover work? If so, your approach is a bit
> wrong. Setup a software raid 1 first, then build your PV on that. Once
> done, you can remove one disk and your LVM will continue to run
> (degraded).
>
>
> ---
> Regards
>    Peter Larsen
>
> I don't kill flies, but I like to mess with their minds.  I hold them
> above
> globes.  They freak out and yell "Whooa, I'm *way* too high."
>                -- Bruce Baum
>
> _______________________________________________
> 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/
>



-- 
Regards,
Himanshu Padmanabhi

[-- Attachment #2: Type: text/html, Size: 2596 bytes --]

Re: [linux-lvm] [IMPORTANT]LVM+iSCSI issue..Local Disk disappeared..

[Peter Larsen]

On Mon, 2008-10-20 at 13:10 +0530, himanshu padmanabhi wrote:
> Thnx everyone(Esp. peter).....Your comments were really useful.
> 
> Just want to ask one thing....
> 
> We can get physical volumes associated with given LV using "lvdisplay
> -m "/dev/vgname/lvname".....Is the information given by it no so
> sure.....

Conceptually, don't think of PVs as disks with LVM. The VG is your disk.
Just like you're not concerned about what goes on each platter of your
disk/raid, the same with LVM. You're not concerted what goes on the
physical devices - but instead what goes on the VG. The VG is where you
manage your "physical" space. And while you could find out what disk(s)
a given LV is located on, why bother?  LVM manages your disk allocation
for you.

As I indicated - if you want redundancy you should use software raid.
LVM does have a mirror option but it's NOT to be mistaken for RAID1
mirror. Once you have your MD setup, loosing a disk doesn't impact your
LVM except for performance. And you'll use your raid tools to
replace/rebuild the missing disk.

> Because you specified that "we cannot get which PV's are associated
> with which LV".

Right - LVs are not associated with PV - only VG. Consider your LV a
"partition" and your VG your disk. The PV is an "abstract" layer that
implements the VG. But you don't operate on the PV. This is on purpose -
this is what gives you the flexibility. Your VG is full? Add a new PV! A
"partition" is too small? Reallocate space on the VG so the partition
(LV) gets more space!

Think about what your goal is. If it's redundancy, use software raid. If
it's storage allocation flexibility it's LVM. And they can be combined
to give you the best of both worlds.

That said - creating a mirror'ed pair of out two disks on different bus
systems isn't exactly "business as usual". While possible, the slowest
disk wins every time.

I have a feeling you want the LVs to allocate to the physical devices
and in particular that the iSCSI contains one LV you want to go offline
in case the ISCSI isn't connected?  If that's the case,  you have to
create two VGs - one for each disk. Assign the LVs as you find fit, and
once the iSCSI target is unavailable, the VG goes offline and all the
LVs on the VG like that (you'll get a loooot of errors - I wouldn't
recommend it). It doesn't work by something computing where on the VG a
LV is located and only the LVs that's on the bad disk gets an error. If
*any* PV on a VG is unavailable, the VG comes unavailable - including
all the LVs that's implemented on the VG.

--- 
Regards
    Peter Larsen

 netgod:  8:42pm is not late.
 doogie: its 2:42am in Joeyland
	-- #Debian