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

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

On 07/18/2012 11:47 AM, James Bottomley wrote:
> On Wed, 2012-07-18 at 11:00 -0500, Anthony Liguori wrote:
>
> Of course: Think about the consequences: you want to upgrade one array
> on your SAN.  You definitely don't want to shut down your entire data
> centre to achieve it.  In place upgrades on running SANs have been
> common in enterprise environments for a while.

Would firmware upgrades ever result in major OS visible changes though?

Maybe OSes are more robust with SCSI than with other types of buses, but I don't 
think it's safe to completely ignore the problem.

>> 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.
>
> What command are we talking about?  Operation of initiators is usually
> just READ and WRITE.  So perhaps we might have inline UNMAP ... but the
> world wouldn't come to an end even if the latter stopped working.

Is that true for all OSes?  Linux may handle things gracefully if UNMAP starts 
throwing errors but that doesn't mean that Windows will.

There are other cases where this creates problems.  Windows (and some other 
OSes) fingerprint the hardware profile in order to do license enforcement.  If 
the hardware changes beyond a certain amount, then they refuse to boot.

Windows does this with a points system and I do believe that INQUIRY responses 
from any local disks are included in this tally.

> Most of the complex SCSI stuff is done at start of day; it's actually
> only then we'd notice things like changes in INQUIRY strings or mode
> pages.
>
> Failover, which is what you're talking about, requires reinstatement of
> all the operating parameters of the source/target system, but that's not
> wholly the responsibility of the storage system ...

It's the responsibility of the hypervisor when dealing with live migration.

Regards,

Anthony Liguori

>
> James
>
>> 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.
>
>
>