On Wed, Jul 18, 2012 at 04:42:33PM +0000, Rustad, Mark D wrote: > On Jul 18, 2012, at 9:00 AM, Michael S. Tsirkin wrote: > > > On Wed, Jul 18, 2012 at 11:53:38AM -0400, 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. > > > > Presumably initiators are shut down for target firmware upgrades? > > With virtualization your host can change without guest shutdown. > > You can also *lose* commands when migrating to an older host. > > > Actually no. Storage vendors do not want to impose a need to take initiators down for any reason. I have worked for a storage system vendor that routinely did firmware upgrades on-the-fly. This is done by multi-pathing and taking one path down, upgrade, bring up, repeat. With live migration even that does not happen. > There was even one non-redundant system that I am aware of that could upgrade firmware and reboot fast enough that the initiators would not notice. > > You do have to pay very close attention to some things however. Don't change the device identity in any way - even version information, otherwise a Windows initiator will blue-screen. I made that mistake myself, so I remember it well. It seemed like such an innocent change. I don't recall there being any issue with adding commands and we did do that on occasion. How about removing commands? > -- > Mark Rustad, LAN Access Division, Intel Corporation -- 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
