Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 30 Apr 2020 19:06:01 +0000
From:      bugzilla-noreply@freebsd.org
To:        virtualization@FreeBSD.org
Subject:   [Bug 236042] Windows Server 2016 Hyper-V snapshot triggers SCSI errors
Message-ID:  <bug-236042-27103-OFKIJ7lY57@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-236042-27103@https.bugs.freebsd.org/bugzilla/>
References:  <bug-236042-27103@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D236042

--- Comment #13 from Dexuan Cui <decui@microsoft.com> ---
(In reply to Michael from comment #11)
When you see the SCSI errors, can the live backup procedure succeed? Do you
notice any instability issue (e.g.hang/panic)? Do you notice any data
corruption issue (e.g. the back-up procedure says it succeeded, but later y=
ou
may find that the data is not really consistently backed up, i.e. 'fsck' may
run while you think it should not)?

If the backup procedure still succeeds, and you never notice any real issue,
then I think it should be safe to ignore the SCSI error messages -- if we w=
ant
to get rid of the messages, it looks  sys/dev/hyperv/utilities/hv_snapshot.=
c is
not an issue -- it looks  we need to improve
sys/dev/hyperv/storvsc/hv_storvsc_drv_freebsd.c and/or the other part of SC=
SI
subsystem.

Linux VM on Hyper-V shows the same/similar messages when Hyper-V live backu=
p is
being performed (at least this was the case in June 2017):

sd 2:0:0:0: [storvsc] Sense Key : Unit Attention [current]
sd 2:0:0:0: [storvsc] Add. Sense: Changed operating definition
sd 2:0:0:0: Warning! Received an indication that the operating parameters on
this target have changed. The Linux SCSI layer does not automatically adjust
these parameters.

These messages in a Linux VM can be seen even if the back-up is successful,=
 so
it looks people just ignore the messages in Linux.=20

The messages are caused as a result of the way how Hyper-V live-backup work=
s:
usually the VM's .vhdx file has a block size of 32MB, and during the
live-backup procedure IIRC it looks a temporary .avhdx of a 2MB block size =
is
generated and the host returns sense key "Unit Attention" with asc 0x3f and
ascq 0x2 (Changed Operating Definition); the host sends "Unit Attention"
because the backing VHD block size has changed after checkpoint or backup a=
nd
this results in a change in the granularity of the UNMAP.

Linux SCSI layer can deal with the following asc 0x3f on Unit Attention:
ascq 0x3 (Inquiry Data Has Changed)
ascq 0xe (Reported Luns Data Has Changed)

However ascq 0x2 is ignored. The SCSI won=E2=80=99t know the UNMAP granular=
ity change,
it will run at probably slower UNMAP but won=E2=80=99t affect other parts.

Note: I excerpted the above details from a 2017 email discussing the SCSI
errors in a Linux VM on Hyper-V. My understanding is that the messages can =
be
safely ignored in Linux, but I'm not sure about FreeBSD, as the SCSI subsys=
tem
in FreeBSD may handle the sense info in a different manner.=20

I have moved on to different projects, so I am sorry I can not follow this
up... I hope someone would find the info I shared here is useful, in case
something has to be done in FreeBSD VM.

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-236042-27103-OFKIJ7lY57>