In a real PC, hard disks and CD/DVD drives are connected to a device called hard disk controller which drives hard disk operation and data transfers. VirtualBox can emulate the five most common types of hard disk controllers typically found in today's PCs: IDE, SATA (AHCI), SCSI, SAS, USB-based and NVMe mass storage devices.^[21]

In summary, VirtualBox gives you the following categories of virtual storage slots:

Given this large choice of storage controllers, you may ask yourself which one to choose. In general, you should avoid IDE unless it is the only controller supported by your guest. Whether you use SATA, SCSI or SAS does not make any real difference. The variety of controllers is only supplied for VirtualBox for compatibility with existing hardware and other hypervisors.

Disk image files reside on the host system and are seen by the guest systems as hard disks of a certain geometry. When a guest operating system reads from or writes to a hard disk, VirtualBox redirects the request to the image file.

Like a physical disk, a virtual disk has a size (capacity), which must be specified when the image file is created. As opposed to a physical disk however, VirtualBox allows you to expand an image file after creation, even if it has data already; see Section 8.23, “VBoxManage modifymedium” for details.^[25]

VirtualBox supports four variants of disk image files:

Irrespective of the disk capacity and format, as briefly mentioned in Section 1.7, “Creating your first virtual machine”, there are two options of how to create a disk image: fixed-size or dynamically allocated.

VirtualBox keeps track of all the hard disk, CD/DVD-ROM and floppy disk images which are in use by virtual machines. These are often referred to as "known media" and come from two sources:

The known media can be viewed and changed in the Virtual Media Manager, which you can access from the "File" menu in the VirtualBox main window:

The known media are conveniently grouped in three tabs for the three possible formats. These formats are:

As you can see in the screenshot above, for each image, the Virtual Media Manager shows you the full path of the image file and other information, such as the virtual machine the image is currently attached to, if any.

The Virtual Media Manager allows you to

These commands are accessible once a medium has been selected either by selecting from the options shown at the top of the window, or by right-clicking the medium and selecting from the options shown on the drop-down menu.

Starting with version 4.0, to create new disk images, please use the "Storage" page in a virtual machine's settings dialog because disk images are now by default stored in each machine's own folder.

Hard disk image files can be copied onto other host systems and imported into virtual machines there, although certain guest systems (notably Windows 2000 and XP) will require that the new virtual machine be set up in a similar way to the old one.

For each virtual disk image supported by VirtualBox, you can determine separately how it should be affected by write operations from a virtual machine and snapshot operations. This applies to all of the aforementioned image formats (VDI, VMDK, VHD or HDD) and irrespective of whether an image is fixed-size or dynamically allocated.

By default, images are in "normal" mode. To mark an existing image with one of the non-standard modes listed below, use VBoxManage modifyhd; see Section 8.23, “VBoxManage modifymedium”. Alternatively, use VBoxManage to attach the image to a VM and use the --mtype argument; see Section 8.18, “VBoxManage storageattach”.

To illustrate the differences between the various types with respect to snapshots: Assume you have installed your guest operating system in your VM, and you have taken a snapshot. Imagine you have accidentally infected your VM with a virus and would like to go back to the snapshot. With a normal hard disk image, you simply restore the snapshot, and the earlier state of your hard disk image will be restored as well (and your virus infection will be undone). With an immutable hard disk, all it takes is to shut down and power on your VM, and the virus infection will be discarded. With a write-through image however, you cannot easily undo the virus infection by means of virtualization, but will have to disinfect your virtual machine like a real computer.

Still, you might find write-through images useful if you want to preserve critical data irrespective of snapshots, and since you can attach more than one image to a VM, you may want to have one immutable for the operating system and one write-through for your data files.

The previous section hinted at differencing images and how they are used with snapshots, immutable images and multiple disk attachments. For the inquisitive VirtualBox user, this section describes in more detail how they work.

A differencing image is a special disk image that only holds the differences to another image. A differencing image by itself is useless, it must always refer to another image. The differencing image is then typically referred to as a "child", which holds the differences to its "parent".

When a differencing image is active, it receives all write operations from the virtual machine instead of its parent. The differencing image only contains the sectors of the virtual hard disk that have changed since the differencing image was created. When the machine reads a sector from such a virtual hard disk, it looks into the differencing image first. If the sector is present, it is returned from there; if not, VirtualBox looks into the parent. In other words, the parent becomes "read-only"; it is never written to again, but it is read from if a sector has not changed.

Differencing images can be chained. If another differencing image is created for a virtual disk that already has a differencing image, then it becomes a "grandchild" of the original parent. The first differencing image then becomes read-only as well, and write operations only go to the second-level differencing image. When reading from the virtual disk, VirtualBox needs to look into the second differencing image first, then into the first if the sector was not found, and then into the original image.

There can be an unlimited number of differencing images, and each image can have more than one child. As a result, the differencing images can form a complex tree with parents, "siblings" and children, depending on how complex your machine configuration is. Write operations always go to the one "active" differencing image that is attached to the machine, and for read operations, VirtualBox may need to look up all the parents in the chain until the sector in question is found. You can look at such a tree in the Virtual Media Manager:

In all of these situations, from the point of view of the virtual machine, the virtual hard disk behaves like any other disk. While the virtual machine is running, there is a slight run-time I/O overhead because VirtualBox might need to look up sectors several times. This is not noticeable however since the tables with sector information are always kept in memory and can be looked up quickly.

Differencing images are used in the following situations:

You can duplicate hard disk image files on the same host to quickly produce a second virtual machine with the same operating system setup. However, you should only make copies of virtual disk images using the utility supplied with VirtualBox; see Section 8.24, “VBoxManage clonemedium”. This is because VirtualBox assigns a unique identity number (UUID) to each disk image, which is also stored inside the image, and VirtualBox will refuse to work with two images that use the same number. If you do accidentally try to re-import a disk image which you copied normally, you can make a second copy using VirtualBox's utility and import that instead.

Note that newer Linux distributions identify the boot hard disk from the ID of the drive. The ID VirtualBox reports for a drive is determined from the UUID of the virtual disk image. So if you clone a disk image and try to boot the copied image the guest might not be able to determine its own boot disk as the UUID changed. In this case you have to adapt the disk ID in your boot loader script (for example /boot/grub/menu.lst). The disk ID looks like this:

scsi-SATA_VBOX_HARDDISK_VB5cfdb1e2-c251e503

The ID for the copied image can be determined with

hdparm -i /dev/sda

Starting with version 3.2, VirtualBox can optionally disable the I/O caching that the host operating system would otherwise perform on disk image files.

Traditionally, VirtualBox has opened disk image files as normal files, which results in them being cached by the host operating system like any other file. The main advantage of this is speed: when the guest OS writes to disk and the host OS cache uses delayed writing, the write operation can be reported as completed to the guest OS quickly while the host OS can perform the operation asynchronously. Also, when you start a VM a second time and have enough memory available for the OS to use for caching, large parts of the virtual disk may be in system memory, and the VM can access the data much faster.

Note that this applies only to image files; buffering never occurred for virtual disks residing on remote iSCSI storage, which is the more common scenario in enterprise-class setups (see Section 5.10, “iSCSI servers”).

While buffering is a useful default setting for virtualizing a few machines on a desktop computer, there are some disadvantages to this approach:

If you decide to disable host I/O caching for the above reasons, VirtualBox uses its own small cache to buffer writes, but no read caching since this is typically already performed by the guest OS. In addition, VirtualBox fully supports asynchronous I/O for its virtual SATA, SCSI and SAS controllers through multiple I/O threads.

Since asynchronous I/O is not supported by IDE controllers, for performance reasons, you may want to leave host caching enabled for your VM's virtual IDE controllers.

For this reason, VirtualBox allows you to configure whether the host I/O cache is used for each I/O controller separately. Either uncheck the "Use host I/O cache" box in the "Storage" settings for a given virtual storage controller, or use the following VBoxManage command to disable the host I/O cache for a virtual storage controller:

VBoxManage storagectl "VM name" --name <controllername> --hostiocache off

See Section 8.19, “VBoxManage storagectl” for details.

For the above reasons also, VirtualBox now uses SATA controllers by default for new virtual machines.

Starting with version 4.0, VirtualBox allows for limiting the maximum bandwidth used for asynchronous I/O. Additionally it supports sharing limits through bandwidth groups for several images. It is possible to have more than one such limit.

Limits are configured through VBoxManage. The example below creates a bandwidth group named "Limit", sets the limit to 20 MB/s and assigns the group to the attached disks of the VM:

VBoxManage bandwidthctl "VM name" add Limit --type disk --limit 20M
VBoxManage storageattach "VM name" --storagectl "SATA" --port 0 --device 0 --type hdd
                                   --medium disk1.vdi --bandwidthgroup Limit
VBoxManage storageattach "VM name" --storagectl "SATA" --port 1 --device 0 --type hdd
                                   --medium disk2.vdi --bandwidthgroup Limit

All disks in a group share the bandwidth limit, meaning that in the example above the bandwidth of both images combined can never exceed 20 MB/s. However, if one disk doesn't require bandwidth the other can use the remaining bandwidth of its group.

The limits for each group can be changed while the VM is running, with changes being picked up immediately. The example below changes the limit for the group created in the example above to 10 MB/s:

VBoxManage bandwidthctl "VM name" set Limit --limit 10M

The virtual CD/DVD drive(s) by default support only reading. The medium configuration is changeable at runtime. You can select between three options to provide the medium data:

Changing between the above, or changing a medium in the host drive that is accessed by a machine, or changing an image file will signal a medium change to the guest operating system, which can then react to the change (e.g. by starting an installation program).

Medium changes can be prevented by the guest, and VirtualBox reflects that by locking the host drive if appropriate. You can force a medium removal in such situations via the VirtualBox GUI or the VBoxManage command line tool. Effectively this is the equivalent of the emergency eject which many CD/DVD drives provide, with all associated side effects: the guest OS can issue error messages, just like on real hardware, and guest applications may misbehave. Use this with caution.

The standard CD/DVD emulation allows for reading standard data CD and DVD formats only. As an experimental feature, for additional capabilities, it is possible to give the guest direct access to the CD/DVD host drive by enabling "passthrough" mode. Depending on the host hardware, this may enable three things to work, potentially:

There is a "Passthrough" checkbox in the GUI dialog for configuring the media attached to a storage controller, or you can use the --passthrough option with VBoxManage storageattach; see Section 8.18, “VBoxManage storageattach” for details.

Even if pass-through is enabled, unsafe commands, such as updating the drive firmware, will be blocked. Video CD formats are never supported, not even in passthrough mode, and cannot be played from a virtual machine.

On Solaris hosts, pass-through requires running VirtualBox with real root permissions due to security measures enforced by the host.

iSCSI stands for "Internet SCSI" and is a standard that allows for using the SCSI protocol over Internet (TCP/IP) connections. Especially with the advent of Gigabit Ethernet, it has become affordable to attach iSCSI storage servers simply as remote hard disks to a computer network. In iSCSI terminology, the server providing storage resources is called an "iSCSI target", while the client connecting to the server and accessing its resources is called "iSCSI initiator".

VirtualBox can transparently present iSCSI remote storage to a virtual machine as a virtual hard disk. The guest operating system will not see any difference between a virtual disk image (VDI file) and an iSCSI target. To achieve this, VirtualBox has an integrated iSCSI initiator.

VirtualBox's iSCSI support has been developed according to the iSCSI standard and should work with all standard-conforming iSCSI targets. To use an iSCSI target with VirtualBox, you must use the command line; see Section 8.18, “VBoxManage storageattach”.