| 1 | <?xml version='1.0' encoding='UTF-8'?>
|
|---|
| 2 | <!DOCTYPE topic PUBLIC "-//OASIS//DTD DITA Topic//EN" "topic.dtd">
|
|---|
| 3 | <topic xml:lang="en-us" id="rawdisk-access-disk-partitions">
|
|---|
| 4 | <title>Access to Individual Physical Hard Disk Partitions</title>
|
|---|
| 5 |
|
|---|
| 6 | <body>
|
|---|
| 7 | <p>This <i>raw partition support</i> is quite similar to the full hard disk access described above. However, in this
|
|---|
| 8 | case, any partitioning information will be stored inside the VMDK image. This means that you can install a
|
|---|
| 9 | different boot loader in the virtual hard disk without affecting the host's partitioning information. While
|
|---|
| 10 | the guest will be able to <i>see</i> all partitions that exist on the physical disk, access will be filtered
|
|---|
| 11 | in that reading from partitions for which no access is allowed the partitions will only yield zeroes, and
|
|---|
| 12 | all writes to them are ignored. </p>
|
|---|
| 13 | <p>To create a special image for raw partition support, which will contain a small amount of data, on a Linux host,
|
|---|
| 14 | use the command: </p>
|
|---|
| 15 | <pre xml:space="preserve">$ VBoxManage createmedium disk --filename <varname>path-to-file</varname>.vmdk --format=VMDK
|
|---|
| 16 | --variant RawDisk --property RawDrive=/dev/sda --property Partitions=1,5</pre>
|
|---|
| 17 | <p>The command is identical to the one for full hard disk access, except for the additional
|
|---|
| 18 | <codeph>--property</codeph> Partitions=1,5 parameter. This example would create the image
|
|---|
| 19 | <filepath><varname>path-to-file</varname>.vmdk</filepath>, which must be absolute, and partitions 1
|
|---|
| 20 | and 5 of <filepath>/dev/sda</filepath> would be made accessible to the guest. </p>
|
|---|
| 21 | <p><ph conkeyref="vbox-conkeyref-phrases/product-name"/> uses the same partition numbering as your Linux host. As a
|
|---|
| 22 | result, the numbers given in the above example would refer to the first primary partition and the first
|
|---|
| 23 | logical drive in the extended partition, respectively. </p>
|
|---|
| 24 | <p>On a Windows host, instead of the above device specification, use for example
|
|---|
| 25 | <filepath>\\.\PhysicalDrive0</filepath>. On a macOS host, instead of the above device specification use
|
|---|
| 26 | <filepath>/dev/rdisk1</filepath>, for example. Note that on OS X you can only use partitions which are
|
|---|
| 27 | not mounted. Unmount the respective disk first using <i>diskutil unmountDisk <filepath>/dev/diskX</filepath>
|
|---|
| 28 | </i>. Partition numbers are the same on Linux, Windows, and macOS hosts. </p>
|
|---|
| 29 | <p>The numbers for the list of partitions can be taken from the output of the following command: </p>
|
|---|
| 30 | <pre xml:space="preserve">$ VBoxManage list hostdrives</pre>
|
|---|
| 31 | <p>The output lists available drives and their partitions with the partition types and sizes to give the user enough
|
|---|
| 32 | information to identify the partitions necessary for the guest. </p>
|
|---|
| 33 | <p>Images which give access to individual partitions are specific to a particular host disk setup. You cannot
|
|---|
| 34 | transfer these images to another host. Also, whenever the host partitioning changes, the image <i>must be
|
|---|
| 35 | recreated</i>. </p>
|
|---|
| 36 | <p>Creating the image requires read/write access for the given device. Read/write access is also later needed when
|
|---|
| 37 | using the image from a virtual machine. If this is not feasible, there is a special variant for raw
|
|---|
| 38 | partition access, currently only available on Linux hosts, that avoids having to give the current user
|
|---|
| 39 | access to the entire disk. To set up such an image, use: </p>
|
|---|
| 40 | <pre xml:space="preserve">$ VBoxManage createmedium disk --filename <varname>path-to-file</varname>.vmdk --format=VMDK
|
|---|
| 41 | --variant RawDisk --property RawDrive=/dev/sda --property Partitions=1,5
|
|---|
| 42 | --property Relative=1</pre>
|
|---|
| 43 | <p>When used from a virtual machine, the image will then refer not to the entire disk, but only to the individual
|
|---|
| 44 | partitions. In this example, <filepath>/dev/sda1</filepath> and <filepath>/dev/sda5</filepath>. As a
|
|---|
| 45 | consequence, read/write access is only required for the affected partitions, not for the entire disk. During
|
|---|
| 46 | creation however, read-only access to the entire disk is required to obtain the partitioning information. </p>
|
|---|
| 47 | <p>In some configurations it may be necessary to change the MBR code of the created image. For example, to replace
|
|---|
| 48 | the Linux boot loader that is used on the host by another boot loader. This enables for example the guest to
|
|---|
| 49 | boot directly to Windows, while the host boots Linux from the "same" disk. For this purpose the
|
|---|
| 50 | <codeph>--property-file</codeph> BootSector=<varname>path-to-file-with-boot-sector</varname> parameter
|
|---|
| 51 | is provided. It specifies a file name from which to take the MBR code. The partition table is not modified
|
|---|
| 52 | at all, so a MBR file from a system with totally different partitioning can be used. An example of this is: </p>
|
|---|
| 53 | <pre xml:space="preserve">$ VBoxManage createmedium disk --filename <varname>path-to-file</varname>.vmdk --format=VMDK
|
|---|
| 54 | --variant RawDisk --property RawDrive=/dev/sda --property Partitions=1,5
|
|---|
| 55 | --property-file BootSector=winxp.mbr</pre>
|
|---|
| 56 | <p>The modified MBR will be stored inside the image, not on the host disk. </p>
|
|---|
| 57 | <p>The created image can be attached to a storage controller in a VM configuration as usual. </p>
|
|---|
| 58 | </body>
|
|---|
| 59 |
|
|---|
| 60 | </topic>
|
|---|
