Re: [PATCH 1/2 v1] blkdrv: Add queue limits parameters for sg block drive

[Paolo Bonzini <pbonzini@xxxxxxxxxx>]

Il 21/08/2012 11:52, Stefan Hajnoczi ha scritto:
>>> >> Using /sys/dev/block or /sys/dev/char seems easier, and lets you
>>> >> retrieve the parameters for block devices too.
>>> >>
>> > what do you mean with "block devices"?   Using "/dev/sda" instead of
>> > "/dev/sg0"?

Yes.

>>> >> However, I'm worried of the consequences this has for migration.  You
>>> >> could have the same physical disk accessed with two different HBAs, with
>>> >> different limits.  So I don't know if this can really be solved at all.
>>> >>
>> > I know little about qemu migration now.  The pending scsi commands will be
>> > saved and
>> > transfered to remote machine when starting migration?
> 
> Passthrough is already a migration blocker if both hosts do not have
> access to the same LUNs.

Yes, but requiring the exact same hardware may be too much.  I'm trying
to understand the problem better before committing to a threefold
spec/qemu/kernel change.

Cong, what is the limit that the host HBA enforces (and what is the
HBA)?  What commands see a problem?  Is it fixed by using scsi-block
instead of scsi-generic (if you can use scsi-block at all, i.e. it's not
a tape or similar device)?

With scsi-generic, QEMU uses a bounce buffer for non-I/O commands to a
SCSI passthrough device, so the only problem in that case should be the
maximum segment size.  This could change in the future, but max_segments
and max_sectors should not yet be a problem.

With scsi-block, QEMU will use read/write on the block device and the
host kernel will then obey the host HBA's block limits.  QEMU will still
use a bounce buffer for non-I/O commands to a scsi-block device, but the
payload is usually small for non-I/O commands.

Paolo

> When both hosts do have access to the same LUNs it's possible to
> extract the block queue limits (using sysfs) and compare them.
> 
> Today you can start QEMU with different image files on both hosts.
> Migration will appear to work but the disk image on the destination
> host could be junk.  This is a similar case, I don't see a problem
> except that there should be a safety check (maybe at the libvirt
> level) to make this safe.

_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization