qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH RFC 0/8] scsi-disk: Active/passive ALUA support


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [PATCH RFC 0/8] scsi-disk: Active/passive ALUA support
Date: Mon, 14 Dec 2015 15:24:25 +0800
User-agent: Mutt/1.5.24 (2015-08-30)

On Thu, Dec 10, 2015 at 10:13:17AM +0100, Hannes Reinecke wrote:
> 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 worry; ALUA
> state 'offline' essentially means "Yeah, there's something here, but I won't
> tell you and you cannot access it.".
> And any transitions to and from 'offline' are essentially vendor-specific.
> In short: Do not use it.
> 
> If OTOH means the 'block_disconnect' state this is something which
> 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 up
> perfectly normal, so we shouldn't get any ENXIO errors.
> 
> (Obviously, if _all_ disks are in 'disconnect' state the guest wouldn't
> start up as it cannot read any data. But that's beside the point.)

I'm referring to scsi_device_set_state(scmd->device, SDEV_OFFLINE) in
Linux.  This is the state where the host block device cannot be opened
or accessed.

Stefan

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]