I want to insert a virtual hard drive (or anything) to occupy the system block /dev/sdb, how could I do that in Linux (Ubuntu and Debian)?
4 Answers
Create a file of the size you'd like this virtual hard drive to be (the following makes a 1Mx1024 or 1GByte file):
dd if=/dev/zero of=virtual_hard_drive.bin bs=1M count=1024
Create a loop device standing in place of /dev/sdb
mknod /dev/sdb b 7 500
No, this will not work if you already have a /dev/sdb
there.
You'll need to change the 500 to another number in the extremely unlikely event you have a /dev/loop500
.
Now, assign your file to this loop device
losetup /dev/sdb virtual_hard_drive.bin
So now you have a file acting as a hard drive, through Linux's loop device mechanism. At this point you want to format it with mke2fs /dev/sdb
or similar, and then mount it in the usual fashion.
To get this to work on boot will require some editing of boot time scripts as the scripts that check fstab
won't make /dev/sdb
into a loop device on boot by themselves.
If you don't really need a volume there, you can do something like ln -s /dev/sdb /dev/full
to make /dev/sdb
"point to" the full
(or zero
or null
, or even dvdrom
) virtual devices.
-
Hi, after the step mknod..., the /dev/ really contains a new virtual sdb file. However, in /sys/block/, a link named loop500 is created... How do I change this to "sdb"? thanks– return 0Dec 10, 2013 at 0:46
-
-
May have to use
ln
for the/sys/block
if that's possible, i.e. tryln -s /sys/block/sdb /sys/block/loop500
or similar. To remove the loop, unmount it, thenlosetup -d /dev/sdb
, then delete the device file youmknod
ed. Dec 10, 2013 at 2:05
If you want to use a raw disk image file you can use loopback devices to access it as a block device (like /dev/sdb
).
- Create an empty image:
dd if=/dev/zero of=/path/to/the/image bs=1M count=10240
This will create an empty image of size 10 GiB. - Associate the image with a loop device:
sudo losetup -f --show /path/to/the/image
This will print the used loop device. Let's say it is/dev/loop0
. - Create partitions (and file systems):
sudo gparted /dev/loop0
- Move the original
/dev/sdb
:for a in /dev/sdb* ; do sudo mv "$a" "$a-orig" ; done
- Copy loop devices in place of
/dev/sdb
:l=/dev/loop0 ; d=/dev/sdb ; sudo cp -a "$l" "$d" ; for a in "$l"* ; do sudo cp -a "$a" "$d${a#$l}" ; done
After that you will have the disk image /path/to/the/image
accessible as /dev/sdb
including partitions.
Why do you specifically need it to be /dev/sdb
? I think you need to explain why you want something to occupy that block device node, because you can't simply have something use it. If you have some software that wants to read /dev/sdb
, you could just change the software.
In the worst case, you can use the SCSI debug host simulator. Simply do modprobe scsi_debug
, and the defaults should provide a single SCSI device. Note that it won't explicitly be on /dev/sdb
, but always the next available SCSI device.
-
This has to be the most useful thing i've found all week. Why did no one else mention SCSI debug simulator in my search for block device ramdisks?– Brad P.Jan 24, 2018 at 22:31
-
@BradP. I'd call that a different need, one that I previously blogged about as well (depends on what properties you need, older options include mtdram, loop, newer high-performance is nvme loop target).– robbat2Jan 25, 2018 at 19:16
The solutions based on losetup
given above don't create a SCSI block device, hence they don't create a /dev/sd*
device node and some renaming or linking is required to create one, and some software may not find the device suitable since it's not using the SCSI subsystem.
It is possible to create a SCSI disk device that is backed by a partition or file using targetcli
. See http://linux-iscsi.org/wiki/Tcm_loop, and https://stackoverflow.com/questions/30972176/creating-a-loopback-device-in-lio-scsi-target which covers an issue with those instructions. As with the SCSI debug host simulator suggested by @robbat2, this device will be assigned the next available identifier.
I gather that the SCSI debug host simulator is backed by RAM, so it is volatile. With the method that I propose here, the data will actually be written to a partition or file.
-
Because the "target" subsystem is meant for exporting drives via iSCSI or FireWire, it should support file-backed (or at least loopdev-backed) devices just fine. Oct 12, 2018 at 12:40