I love Mark's solution in the theory, but the systems I have that continue to have solid SCSI support don't have a copy of simh, nor enough local disk for the output. What I have done in the past is something on the order of:
dd if=/dev/RSCSI_DISK ibs=VERY_LARGE obs=4k conv=sync | ssh remote_sys dd of=/tmp/vdisk.dsk ibs=4k obs=VERY_LARGE The reason for the obs=4k is to keep the network block size under control. Depending on source and destination. Blocking then becomes what is right for the system (on something like a Vax or early x86 based bus maps, they can only do 64K bytes of DMA at a time even if the host has more memory, so even if you put a larger block, it's not clear you will get much more speed up, and the OS how to clear our memory for the I/O, so it becomes a trade off -- i.e. YMMV) Now I have a/couple of different version(s) of dd I dug up/rewrote years ago called ddd - double dd (before gnu's Debugger existed BTW). The original ddd used to UNIX processes the swap back and forth controlled via a pipe (you can find it in the UUNET archives I want to say around 1985), but my newer versions used can use threads of some sort if the local UNIX supports MxN user mode threading, or async I/O is that was supported as the threading overlap tends to be more efficient in the kernel itself, but the idea is the same - you want as much I/O overlapped as possible. [I originally did this to fully stream tape drives in the bad old days of a 10Mhz 68000 are the processor. We ran: dump -f - | ddd of=/dev/rmt0 ibs=20b obs=64k ]. ᐧ On Sun, Apr 21, 2019 at 5:37 PM Mark Pizzolato <m...@infocomm.com> wrote: > On Sunday, April 21, 2019 at 11:28 AM, Zane Healy wrote: > > I have a DL380 on the way to add to my ESXI cluster here at home. As a > result > > I’m looking to finish virtualizing my DEC HW. What is the best way to > convert > > a physical SCSI HD to a disk image for SIMH? I need to do this for both > VAX > > and PDP-11. > > If these are SCSI disks, AND you have a host system with a SCSI host > adapter > that can connect to these disks (i.e. it is the correct SCSI width, and > type), > then you can do this directly using simh from the host system. > > Warning: If you try to do this under some complicated set of layered > virtual systems, then you are on your own (recall your VNC experience). > > Depending on your host system the OS will have some name for the > above mentioned SCSI disk(s) which you've connected. > When you connect these disks to the host system, BE SURE not to > perform any action on these drives BEFORE you let simh see them. > Be sure you identify the raw device name that the OS sees the newly > connected SCSI disks as. Knowing that name the following should work > with a VAX or PDP11 simulator. Note that this will probably have to > be done as root in order to access the physical devices. > > # vax > sim> ATTACH RQ0 -c <rawdevicename> disk1.vhd > sim> DETACH RQ0 > > This will produce a "disk1.vhd" container file with all of the bits that > can be read from the original SCSI disk. > Repeat as necessary for each original disk. > > > One of the main systems that I want to Virtualize is a VAXstation 4000/60 > > with a BA350 shelf. The only HD connected to the system is a RZ28-VA SBB > > (2GB) as DKA200:, so yesterday I added a RZ29-VA SBB (4GB) as DKA100:. I > > setup Standalone Backup on the RZ29 and booted into Standalone backup. > > > > I tried to run the following: > > backup/image/verify dka200: dka100:[000000]20190420-system.sav/sav > > > > I ended up with a very strange “No valid storage bitmap found” error, > and it > > failed to copy anything. > > > > Facility: BACKUP, Backup Utility > > Explanation: Software bad block data is not present on the volume. The > > volume has been initialized with no bad blocks. > > User Action: Execute the Bad Block Locator utility before using the > volume. > > NOBITMAP, no valid storage bitmap found on 'device-name’ > > > > I tried ANALYZE/MEDIA, but may not have been doing things right. This > is a > > Genuine RZ29-VA, but it was originally used as part of a disk array for > a Sun > > Sparc system. > > This exercise will merely put a backup saveset on another disk which I > don't > see getting you very far towards making it accessible from simh. > > Meanwhile, I suspect you are seeing a failure under standalone backup due > to the fact that after you added the DKA100 disk drive to the system you > didn't initialize the disk. You can't initialize a target disk under > standalone > backup, so you'll have to do that with full VMS running before you attempt > the backup again. > > - Mark > _______________________________________________ > Simh mailing list > Simh@trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh
_______________________________________________ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh