Re: [RFC-v2 0/4] tcm_vhost+cmwq fabric driver code for-3.6

[Anthony Liguori <aliguori@us.ibm.com>]

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

>