<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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:</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style=""><font face="arial, helvetica, sans-serif">        </font><font color="#0000ff" style="" face="monospace, monospace">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</font></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style=""><span style="font-family:arial,helvetica,sans-serif">The reason for the </span><font face="monospace, monospace" color="#0000ff">obs=4k</font><font face="arial, helvetica, sans-serif"> 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)</font></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style=""><font face="arial, helvetica, sans-serif">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:  </font><font color="#0000ff" style="" face="monospace, monospace">dump -f - | ddd of=/dev/rmt0 ibs=20b obs=64k</font><font face="arial, helvetica, sans-serif"> ].</font></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">  </div></div><div hspace="streak-pt-mark" style="max-height:1px"><img alt="" style="width:0px;max-height:0px;overflow:hidden" src="https://mailfoogae.appspot.com/t?sender=aY2xlbWNAY2NjLmNvbQ%3D%3D&type=zerocontent&guid=c32996ea-c53b-4ed3-8906-357a2e215b2f"><font color="#ffffff" size="1">ᐧ</font></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Apr 21, 2019 at 5:37 PM Mark Pizzolato <<a href="mailto:Mark@infocomm.com">Mark@infocomm.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sunday, April 21, 2019 at 11:28 AM, Zane Healy wrote:<br>
> I have a DL380 on the way to add to my ESXI cluster here at home.  As a result<br>
> I’m looking to finish virtualizing my DEC HW.  What is the best way to convert<br>
> a physical SCSI HD to a disk image for SIMH?  I need to do this for both VAX<br>
> and PDP-11.<br>
<br>
If these are SCSI disks, AND you have a host system with a SCSI host adapter <br>
that can connect to these disks (i.e. it is the correct SCSI width, and type), <br>
then you can do this directly using simh from the host system.<br>
<br>
Warning: If  you try to do this under some complicated set of layered <br>
virtual systems, then you are on your own (recall your VNC experience).<br>
<br>
Depending on your host system the OS will have some name for the <br>
above mentioned SCSI disk(s) which you've connected.  <br>
When you connect these disks to the host system, BE SURE not to <br>
perform any action on these drives BEFORE you let simh see them.<br>
Be sure you identify the raw device name that the OS sees the newly<br>
connected SCSI disks as.  Knowing that name the following should work<br>
with a VAX or PDP11 simulator.  Note that this will probably have to <br>
be done as root in order to access the physical devices.<br>
<br>
       # vax<br>
       sim> ATTACH RQ0 -c <rawdevicename> disk1.vhd<br>
       sim> DETACH RQ0<br>
<br>
This will produce a "disk1.vhd" container file with all of the bits that can be read from the original SCSI disk.<br>
Repeat as necessary for each original disk. <br>
<br>
> One of the main systems that I want to Virtualize is a VAXstation 4000/60<br>
> with a BA350 shelf.  The only HD connected to the system is a RZ28-VA SBB<br>
> (2GB) as DKA200:, so yesterday I added a RZ29-VA SBB (4GB) as DKA100:.  I<br>
> setup Standalone Backup on the RZ29 and booted into Standalone backup.<br>
> <br>
> I tried to run the following:<br>
> backup/image/verify dka200: dka100:[000000]20190420-system.sav/sav<br>
> <br>
> I ended up with a very strange “No valid storage bitmap found” error, and it<br>
> failed to copy anything.<br>
> <br>
> Facility: BACKUP, Backup Utility<br>
> Explanation: Software bad block data is not present on the volume. The<br>
> volume has been initialized with no bad blocks.<br>
> User Action: Execute the Bad Block Locator utility before using the volume.<br>
> NOBITMAP, no valid storage bitmap found on 'device-name’<br>
> <br>
> I tried ANALYZE/MEDIA, but may not have been doing things right.  This is a<br>
> Genuine RZ29-VA, but it was originally used as part of a disk array for a Sun<br>
> Sparc system.<br>
<br>
This exercise will merely put a backup saveset on another disk which I don't <br>
see getting you very far towards making it accessible from simh.<br>
<br>
Meanwhile, I suspect you are seeing a failure under standalone backup due <br>
to the fact that after you added the DKA100 disk drive to the system you <br>
didn't initialize the disk.  You can't initialize a target disk under standalone<br>
backup, so you'll have to do that with full VMS running before you attempt<br>
the backup again.<br>
<br>
- Mark<br>
_______________________________________________<br>
Simh mailing list<br>
<a href="mailto:Simh@trailing-edge.com" target="_blank">Simh@trailing-edge.com</a><br>
<a href="http://mailman.trailing-edge.com/mailman/listinfo/simh" rel="noreferrer" target="_blank">http://mailman.trailing-edge.com/mailman/listinfo/simh</a></blockquote></div>