[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] [Patch 0/7] pvSCSI driver
> Hi, > > Problems discussed in this context, what the portion of whole SCSI > tree should be exposed to guest and how the numbering logic of guest's > tree should be, is very fundamental and difficult, I think. > > In my current thought, following two options are reasonable solutions. > How do you think about them? Could you please comment me? > > Option 1 (LUN assignment) > - Specify the assignment like below: > "host1:channel1:id1:lun1"(Dom0) -> "host2:channel2:id2:lun2"(guest) > The lun1 must be same as the lun2. > - Munging :-) REPORT LUNS command on Dom0 according to the number of > LUNs actually attached to the guest. > > Option 2 (Target Assignment) > - Specify the assignment like below: > "host1:channel1:id1"(Dom0) -> "host2:channel2:id2"(guest) > All LUNs under id1 are assigned to one guest. > - Munging for LUN is not needed. I think it would help to have some real-life examples about where each option would and wouldn't make sense. It may be that you need to implement both options. I'm not familiar enough with the variety of scsi devices out there to be able to judge. > For each option, how host/bus/device reset command should be? I have thought about this some more. Normally, a reset will be issued because of some error, normally a timeout I assume. You could implement something like: . if the reset requested is a device reset, and the DomU 'owns' all luns attached to the device, then allow the device reset. . if the reset requested is a device reset, and the DomU 'owns' only some of the luns attached to the device, then only allow the device reset if all the other 'owners' have requested a device reset also. . the above two rules might work for host and bus resets too, as long as all 'owners' agree to a reset. The problem might be if you had a device with three luns, and three DomU's with a single lun each. If the device had hung and required a reset, then any DomU using it would notice the timeout and issue a reset, but if one DomU wasn't using its lun at the time it might not notice. Maybe you need another communication channel where Dom0 can ask each DomU for permission to do the reset. This reset stuff seems like a lot of extra work for probably not much benefit though. James _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |