[Bug 226583] FreeBSD VM on Hyper-V/Azure can't properly detected SCSI disk da2
bugzilla-noreply at freebsd.org
bugzilla-noreply at freebsd.org
Tue Apr 24 03:08:35 UTC 2018
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226583
--- Comment #8 from commit-hook at freebsd.org ---
A commit references this bug:
Author: dexuan
Date: Tue Apr 24 03:07:49 UTC 2018
New revision: 332904
URL: https://svnweb.freebsd.org/changeset/base/332904
Log:
MFC: 332385
r332385:
hyperv/storvsc: storvsc_io_done(): do not use CAM_SEL_TIMEOUT
CAM_SEL_TIMEOUT was introduced in
https://reviews.freebsd.org/D7521 (r304251), which claimed:
"VM shall response to CAM layer with CAM_SEL_TIMEOUT to filter those
invalid LUNs. Never use CAM_DEV_NOT_THERE which will block LUN scan
for LUN number higher than 7."
But it turns out this is not correct:
I think what really filters the invalid LUNs in r304251 is that:
before r304251, we could set the CAM_REQ_CMP without checking
vm_srb->srb_status at all:
ccb->ccb_h.status |= CAM_REQ_CMP.
r304251 checks vm_srb->srb_status and sets ccb->ccb_h.status properly,
so the invalid LUNs are filtered.
I changed my code version to r304251 but replaced the CAM_SEL_TIMEOUT
with CAM_DEV_NOT_THERE, and I confirmed the invalid LUNs can also be
filtered, and I successfully hot-added and hot-removed 8 disks to/from
the VM without any issue.
CAM_SEL_TIMEOUT has an unwanted side effect -- see cam_periph_error():
For a selection timeout, we consider all of the LUNs on
the target to be gone. If the status is CAM_DEV_NOT_THERE,
then we only get rid of the device(s) specified by the
path in the original CCB.
This means: for a VM with a valid LUN on 3:0:0:0, when the VM inquires
3:0:0:1 and the host reports 3:0:0:1 doesn't exist and storvsc returns
CAM_SEL_TIMEOUT to the CAM layer, CAM will detech 3:0:0:0 as well: this
is the bug I reported recently:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226583
PR: 226583
Reviewed by: mav
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D14690
Changes:
_U stable/10/
stable/10/sys/dev/hyperv/storvsc/hv_storvsc_drv_freebsd.c
--
You are receiving this mail because:
You are the assignee for the bug.
More information about the freebsd-virtualization
mailing list