From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55634) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a6xHu-0004MN-DK for qemu-devel@nongnu.org; Thu, 10 Dec 2015 04:13:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a6xHr-0005dQ-2y for qemu-devel@nongnu.org; Thu, 10 Dec 2015 04:13:22 -0500 Received: from mx2.suse.de ([195.135.220.15]:52978) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a6xHq-0005d0-TK for qemu-devel@nongnu.org; Thu, 10 Dec 2015 04:13:19 -0500 References: <1448636346-24641-1-git-send-email-hare@suse.de> <20151210082641.GA4222@stefanha-x1.localdomain> From: Hannes Reinecke Message-ID: <5669422D.5080400@suse.de> Date: Thu, 10 Dec 2015 10:13:17 +0100 MIME-Version: 1.0 In-Reply-To: <20151210082641.GA4222@stefanha-x1.localdomain> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH RFC 0/8] scsi-disk: Active/passive ALUA support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Johannes Thumshirn , Paolo Bonzini , qemu-devel@nongnu.org, Alexander Graf On 12/10/2015 09:26 AM, Stefan Hajnoczi wrote: > On Fri, Nov 27, 2015 at 03:58:58PM +0100, Hannes Reinecke wrote: >> here's now an updated version to enable ALUA and simplified >> active/passive multipath support for qemu. >> >> This patchset relies on having _two_ block devices configured, >> and two SCSI disks pointing to those block devices with the >> _same_ 'wwn' property and unique 'port_group' properties. >> I know, this is a bit of a nasty hack, but I hope to add >> proper multipath support (with several SCSI devices pointing / >> linking to the same block device) in the near future. >> >> It also implements a 'alua_policy', which allows for simulating >> an 'active/passive' multipath setup. >> >> And for testing I've implemented a 'block_disconnect' HMP command, >> which simulates a link failure for the attached devices. >> >> I wouldn't object if someone declares this a gross hack, but with >> it I can finally simulate real-life multipath failover and do >> some functional multipath-tools testing withouth having to recurse >> on using real hardware. > > I'm not familiar with how ALUA works but have been thinking about a > multipath problem: > > If the host has SCSI disks that are marked 'offline' then QEMU will > refuse to start up since it cannot open the block device (ENXIO). > Define 'offline'. If this means the ALUA state 'offline' then we wouldn't have to=20 worry; ALUA state 'offline' essentially means "Yeah, there's=20 something here, but I won't tell you and you cannot access it.". And any transitions to and from 'offline' are essentially=20 vendor-specific. In short: Do not use it. If OTOH means the 'block_disconnect' state this is something which=20 should/needs to be implemented in the HBA emulation for simulating a link failure. qemu itself should be able to access the device and it should start=20 up perfectly normal, so we shouldn't get any ENXIO errors. (Obviously, if _all_ disks are in 'disconnect' state the guest=20 wouldn't start up as it cannot read any data. But that's beside the=20 point.) > Does it make sense to allow guests to start in this condition? > Sorta. At least it'd be good to allow this, if only for debugging. > I think we'd need to notice when the disk comes back online and notify > the guest. > Nope. That's something the HBA emulation is responsible for. Cheers, Hannes --=20 Dr. Hannes Reinecke zSeries & Storage hare@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 N=FCrnberg GF: F. Imend=F6rffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG N=FCrnberg)