There are presently three methods in which to achieve this: Most commonly, VirtualBox will use large image files on a real hard disk and present them to a guest as a virtual hard disk. Each such virtual storage device image file, iSCSI target or physical hard disk will need to be connected to the virtual hard disk controller that VirtualBox presents to a virtual machine.
This is explained in the next section. VirtualBox can emulate the five most common types of hard disk controllers typically found in today's PCs: Initially, this interface worked only with hard disks, but was later extended to also support CD-ROM drives and other types of removable media. In physical PCs, this standard uses flat ribbon parallel cables with 40 or 80 wires.
Each such cable can connect two devices to a controller, which have traditionally been called "master" and "slave". Typical PCs had two connectors for such cables; as a result, support for up to four IDE devices was most common. In VirtualBox, each virtual machine may have one IDE controller enabled, which gives you up to four virtual storage devices that you can attach to the machine. This makes no difference in terms of performance, but if you import a virtual machine from another virtualization product, the operating system in that machine may expect a particular controller type and crash if it isn't found.
Compared to IDE, it supports both much higher speeds and more devices per controller. Also, with physical hardware, devices can be added and removed while the system is running. Also, this allows you to connect up to 30 virtual hard disks to one machine instead of just three, as with the VirtualBox IDE controller with the DVD drive already attached.
For this reason, starting with version 3. One virtual SATA controller is created by default, and the default disk that is created with a new VM is attached to this controller. After this, the additional controller will appear as a separate PCI device in the virtual machine, and you can add virtual disks to it.
SCSI was standardized as early as as a generic interface for data transfer between all kinds of devices, including storage devices. Today SCSI is still used for connecting hard disks and tape devices, but it has mostly been displaced in commodity hardware. It is still in common use in high-performance workstations and servers. After this, the additional controller will appear as a separate PCI device in the virtual machine.
Warning As with the other controller types, a SCSI controller will only be seen by operating systems with device support for it. Windows XP ships with drivers for neither. As opposed to SCSI, however, with physical devices, serial cables are used instead of parallel ones, which simplifies physical device connections. At this time, up to eight devices can be connected to the SAS controller.
The USB mass storage device class is a standard to connect external storage devices like hard disks or flash drives to a host through USB. All major operating systems support these devices for a long time and ship generic drivers making third-party drivers superfluous. The virtual USB storage controller offered by VirtualBox works different than the other storage controller types: When storage controllers appear as a single PCI device to the guest with multiple disks attached to it, the USB-based storage controller does not appear as virtual storage controller.
Each disk attached to the controller appears as a dedicated USB device to the guest. Operating systems need to support NVMe devices to make use of them. For example Windows 8.
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.
The variety of controllers is only supplied for VirtualBox for compatibility with existing hardware and other hypervisors. 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.
In particular, this format will be used when you create a new virtual machine with a new disk. VirtualBox also fully supports the popular and open VMDK container format that is used by many other virtualization products, in particular, by VMware. Image files of Parallels version 2 HDD format are also supported. You can however convert such image files to version 2 format using tools provided by Parallels. If you create a fixed-size image, an image file will be created on your host system which has roughly the same size as the virtual disk's capacity.
So, for a 10G disk, you will have a 10G file. Note that the creation of a fixed-size image can take a long time depending on the size of the image and the write performance of your hard disk. For more flexible storage management, use a dynamically allocated image. This will initially be very small and not occupy any space for unused virtual disk sectors, but will grow every time a disk sector is written to for the first time, until the drive reaches the maximum capacity chosen when the drive was created.
While this format takes less space initially, the fact that VirtualBox needs to expand the image file consumes additional computing resources, so until the disk file size has stabilized, write operations may be slower than with fixed size disks.
However, after a time the rate of growth will slow and the average penalty for write operations will be negligible. These are often referred to as "known media" and come from two sources: For details about how media registration has changed with version 4. 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.
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 remove an image from the registry and optionally delete the image file when doing so ; "release" an image, that is, detach it from a virtual machine if it is currently attached to one as a virtual hard disk.
Normal, Immutable, Writethrough, Shareable, Multi-attach. 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. Hard disk image files can be copied onto other host systems and imported into virtual machines there, although certain guest systems notably Windows and XP will require that the new virtual machine be set up in a similar way to the old one.
Note Do not simply make copies of virtual disk images. If you import such a second copy into a virtual machine, VirtualBox will complain with an error, since VirtualBox assigns a unique identifier UUID to each disk image to make sure it is only used once. Special image write modes 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.
By default, images are in "normal" mode. With normal images the default setting , there are no restrictions on how guests can read from and write to the disk. Technically, strictly speaking, the image file itself is not "reset". Instead, when a snapshot is taken, VirtualBox "freezes" the image file and no longer writes to it. For the write operations from the VM, a second, "differencing" image file is created which receives only the changes to the original image; see the next section for details.
While you can attach the same "normal" image to more than one virtual machine, only one of these virtual machines attached to the same image file can be executed simultaneously, as otherwise there would be conflicts if several machines write to the same image file.
Shareable hard disks are a variant of write-through hard disks. In principle they behave exactly the same, i. The difference only shows if you attach such disks to several VMs. Shareable disks may be attached to several VMs which may run concurrently.
This makes them suitable for use by cluster filesystems between VMs and similar applications which are explicitly prepared to access a disk concurrently. Only fixed size images can be used in this way, and dynamically allocated images are rejected.
Warning This is an expert feature, and misuse can lead to data loss -- regular filesystems are not prepared to handle simultaneous changes by several parties. Next, immutable images only remember write accesses temporarily while the virtual machine is running; all changes are lost when the virtual machine is powered on the next time.
As a result, as opposed to "normal" images, the same immutable image can be used with several virtual machines without restrictions. Creating an immutable image makes little sense since it would be initially empty and lose its contents with every machine restart unless you really want to have a disk that is always unformatted when the machine starts up.
As a result, normally, you would first create a "normal" image and then, when you deem its contents useful, later mark it immutable.
If you take a snapshot of a machine with immutable images, then on every machine power-up, those images are reset to the state of the last current snapshot instead of the state of the original immutable image. Note As a special exception, immutable images are not reset if they are attached to a machine in saved state or whose last snapshot was taken while the machine was running a so-called "online" snapshot. As a result, if the machine's current snapshot is such an "online" snapshot, its immutable images behave exactly like the "normal" images described previously.
To re-enable the automatic resetting of such images, delete the current snapshot of the machine. Again, technically, VirtualBox never writes to an immutable image directly at all. All write operations from the machine will be directed to a differencing image; the next time the VM is powered on, the differencing image is reset so that every time the VM starts, its immutable images have exactly the same content.
This is also why immutable images behave as described above when snapshots are also present, which use differencing images as well.
An image in multiattach mode can be attached to more than one virtual machine at the same time, even if these machines are running simultaneously. For each virtual machine to which such an image is attached, a differencing image is created.
As a result, data that is written to such a virtual disk by one machine is not seen by the other machines to which the image is attached; each machine creates its own write history of the multiattach image. Technically, a "multiattach" image behaves identically to an "immutable" image except the differencing image is not reset every time the machine starts. This mode is useful for sharing files which are almost never written, for instance picture galleries, where every guest changes only a small amount of data and the majority of the disk content remains unchanged.
The modified blocks are stored in differencing images which remain relatively small and the shared content is stored only once at the host. 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.