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
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list