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