First post, by JodieC
I really hate dedicating storage to old PCs. I'm not sure why - and the idea has always tickled my fancy that I should definitely be able to emulate a SCSI disk somewhere else. I did it a long time ago and I bet it's even better today.
So, without further ado. What I'm doing so far, what I've ordered, etc. I'm just going to be pasting links, photos and configs and stuff.
Cards that may support target mode:
Adaptec PSCSI cards seem to have explicit callouts in their product sheets when they support target mode. There have been mentions in product literature back to 154x cards.
I've seen indications that QLogic cards may support target mode, but have not seen extensive documentation to it.
Drivers for PSCSI target mode:
FreeBSD:
ahc - https://www.freebsd.org/cgi/man.cgi?ahc(4)
ahd - https://www.freebsd.org/cgi/man.cgi?ahd(4)
I found an interesting discussion here about someone having issues with FreeBSD target mode, and this actually included a lot of helpful info for getting started
https://forums.freebsd.org/threads/help-with- … -example.56828/
My setup is this:
ESXi VT-d passthrough of an Adaptec 39160 to a FreeBSD 12.0 machine
Custom compiled kernel with these options. As I have a 160 controller, it's covered by the ahc driver and these options are specific to the ahc driver. I tried a 39320 and it didn't work.
`include GENERIC
ident SCSIKERNEL
device scbus
device da
device targ
device targbh
options CAMDEBUG
options AHC_TMODE_ENABLE=0x127`
(I went really wide with the bitmask. 🤣)
I made that config file, compiled the kernel and rebooted. It's a lot easier than it sounds.
https://www.freebsd.org/doc/en_US.ISO8859-1/b … fig-config.html
https://www.freebsd.org/doc/en_US.ISO8859-1/b … g-building.html
Okay, now what?
FreeBSD includes a usermode scsi target application in /usr/share/examples/scsi_target . Go in there and run `make`
If you have your file or disk for the backing store, you are ready to try. However you need a piece of information first - the bus number of your ahc controller (or whichever controller. To get this information, you'll need to run `camcontrol devlist -b` .
If you have something like a 29160 or a dual bus controller, you'll see two controllers, one for each channel. Picking the wrong one is easy - however a lot of devices will reset the channel when they initialize the IC and you'll see "something reset channel A" on your FreeBSD console or messages.
So in my case the 39160 was on scbus33 and scbus34. You can define these manually with some hints files if you really wanted to.
I have two 20GB disks given to the VM from my SSD stores. They're in the system as /dev/da1 and /dev/da2
Now to fire up the target:
`tmux`
`/usr/share/examples/scsi_target/scsi_target -W16 33:1:0 /dev/da1`
(When I don't do -W16 for 16 bit transfers, nothing shows up on the initiators)
If this went well you'll see messages about sending CCBs and blah blah blah. If it says your controller doesn't support target mode, you may have the wrong controller number, or it may be that your controller really doesn't support target mode. I've read that Adaptec Ultra320 adapters 1) might not do target mode if set to Ultra320 speed, 2) Later models might not do target mode at all.
OKAY, the client now. I want to install Windows98 on something!
I drop the 39320 into the client and connect a VHDCI cable to the 39160 in the ESXI box.
Now I'm going to power down that FreeBSD VM. Then I make a new VM in ESXI for Windows98, and tell it to use the first 20GB disk I gave the BSD VM. Install until it gets past the text installer portion and shut down. Remove the 98 VM but let it keep the disks.
Boot the FreeBSD box back up and run your scsi_target command again. Ctl-B D to detach from the tmux session and leave it running.
Now on the client, I power up, and I remember to change the initiator ID for the client device, because if they're all ID 7, nothing is going to work. So I change the initiator ID to 0.
At this point, I can go into Adaptec's SCSI bios and see if it will pick everything up. It should be pretty smooth sailing from here. However, I have had instances where the initiator does something, I don't know what, that just absolutely wrecks the target side, and I make it a point that if I reboot the initiator, I just go ahead and reboot the target VM too, because it seems to tweak the target on reboot.
I'm going to splat more things here as I come across them.