Raw partition support

[antonjo]

I need some insights on disks based on raw partitions, that is the command:

Code: Select all

  VBoxManage internalcommands createrawvmdk -filename <vmdk path> -rawdisk <device> -partitions #
 

1. What is the partitioning scheme of the virtual disk image?
   GPT, MBR, or the same as the physical disk?
2. Can I specify a different scheme (different from the default used)?
3. As regard MBR virtual disks, what is the MBR used (if I do not use the "-mbr" option)?
   Nothing (empty space allocated), a standard VB MBR, or it is copied from the physical disk?

[mpack]

1. What is the partitioning scheme of the virtual disk image?
   GPT, MBR, or the same as the physical disk?

None of the above. Partitions are a guest OS concept, not a function of the disk drive.

[*] Can I specify a different scheme (different from the default used)?

You can supply the MBR sector as a separate vmdk extent. You can make this sector include boot code and a partition scheme which is not what the host uses. Note that it's up to you to create this MBR sector somehow. VirtualBox doesn't do it for you. One idea is to create a VM with the MBR you want, and save it off.

[*] As regard MBR virtual disks, what is the MBR used (if I do not use the "-mbr" option)?
Nothing (empty space allocated), a standard VB MBR, or it is copied from the physical disk?[/list]

Whatever is in the first sector of the disk. Since partitions do not have an MBR in sector 0 the boot will fail.


The above answers rely on the fact that you asked about creating virtual drives from raw partitions. Naturally, if you create a virtual drive from an entire physical drive then the guest sees the same partition map that the host sees.

I hope you paid attention to the user manuals dire warnings about the dangers of this feature.

[antonjo]

Thank you for your fast reply.

I hope you paid attention to the user manuals dire warnings about the dangers of this feature.

Indeed this is the reason why I am not proceeding with my usual trial-and-error approach. I have an UEFI/GPT system, which dual boots Windows and Arch Linux. From Windows as host I would like to boot the Arch Linux partition as a guest.

Some points are clear, some still require to me a bit of extra details. Specifically:

Partitions are a guest OS concept, not a function of the disk drive.

Also docs say:

While the guest will be able to see all partitions that exist on the physical disk, access will be filtered in that reading from partitions for which no access is allowed the partitions will only yield zeroes, and all writes to them are ignored.

It is not absolutely clear to me what happen to the non-partition areas (say MBRs, MBR gaps used by some boot loaders) when no `-mbr` option is given. I try to explain myself with an example.

Let us assume that I create a virtual drive from a raw partition (no `-mbr` option) and I attach it to a VM together with a live Linux ISO (eg Arch Linux ISO).
I boot the ISO. Assume that `/dev/sda` is the virtual drive image and I execute a canonical:

Code: Select all

# dd if=/dev/sda of=mbr.bin bs=512 count=1

Do I get some actual data here? And if so, where do these data come from.
Put it another way, if I write:

Code: Select all

# dd if=/dev/zero of=/dev/sda bs=512 count=1

what am I zeroing (if any)?
If the guest OS is UEFI compatible (eg Arch Linux), are the effects of `dd`, or similar tools, impacted by the fact that the VM is set with or without "Enable EFI" checked.

[mpack]

Understand that you can create a virtual drive image from any random collection of bytes. VirtualBox doesn't impose any assumptions on you. A raw disk is just getting those bytes from string of host drive sectors, instead of from a file. Otherwise it's just the same as any other virtual drive.

If you create a virtual drive image from a physical drive image then the guest will see the entire disk image.

If you create a virtual drive image from just a portion of the host drive (i.e. a host partition) then that is the what the guest will see as occupying the entire drive. Since this subset image doesn't include a partition map the guest will see it as an empty drive. You can't boot from it, you can't read data from it except using a sector viewer even if you boot from a ISO. If you want to fix this, and you don't want the guest to see the entire host drive, then you must provide a sythetic MBR sector.

Reading / writing / filling sector 0 in the guest drive will read / write / fill sector zero of the image. I.e. sector 0 of the host partition, not sector 0 of the host drive.

[antonjo]

Thank you.
I checked from the live ISO and

Code: Select all

od /dev/sda -N 512 -xv | less

results in all zeros for the MBR code area. The partition table area is not zeroed and in my case, a GPT device, it contains the data for the protective MBR. Also, extending `od` above 512 bytes, I can still see data, which supposedly is the GPT header.

As I understand now, outside the area covered by the partition(s) referenced by the VMDK image, I could write anything with absolutely no effects.

Summing-up, physical-to-virtual disk data mapping is as follows:

• MBR/GPT partition information is retained in read-only mode;
• Data on the host partition(s) virtualized can be read/written by the guest;
• Remaining physical disk data (including MBR code area) is zerored and read only.

Hope this is correct.

[mpack]

As I understand now, outside the area covered by the partition(s) referenced by the VMDK image, I could write anything with absolutely no effects.

No, that isn't correct. Unless you provided additional VMDK extents then sectors on the virtual drive beyond those referenced by the VMDK simply do not exist, so reading or writing out of range sectors would result in disk errors. The fact that the physical drive has additional sectors on it is not relevant to the virtual drive.

If you mount a host partition as a virtual drive then sector 0 of the virtual drive maps to sector 0 of the host partition. On some filesystems this might be filled with zeroes. On XP guests for example it would contains a boot sector (but not an MBR).