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

[Hannes Reinecke <hare@suse.de>]

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.)
> 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
-- 
Dr. Hannes Reinecke		               zSeries & Storage
hare@suse.de			               +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)