On 07/18/2012 10:53 AM, Christoph Hellwig wrote:
On Wed, Jul 18, 2012 at 08:42:21AM -0500, Anthony Liguori wrote:
If you add support for a new command, you need to provide userspace
a way to disable this command. If you change what gets reported for
VPD, you need to provide userspace a way to make VPD look like what
it did in a previous version.
Basically, you need to be able to make a TCM device behave 100% the
same as it did in an older version of the kernel.
This is unique to virtualization due to live migration. If you
migrate from a 3.6 kernel to a 3.8 kernel, you need to make sure
that the 3.8 kernel's TCM device behaves exactly like the 3.6 kernel
because the guest that is interacting with it does not realize that
live migration happened.
I don't think these strict live migration rules apply to SCSI targets.
Real life storage systems get new features and different behaviour with
firmware upgrades all the time, and SCSI initiators deal with that just
fine. I don't see any reason to be more picky just because we're
virtualized.
But would this happen while a system is running live?
I agree that in general, SCSI targets don't need this, but I'm pretty sure that
if a guest probes for a command, you migrate to an old version, and that command
is no longer there, badness will ensue.
It's different when you're talking about a reboot happening or a
disconnect/reconnect due to firmware upgrade. The OS would naturally be
reprobing in this case.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
