On 06/15/2012 02:32 PM, Rustad, Mark D wrote: > I have been thinking some about target configuration and I think I > have an idea that may improve things somewhat. An issue I have seen > is that the targetcli will sometimes fail to restore a configuration, > or at least portions of it, when a link has not yet reached the right > state. This can lead to loss of the configuration information, since > by default the configuration is saved when targetcli exits. Yes, I > know that it will remain in the backup file, at least for one > failure. I've had to use it more than once. > > I am thinking that perhaps the kernel should accept the configuration > information, even if things are not (yet) in an operational state. I > got to thinking about configuring a multipath target, and it seems > like it really should be possible to fully configure the target, even > if a link happens to be down, so that it can automatically be active > when the link finally gets to the right state. > > Does this seem feasible? Are there any significant problems with > having things work in this way? I assumed this was the kernel code not permitting configuration of absent wwns, but after looking I think this might actually be a rtslib-fb constraint. if you want to try hacking-up /usr/lib/python-2.<x>/site-packages/rtslib/target.py line 227(ish) from: return is_valid_wwn(self.spec['wwn_type'], wwn, self.spec['wwn_list']) to: return is_valid_wwn(self.spec['wwn_type'], wwn) does it work better? Thanks -- Regards -- Andy -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
