On Wed, 2012-07-18 at 11:00 -0500, Anthony Liguori wrote: > 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? 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. > 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. 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 ... 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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
