[libvirt] [PATCH] iscsi: do not fail to stop a stopped pool

[Ján Tomko]

On Wed, Apr 29, 2015 at 01:03:29PM -0400, John Ferlan wrote:
> 
> 
> On 04/29/2015 10:40 AM, Ján Tomko wrote:
> > On Wed, Apr 29, 2015 at 10:10:11AM -0400, John Ferlan wrote:
> >>
> >>
> >> On 04/29/2015 09:08 AM, Ján Tomko wrote:
> >>> Just as we allow stopping filesystem pools when they were unmounted
> >>> externally, do not fail to stop an iscsi pool when someone else
> >>> closed the session externally.
> >>>
> >>> Resolves:
> >>> https://bugzilla.redhat.com/show_bug.cgi?id=1171984
> >>
> >> For this I disagree - it doesn't resolve all the issues in 1171984.
> > 
> > I can remove the 'Resolves:' line.
> > 
> 
> Fair enough
> 
> >> It
> >> resolves a symptom of libvirt allowing more than one pool to use the
> >> same session.
> > 
> > This resolves the error to stop a pool when there's no pool anymore,
> > whether that's because someone called StopPool earlier on a pool that
> > was duplicate but libvirt didn't catch it, or manually via messing with
> > iscsiadm.
> > 
> 
> I did some more testing of this and found one could start a domain using
> the pool in the funky state which would cause the session to be logged
> back in (I have authentication enabled too, so that could be a reason -
> I didn't chase deeper)....
> 

I don't see the qemu driver doing any iscsi-related calls, is this done
by qemu?

> This patch only addresses failure to shutdown the second of the
> duplicated pools, but trying to refresh the pool gets the same result -
> that is an error since the session was logged out. However, if someone
> calls refreshPool and there's a failure because of the logout, then the
> pool gets marked as inactive.
> 

Well, the pool was shut down outside of libvirt's knowledge and libvirt
marks is as inactive as soon as it's asked to refresh it, I think that's
expected.

> The checkPool will be "tricked" into believing the pool isn't started
> which shouldn't be a huge deal unless pool-autostart is set for the
> pool. 

Why tricked? The pool is not started - the session is not there.

> But I think someone would have expected (based on a recent series)
> that if a pool was started, that it could survive a 'service libvirtd
> restart'.
> 
> The findPoolSources, uploadVol, downloadVol, and wipeVol don't require
> the session as they go direct to the block device
> 
> >>
> >> While there is disagreement over the method I've taken :
> >>
> >> http://www.redhat.com/archives/libvir-list/2015-April/msg01197.html
> >>
> >> Simply "covering up" the original issue by just ignoring the error on
> >> stop doesn't seem to be the best solution to me.
> >>
> > 
> > The proposed series aims to detect duplicate pools on the same hosts.
> > It does not deal with duplicate pools on different hosts.
> > Even if we change the duplicate checks to only deal with the target,
> > as I suggested here:
> > https://www.redhat.com/archives/libvir-list/2015-April/msg00959.html
> > (since libvirt's iscsi backend treats the same target on different hosts
> > as a duplicate pool, but the check above does not), this patch also
> > fixes stopping the pool after someone messes with iscsiadm manually,
> > 
> > 
> As noted in my response, duplicated IQN's on truly different host names
> (by name or address) is a different bug.  Not that it doesn't deserve to
> be fixed, but let's take it one step at a time.
> 


> There's still another issue of how to resolve the "same host" when using
> different IP address families...
> 

I don't think that can be done, or that it should be attempted.

Jan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20150430/32244b83/attachment-0001.sig>